mirror of
https://github.com/followmsi/android_kernel_google_msm.git
synced 2024-11-06 23:17:41 +00:00
typo fixes
Most of these fixes were already submitted for old kernel versions, and were approved, but for some reason they never made it into the releases. Because this is a consolidation of a couple old missed patches, it touches both Kconfigs and documentation texts. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
This commit is contained in:
Matt LaPlante
Adrian Bunk
parent
0f035b8e84
commit
01dd2fbf0d
50 changed files with 186 additions and 180 deletions
|
|
@ -5,7 +5,7 @@ Introduction
|
|||
------------
|
||||
|
||||
The kernel provides an interface to manage DMA transfers
|
||||
using the DMA channels in the cpu, so that the central
|
||||
using the DMA channels in the CPU, so that the central
|
||||
duty of managing channel mappings, and programming the
|
||||
channel generators is in one place.
|
||||
|
||||
|
|
@ -17,24 +17,24 @@ DMA Channel Ordering
|
|||
channels to all sources, which means that some devices
|
||||
have a restricted number of channels that can be used.
|
||||
|
||||
To allow flexibilty for each cpu type and board, the
|
||||
dma code can be given an dma ordering structure which
|
||||
To allow flexibility for each CPU type and board, the
|
||||
DMA code can be given a DMA ordering structure which
|
||||
allows the order of channel search to be specified, as
|
||||
well as allowing the prohibition of certain claims.
|
||||
|
||||
struct s3c24xx_dma_order has a list of channels, and
|
||||
each channel within has a slot for a list of dma
|
||||
channel numbers. The slots are searched in order, for
|
||||
the presence of a dma channel number with DMA_CH_VALID
|
||||
orred in.
|
||||
each channel within has a slot for a list of DMA
|
||||
channel numbers. The slots are searched in order for
|
||||
the presence of a DMA channel number with DMA_CH_VALID
|
||||
or-ed in.
|
||||
|
||||
If the order has the flag DMA_CH_NEVER set, then after
|
||||
checking the channel list, the system will return no
|
||||
found channel, thus denying the request.
|
||||
|
||||
A board support file can call s3c24xx_dma_order_set()
|
||||
to register an complete ordering set. The routine will
|
||||
copy the data, so the original can be discared with
|
||||
to register a complete ordering set. The routine will
|
||||
copy the data, so the original can be discarded with
|
||||
__initdata.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2188,7 +2188,7 @@ Your cooperation is appreciated.
|
|||
|
||||
136-143 char Unix98 PTY slaves
|
||||
0 = /dev/pts/0 First Unix98 pseudo-TTY
|
||||
1 = /dev/pts/1 Second Unix98 pesudo-TTY
|
||||
1 = /dev/pts/1 Second Unix98 pseudo-TTY
|
||||
...
|
||||
|
||||
These device nodes are automatically generated with
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ braindamaged document, if it's finally working, well, it's working.
|
|||
|
||||
For one reason or another, low level drivers don't receive as much
|
||||
attention or testing as core code, and bugs on driver detach or
|
||||
initilaization failure doesn't happen often enough to be noticeable.
|
||||
initialization failure don't happen often enough to be noticeable.
|
||||
Init failure path is worse because it's much less travelled while
|
||||
needs to handle multiple entry points.
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ resources on failure. For example,
|
|||
devres_release_group(dev, NULL);
|
||||
return err_code;
|
||||
|
||||
As resource acquision failure usually means probe failure, constructs
|
||||
As resource acquisition failure usually means probe failure, constructs
|
||||
like above are usually useful in midlayer driver (e.g. libata core
|
||||
layer) where interface function shouldn't have side effect on failure.
|
||||
For LLDs, just returning error code suffices in most cases.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Deferred IO
|
|||
|
||||
Deferred IO is a way to delay and repurpose IO. It uses host memory as a
|
||||
buffer and the MMU pagefault as a pretrigger for when to perform the device
|
||||
IO. The following example may be a useful explaination of how one such setup
|
||||
IO. The following example may be a useful explanation of how one such setup
|
||||
works:
|
||||
|
||||
- userspace app like Xfbdev mmaps framebuffer
|
||||
|
|
@ -28,7 +28,7 @@ a relatively more expensive operation.
|
|||
|
||||
For some types of nonvolatile high latency displays, the desired image is
|
||||
the final image rather than the intermediate stages which is why it's okay
|
||||
to not update for each write that is occuring.
|
||||
to not update for each write that is occurring.
|
||||
|
||||
It may be the case that this is useful in other scenarios as well. Paul Mundt
|
||||
has mentioned a case where it is beneficial to use the page count to decide
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ OPTIONS
|
|||
aname=name aname specifies the file tree to access when the server is
|
||||
offering several exported file systems.
|
||||
|
||||
cache=mode specifies a cacheing policy. By default, no caches are used.
|
||||
cache=mode specifies a caching policy. By default, no caches are used.
|
||||
loose = no attempts are made at consistency,
|
||||
intended for exclusive, read-only mounts
|
||||
|
||||
|
|
|
|||
|
|
@ -21,10 +21,10 @@ software test suits to do stressful testing on IPF.
|
|||
|
||||
Below is a sample application as part of the whole tool. The sample
|
||||
can be used as a working test tool. Or it can be expanded to include
|
||||
more features. It also can be a integrated into a libary or other user
|
||||
more features. It also can be a integrated into a library or other user
|
||||
application to have more thorough test.
|
||||
|
||||
The sample application takes err.conf as error configuation input. Gcc
|
||||
The sample application takes err.conf as error configuration input. GCC
|
||||
compiles the code. After you install err_inject driver, you can run
|
||||
this sample application to inject errors.
|
||||
|
||||
|
|
@ -809,7 +809,7 @@ int err_inj()
|
|||
}
|
||||
|
||||
/* Create semaphore: If one_lock, one semaphore for all processors.
|
||||
Otherwise, one sempaphore for each processor. */
|
||||
Otherwise, one semaphore for each processor. */
|
||||
if (one_lock) {
|
||||
if (create_sem(0)) {
|
||||
printf("Can not create semaphore...exit\n");
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ major controller faults (ROM checksum and RAM test) and such things as stuck
|
|||
keys. Any keys down at power-up are presumed to be stuck, and their BREAK
|
||||
(sic) code is returned (which without the preceding MAKE code is a flag for a
|
||||
keyboard error). If the controller self-test completes without error, the code
|
||||
0xF0 is returned. (This code will be used to indicate the version/rlease of
|
||||
0xF0 is returned. (This code will be used to indicate the version/release of
|
||||
the ikbd controller. The first release of the ikbd is version 0xF0, should
|
||||
there be a second release it will be 0xF1, and so on.)
|
||||
The ikbd defaults to a mouse position reporting with threshold of 1 unit in
|
||||
|
|
@ -413,7 +413,7 @@ INTERROGATION MODE.
|
|||
%nnnnmmmm ; where m is JOYSTICK1 state
|
||||
; and n is JOYSTICK0 state
|
||||
|
||||
Sets the ikbd to do nothing but monitor the serial command lne, maintain the
|
||||
Sets the ikbd to do nothing but monitor the serial command line, maintain the
|
||||
time-of-day clock, and monitor the joystick. The rate sets the interval
|
||||
between joystick samples.
|
||||
N.B. The user should not set the rate higher than the serial communications
|
||||
|
|
@ -446,10 +446,10 @@ The sample interval should be as constant as possible.
|
|||
; until vertical cursor key is generated before RY
|
||||
; has elapsed
|
||||
VX ; length (in tenths of seconds) of joystick closure
|
||||
; until horizontal cursor keystokes are generated
|
||||
; until horizontal cursor keystrokes are generated
|
||||
; after RX has elapsed
|
||||
VY ; length (in tenths of seconds) of joystick closure
|
||||
; until vertical cursor keystokes are generated
|
||||
; until vertical cursor keystrokes are generated
|
||||
; after RY has elapsed
|
||||
|
||||
In this mode, joystick 0 is scanned in a way that simulates cursor keystrokes.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ This is not a reference. Comments and corrections are welcome. To contact me,
|
|||
send an email to: johann.deneux@gmail.com
|
||||
|
||||
** WARNING **
|
||||
I may not be held responsible for any dammage or harm caused if you try to
|
||||
I shall not be held responsible for any damage or harm caused if you try to
|
||||
send data to your I-Force device based on what you read in this document.
|
||||
|
||||
** Preliminary Notes:
|
||||
|
|
@ -151,13 +151,13 @@ OP= ff
|
|||
Query command. Length varies according to the query type.
|
||||
The general format of this packet is:
|
||||
ff 01 QUERY [INDEX] CHECKSUM
|
||||
reponses are of the same form:
|
||||
responses are of the same form:
|
||||
FF LEN QUERY VALUE_QUERIED CHECKSUM2
|
||||
where LEN = 1 + length(VALUE_QUERIED)
|
||||
|
||||
**** Query ram size ****
|
||||
QUERY = 42 ('B'uffer size)
|
||||
The device should reply with the same packet plus two additionnal bytes
|
||||
The device should reply with the same packet plus two additional bytes
|
||||
containing the size of the memory:
|
||||
ff 03 42 03 e8 CS would mean that the device has 1000 bytes of ram available.
|
||||
|
||||
|
|
@ -234,12 +234,16 @@ is the amount of memory apparently needed for every set of parameters:
|
|||
|
||||
** Appendix: How to study the protocol ? **
|
||||
|
||||
1. Generate effects using the force editor provided with the DirectX SDK, or use Immersion Studio (freely available at their web site in the developer section: www.immersion.com)
|
||||
2. Start a soft spying RS232 or USB (depending on where you connected your joystick/wheel). I used ComPortSpy from fCoder (alpha version!)
|
||||
1. Generate effects using the force editor provided with the DirectX SDK, or
|
||||
use Immersion Studio (freely available at their web site in the developer section:
|
||||
www.immersion.com)
|
||||
2. Start a soft spying RS232 or USB (depending on where you connected your
|
||||
joystick/wheel). I used ComPortSpy from fCoder (alpha version!)
|
||||
3. Play the effect, and watch what happens on the spy screen.
|
||||
|
||||
A few words about ComPortSpy:
|
||||
At first glance, this soft seems, hum, well... buggy. In fact, data appear with a few seconds latency. Personnaly, I restart it every time I play an effect.
|
||||
At first glance, this software seems, hum, well... buggy. In fact, data appear with a
|
||||
few seconds latency. Personally, I restart it every time I play an effect.
|
||||
Remember it's free (as in free beer) and alpha!
|
||||
|
||||
** URLS **
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ In the _init function, which is called either upon module load or when
|
|||
booting the kernel, it grabs the required resources (it should also check
|
||||
for the presence of the device).
|
||||
|
||||
Then it allocates a new input device structure with input_aloocate_device()
|
||||
Then it allocates a new input device structure with input_allocate_device()
|
||||
and sets up input bitfields. This way the device driver tells the other
|
||||
parts of the input systems what it is - what events can be generated or
|
||||
accepted by this input device. Our example device can only generate EV_KEY
|
||||
|
|
|
|||
|
|
@ -76,9 +76,9 @@
|
|||
* Title: "Conceptual Architecture of the Linux Kernel"
|
||||
Author: Ivan T. Bowman.
|
||||
URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a1.html
|
||||
Keywords: conceptual software arquitecture, extracted design,
|
||||
Keywords: conceptual software architecture, extracted design,
|
||||
reverse engineering, system structure.
|
||||
Description: Conceptual software arquitecture of the Linux kernel,
|
||||
Description: Conceptual software architecture of the Linux kernel,
|
||||
automatically extracted from the source code. Very detailed. Good
|
||||
figures. Gives good overall kernel understanding.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ all, distributions. There is, however, additional software that is
|
|||
required. The firmware used by the chip is the intellectual property
|
||||
of Broadcom and they have not given the bcm43xx team redistribution
|
||||
rights to this firmware. Since we cannot legally redistribute
|
||||
the firwmare we cannot include it with the driver. Furthermore, it
|
||||
the firmware we cannot include it with the driver. Furthermore, it
|
||||
cannot be placed in the downloadable archives of any distributing
|
||||
organization; therefore, the user is responsible for obtaining the
|
||||
firmware and placing it in the appropriate location so that the driver
|
||||
|
|
|
|||
|
|
@ -689,7 +689,7 @@ such as the AFS filesystem. This permits such a utility to:
|
|||
buffers manipulated directly.
|
||||
|
||||
To use the RxRPC facility, a kernel utility must still open an AF_RXRPC socket,
|
||||
bind an addess as appropriate and listen if it's to be a server socket, but
|
||||
bind an address as appropriate and listen if it's to be a server socket, but
|
||||
then it passes this to the kernel interface functions.
|
||||
|
||||
The kernel interface functions are as follows:
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
For in-depth information, you can consult:
|
||||
|
||||
o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
|
||||
Fom here you can also download some example application source code.
|
||||
From here you can also download some example application source code.
|
||||
|
||||
o The UDP-Lite HOWTO on
|
||||
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
|
||||
|
|
@ -223,7 +223,7 @@
|
|||
While it is important that such cases are dealt with correctly, they
|
||||
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
|
||||
performance over wireless (or generally noisy) links and thus smaller
|
||||
coverage lenghts are likely to be expected.
|
||||
coverage lengths are likely to be expected.
|
||||
|
||||
|
||||
V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING
|
||||
|
|
@ -259,7 +259,7 @@
|
|||
VI) IPTABLES
|
||||
|
||||
There is packet match support for UDP-Lite as well as support for the LOG target.
|
||||
If you copy and paste the following line into /etc/protcols,
|
||||
If you copy and paste the following line into /etc/protocols,
|
||||
|
||||
udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ resume=<swap_file_partition> resume_offset=<swap_file_offset>
|
|||
where <swap_file_partition> is the partition on which the swap file is located
|
||||
and <swap_file_offset> is the offset of the swap header determined by the
|
||||
application in 2) (of course, this step may be carried out automatically
|
||||
by the same application that determies the swap file's header offset using the
|
||||
by the same application that determines the swap file's header offset using the
|
||||
FIBMAP ioctl)
|
||||
|
||||
OR
|
||||
|
|
|
|||
|
|
@ -36,8 +36,8 @@ Causes of EEH Errors
|
|||
EEH was originally designed to guard against hardware failure, such
|
||||
as PCI cards dying from heat, humidity, dust, vibration and bad
|
||||
electrical connections. The vast majority of EEH errors seen in
|
||||
"real life" are due to eithr poorly seated PCI cards, or,
|
||||
unfortunately quite commonly, due device driver bugs, device firmware
|
||||
"real life" are due to either poorly seated PCI cards, or,
|
||||
unfortunately quite commonly, due to device driver bugs, device firmware
|
||||
bugs, and sometimes PCI card hardware bugs.
|
||||
|
||||
The most common software bug, is one that causes the device to
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ passed by the boot loader to the kernel at boot time. The device tree
|
|||
describes what devices are present on the board and how they are
|
||||
connected. The device tree can either be passed as a binary blob (as
|
||||
described in Documentation/powerpc/booting-without-of.txt), or passed
|
||||
by Open Firmare (IEEE 1275) compatible firmware using an OF compatible
|
||||
by Open Firmware (IEEE 1275) compatible firmware using an OF compatible
|
||||
client interface API.
|
||||
|
||||
This document specifies the requirements on the device-tree for mpc5200
|
||||
based boards. These requirements are above and beyond the details
|
||||
specified in either the OpenFirmware spec or booting-without-of.txt
|
||||
specified in either the Open Firmware spec or booting-without-of.txt
|
||||
|
||||
All new mpc5200-based boards are expected to match this document. In
|
||||
cases where this document is not sufficient to support a new board port,
|
||||
|
|
@ -73,8 +73,8 @@ match on the compatible list; the 'most compatible' driver should be
|
|||
selected.
|
||||
|
||||
The split between the MPC5200 and the MPC5200B leaves a bit of a
|
||||
connundrum. How should the compatible property be set up to provide
|
||||
maximum compatability information; but still acurately describe the
|
||||
conundrum. How should the compatible property be set up to provide
|
||||
maximum compatibility information; but still accurately describe the
|
||||
chip? For the MPC5200; the answer is easy. Most of the SoC devices
|
||||
originally appeared on the MPC5200. Since they didn't exist anywhere
|
||||
else; the 5200 compatible properties will contain only one item;
|
||||
|
|
@ -84,7 +84,7 @@ The 5200B is almost the same as the 5200, but not quite. It fixes
|
|||
silicon bugs and it adds a small number of enhancements. Most of the
|
||||
devices either provide exactly the same interface as on the 5200. A few
|
||||
devices have extra functions but still have a backwards compatible mode.
|
||||
To express this infomation as completely as possible, 5200B device trees
|
||||
To express this information as completely as possible, 5200B device trees
|
||||
should have two items in the compatible list;
|
||||
"mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended
|
||||
that 5200B device trees follow this convention (instead of only listing
|
||||
|
|
@ -199,7 +199,7 @@ ethernet@<addr> network mpc5200-fec MPC5200 ethernet device
|
|||
ata@<addr> ata mpc5200-ata IDE ATA interface
|
||||
i2c@<addr> i2c mpc5200-i2c I2C controller
|
||||
usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller
|
||||
xlb@<addr> xlb mpc5200-xlb XLB arbritrator
|
||||
xlb@<addr> xlb mpc5200-xlb XLB arbitrator
|
||||
|
||||
Important child node properties
|
||||
name type description
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ The following information is available in this file:
|
|||
list size to avoid SCSI malloc pool fragmentation.
|
||||
- Cleanup channel display in our /proc output.
|
||||
- Workaround duplicate device entries in the mid-layer
|
||||
devlice list during add-single-device.
|
||||
device list during add-single-device.
|
||||
|
||||
1.3.6 (March 28th, 2003)
|
||||
- Correct a double free in the Domain Validation code.
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ The following information is available in this file:
|
|||
- Add support for 2.5.X's scsi_report_device_reset().
|
||||
|
||||
6.2.34 (May 5th, 2003)
|
||||
- Fix locking regression instroduced in 6.2.29 that
|
||||
- Fix locking regression introduced in 6.2.29 that
|
||||
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.
|
||||
|
|
@ -264,7 +264,7 @@ The following information is available in this file:
|
|||
Option: tag_info:{{value[,value...]}[,{value[,value...]}...]}
|
||||
Definition: Set the per-target tagged queue depth on a
|
||||
per controller basis. Both controllers and targets
|
||||
may be ommitted indicating that they should retain
|
||||
may be omitted indicating that they should retain
|
||||
the default tag depth.
|
||||
Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32}
|
||||
On Controller 0
|
||||
|
|
@ -290,7 +290,7 @@ The following information is available in this file:
|
|||
-----------------------------------------------------------------
|
||||
Option: dv: {value[,value...]}
|
||||
Definition: Set Domain Validation Policy on a per-controller basis.
|
||||
Controllers may be ommitted indicating that
|
||||
Controllers may be omitted indicating that
|
||||
they should retain the default read streaming setting.
|
||||
Example: dv:{-1,0,,1,1,0}
|
||||
On Controller 0 leave DV at its default setting.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
versions older than 4.0 do not work with kernels 2.4.0 or later! If you
|
||||
try to compile your kernel with the wrong driver source, the
|
||||
compilation is aborted and you get a corresponding error message. This is
|
||||
no bug in the driver. It prevents you from using the wrong sourcecode
|
||||
no bug in the driver; it prevents you from using the wrong source code
|
||||
with the wrong kernel version.
|
||||
|
||||
Authors of this Driver
|
||||
|
|
@ -58,7 +58,7 @@
|
|||
5 Users' Manual
|
||||
5.1 Commandline Parameters
|
||||
5.2 Troubleshooting
|
||||
5.3 Bugreports
|
||||
5.3 Bug reports
|
||||
5.4 Support WWW-page
|
||||
6 References
|
||||
7 Credits to
|
||||
|
|
@ -71,13 +71,13 @@
|
|||
|
||||
1 Abstract
|
||||
----------
|
||||
This README-file describes the IBM SCSI-subsystem low level driver for
|
||||
Linux. The descriptions which were formerly kept in the source-code have
|
||||
been taken out to this file to easify the codes' readability. The driver
|
||||
This README-file describes the IBM SCSI-subsystem low level driver for
|
||||
Linux. The descriptions which were formerly kept in the source code have
|
||||
been taken out of this file to simplify the codes readability. The driver
|
||||
description has been updated, as most of the former description was already
|
||||
quite outdated. The history of the driver development is also kept inside
|
||||
here. Multiple historical developments have been summarized to shorten the
|
||||
textsize a bit. At the end of this file you can find a small manual for
|
||||
quite outdated. The history of the driver development is also kept inside
|
||||
here. Multiple historical developments have been summarized to shorten the
|
||||
text size a bit. At the end of this file you can find a small manual for
|
||||
this driver and hints to get it running on your machine.
|
||||
|
||||
2 Driver Description
|
||||
|
|
@ -186,7 +186,7 @@
|
|||
between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two
|
||||
busses and provides support for 30 logical devices at the same time, where
|
||||
in wide-addressing mode you can have 16 puns with 32 luns on each device.
|
||||
This section dexribes you the handling of devices on non-F/W adapters.
|
||||
This section describes the handling of devices on non-F/W adapters.
|
||||
Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter
|
||||
which means a lot of possible devices for such a small machine.
|
||||
|
||||
|
|
@ -209,10 +209,10 @@
|
|||
--------------------------------------------------------
|
||||
One consequence of information hiding is that the real (pun,lun)
|
||||
numbers are also hidden. The two possibilities to get around this problem
|
||||
is to offer fake pun/lun combinations to the operating system or to
|
||||
are to offer fake pun/lun combinations to the operating system or to
|
||||
delete the whole mapping of the adapter and to reassign the ldns, using
|
||||
the immediate assign command of the SCSI-subsystem for probing through
|
||||
all possible pun/lun combinations. a ldn is a "logical device number"
|
||||
all possible pun/lun combinations. An ldn is a "logical device number"
|
||||
which is used by IBM SCSI-subsystems to access some valid SCSI-device.
|
||||
At the beginning of the development of this driver, the following approach
|
||||
was used:
|
||||
|
|
@ -251,9 +251,9 @@
|
|||
lun>0 or to non-existing devices, in order to satisfy the subsystem, if
|
||||
there are less than 15 SCSI-devices connected. In the case of more than 15
|
||||
devices, the dynamical mapping goes active. If the get_scsi[][] reports a
|
||||
device to be existant, but it has no ldn assigned, it gets a ldn out of 7
|
||||
to 14. The numbers are assigned in cyclic order. Therefore it takes 8
|
||||
dynamical reassignments on the SCSI-devices, until a certain device
|
||||
device to be existent, but it has no ldn assigned, it gets an ldn out of 7
|
||||
to 14. The numbers are assigned in cyclic order, therefore it takes 8
|
||||
dynamical reassignments on the SCSI-devices until a certain device
|
||||
loses its ldn again. This assures that dynamical remapping is avoided
|
||||
during intense I/O between up to 15 SCSI-devices (means pun,lun
|
||||
combinations). A further advantage of this method is that people who
|
||||
|
|
@ -551,7 +551,7 @@
|
|||
than devices are available, they are assigned to non existing pun,lun
|
||||
combinations to satisfy the adapter. With this, the dynamical mapping
|
||||
was possible to implement. (For further info see the text in the
|
||||
source-code and in the description below. Read the description
|
||||
source code and in the description below. Read the description
|
||||
below BEFORE installing this driver on your system!)
|
||||
2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION.
|
||||
3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID
|
||||
|
|
@ -762,9 +762,9 @@
|
|||
- Michael Lang
|
||||
|
||||
Apr 23, 2000 (v3.2pre1)
|
||||
1) During a very long time, I collected a huge amount of bugreports from
|
||||
1) During a very long time, I collected a huge amount of bug reports from
|
||||
various people, trying really quite different things on their SCSI-
|
||||
PS/2s. Today, all these bugreports are taken into account and should be
|
||||
PS/2s. Today, all these bug reports are taken into account and should be
|
||||
mostly solved. The major topics were:
|
||||
- Driver crashes during boottime by no obvious reason.
|
||||
- Driver panics while the midlevel-SCSI-driver is trying to inquire
|
||||
|
|
@ -819,7 +819,7 @@
|
|||
- Michael Lang
|
||||
|
||||
July 17, 2000 (v3.2pre8)
|
||||
A long period of collecting bugreports from all corners of the world
|
||||
A long period of collecting bug reports from all corners of the world
|
||||
now lead to the following corrections to the code:
|
||||
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
|
||||
was that it is possible to disable Fast-SCSI for the external bus.
|
||||
|
|
@ -873,7 +873,7 @@
|
|||
July 26, 2000 (v3.2pre11)
|
||||
1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and
|
||||
a model 9595. Asking around in the community, nobody except of me has
|
||||
seen such errors. Weired, but I am trying to recompile everything on
|
||||
seen such errors. Weird, but I am trying to recompile everything on
|
||||
the model 9595. Maybe, as I use a specially modified gcc, that could
|
||||
cause problems. But, it was not the reason. The true background was,
|
||||
that the kernel was compiled for i386 and the 9595 has a 486DX-2.
|
||||
|
|
@ -886,7 +886,7 @@
|
|||
alive rotator during boottime. This makes sense, when no monitor is
|
||||
connected to the system. You can get rid of all display activity, if
|
||||
you do not use any parameter or just ibmmcascsi=activity, for the
|
||||
harddrive activity LED, existant on all PS/2, except models 8595-XXX.
|
||||
harddrive activity LED, existent on all PS/2, except models 8595-XXX.
|
||||
If no monitor is available, please use ibmmcascsi=display, which works
|
||||
fine together with the linuxinfo utility for the LED-panel.
|
||||
- Michael Lang
|
||||
|
|
@ -1115,7 +1115,7 @@
|
|||
If this really happens, do also send e-mail to the maintainer, as
|
||||
forced detection should be never necessary. Forced detection is in
|
||||
principal some flaw of the driver adapter detection and goes into
|
||||
bugreports.
|
||||
bug reports.
|
||||
Q: The driver screws up, if it starts to probe SCSI-devices, is there
|
||||
some way out of it?
|
||||
A: Yes, that was some recognition problem of the correct SCSI-adapter
|
||||
|
|
@ -1172,7 +1172,7 @@
|
|||
recommended version is 3.2 or later. Here, the F/W support is in
|
||||
a stable and reliable condition. Wide-addressing is in addition
|
||||
supported.
|
||||
Q: I get a Ooops message and something like "killing interrupt".
|
||||
Q: I get an Oops message and something like "killing interrupt".
|
||||
A: The reason for this is that the IBM SCSI-subsystem only sends a
|
||||
termination status back, if some error appeared. In former releases
|
||||
of the driver, it was not checked, if the termination status block
|
||||
|
|
@ -1213,21 +1213,21 @@
|
|||
problem. Not yet tried, but guessing that it could work. To get this,
|
||||
set unchecked_isa_dma argument of ibmmca.h from 0 to 1.
|
||||
|
||||
5.3 Bugreports
|
||||
5.3 Bug reports
|
||||
--------------
|
||||
If you really find bugs in the sourcecode or the driver will successfully
|
||||
If you really find bugs in the source code or the driver will successfully
|
||||
refuse to work on your machine, you should send a bug report to me. The
|
||||
best for this is to follow the instructions on the WWW-page for this
|
||||
driver. Fill out the bug-report form, placed on the WWW-page and ship it,
|
||||
so the bugs can be taken into account with maximum efforts. But, please
|
||||
do not send bug reports about this driver to Linus Torvalds or Leonard
|
||||
Zubkoff, as Linus is burried in E-Mail and Leonard is supervising all
|
||||
Zubkoff, as Linus is buried in E-Mail and Leonard is supervising all
|
||||
SCSI-drivers and won't have the time left to look inside every single
|
||||
driver to fix a bug and especially DO NOT send modified code to Linus
|
||||
Torvalds or Alan J. Cox which has not been checked here!!! They are both
|
||||
quite burried in E-mail (as me, sometimes, too) and one should first check
|
||||
quite buried in E-mail (as me, sometimes, too) and one should first check
|
||||
for problems on my local teststand. Recently, I got a lot of
|
||||
bugreports for errors in the ibmmca.c code, which I could not imagine, but
|
||||
bug reports for errors in the ibmmca.c code, which I could not imagine, but
|
||||
a look inside some Linux-distribution showed me quite often some modified
|
||||
code, which did no longer work on most other machines than the one of the
|
||||
modifier. Ok, so now that there is maintenance service available for this
|
||||
|
|
@ -1261,7 +1261,7 @@
|
|||
some e-mail directly, but at least with the same information as required by
|
||||
the formular.
|
||||
|
||||
If you have extensive bugreports, including Ooops messages and
|
||||
If you have extensive bug reports, including Oops messages and
|
||||
screen-shots, please feel free to send it directly to the address
|
||||
of the maintainer, too. The current address of the maintainer is:
|
||||
|
||||
|
|
@ -1318,7 +1318,7 @@
|
|||
detailed bug reports and ideas for this driver (and his
|
||||
patience ;-)).
|
||||
Alan J. Cox
|
||||
for his bugreports and his bold activities in cross-checking
|
||||
for his bug reports and his bold activities in cross-checking
|
||||
the driver-code with his teststand.
|
||||
|
||||
7.2 Sponsors & Supporters
|
||||
|
|
|
|||
|
|
@ -20,12 +20,12 @@ I2S
|
|||
===
|
||||
|
||||
I2S is a common 4 wire DAI used in HiFi, STB and portable devices. The Tx and
|
||||
Rx lines are used for audio transmision, whilst the bit clock (BCLK) and
|
||||
Rx lines are used for audio transmission, whilst the bit clock (BCLK) and
|
||||
left/right clock (LRC) synchronise the link. I2S is flexible in that either the
|
||||
controller or CODEC can drive (master) the BCLK and LRC clock lines. Bit clock
|
||||
usually varies depending on the sample rate and the master system clock
|
||||
(SYSCLK). LRCLK is the same as the sample rate. A few devices support separate
|
||||
ADC and DAC LRCLK's, this allows for similtanious capture and playback at
|
||||
ADC and DAC LRCLK's, this allows for simultaneous capture and playback at
|
||||
different sample rates.
|
||||
|
||||
I2S has several different operating modes:-
|
||||
|
|
@ -41,12 +41,12 @@ I2S has several different operating modes:-
|
|||
PCM
|
||||
===
|
||||
|
||||
PCM is another 4 wire interface, very similar to I2S, that can support a more
|
||||
PCM is another 4 wire interface, very similar to I2S, which can support a more
|
||||
flexible protocol. It has bit clock (BCLK) and sync (SYNC) lines that are used
|
||||
to synchronise the link whilst the Tx and Rx lines are used to transmit and
|
||||
receive the audio data. Bit clock usually varies depending on sample rate
|
||||
whilst sync runs at the sample rate. PCM also supports Time Division
|
||||
Multiplexing (TDM) in that several devices can use the bus similtaniuosly (This
|
||||
Multiplexing (TDM) in that several devices can use the bus simultaneously (this
|
||||
is sometimes referred to as network mode).
|
||||
|
||||
Common PCM operating modes:-
|
||||
|
|
|
|||
|
|
@ -2,20 +2,20 @@ Audio Clocking
|
|||
==============
|
||||
|
||||
This text describes the audio clocking terms in ASoC and digital audio in
|
||||
general. Note: Audio clocking can be complex !
|
||||
general. Note: Audio clocking can be complex!
|
||||
|
||||
|
||||
Master Clock
|
||||
------------
|
||||
|
||||
Every audio subsystem is driven by a master clock (sometimes refered to as MCLK
|
||||
Every audio subsystem is driven by a master clock (sometimes referred to as MCLK
|
||||
or SYSCLK). This audio master clock can be derived from a number of sources
|
||||
(e.g. crystal, PLL, CPU clock) and is responsible for producing the correct
|
||||
audio playback and capture sample rates.
|
||||
|
||||
Some master clocks (e.g. PLL's and CPU based clocks) are configuarble in that
|
||||
Some master clocks (e.g. PLL's and CPU based clocks) are configurable in that
|
||||
their speed can be altered by software (depending on the system use and to save
|
||||
power). Other master clocks are fixed at at set frequency (i.e. crystals).
|
||||
power). Other master clocks are fixed at a set frequency (i.e. crystals).
|
||||
|
||||
|
||||
DAI Clocks
|
||||
|
|
@ -44,7 +44,7 @@ This relationship depends on the codec or SoC CPU in particular. In general
|
|||
it's best to configure BCLK to the lowest possible speed (depending on your
|
||||
rate, number of channels and wordsize) to save on power.
|
||||
|
||||
It's also desireable to use the codec (if possible) to drive (or master) the
|
||||
It's also desirable to use the codec (if possible) to drive (or master) the
|
||||
audio clocks as it's usually gives more accurate sample rates than the CPU.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Optionally, codec drivers can also provide:-
|
|||
6) DAPM event handler.
|
||||
7) DAC Digital mute control.
|
||||
|
||||
It's probably best to use this guide in conjuction with the existing codec
|
||||
It's probably best to use this guide in conjunction with the existing codec
|
||||
driver code in sound/soc/codecs/
|
||||
|
||||
ASoC Codec driver breakdown
|
||||
|
|
@ -28,7 +28,7 @@ ASoC Codec driver breakdown
|
|||
1 - Codec DAI and PCM configuration
|
||||
-----------------------------------
|
||||
Each codec driver must have a struct snd_soc_codec_dai to define it's DAI and
|
||||
PCM's capablities and operations. This struct is exported so that it can be
|
||||
PCM's capabilities and operations. This struct is exported so that it can be
|
||||
registered with the core by your machine driver.
|
||||
|
||||
e.g.
|
||||
|
|
@ -67,7 +67,7 @@ EXPORT_SYMBOL_GPL(wm8731_dai);
|
|||
|
||||
2 - Codec control IO
|
||||
--------------------
|
||||
The codec can ususally be controlled via an I2C or SPI style interface (AC97
|
||||
The codec can usually be controlled via an I2C or SPI style interface (AC97
|
||||
combines control with data in the DAI). The codec drivers will have to provide
|
||||
functions to read and write the codec registers along with supplying a register
|
||||
cache:-
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ other PM systems.
|
|||
|
||||
DAPM is also completely transparent to all user space applications as all power
|
||||
switching is done within the ASoC core. No code changes or recompiling are
|
||||
required for user space applications. DAPM makes power switching descisions based
|
||||
required for user space applications. DAPM makes power switching decisions based
|
||||
upon any audio stream (capture/playback) activity and audio mixer settings
|
||||
within the device.
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ There are 4 power domains within DAPM
|
|||
Enabled and disabled when stream playback/capture is started and
|
||||
stopped respectively. e.g. aplay, arecord.
|
||||
|
||||
All DAPM power switching descisons are made automatically by consulting an audio
|
||||
All DAPM power switching decisions are made automatically by consulting an audio
|
||||
routing map of the whole machine. This map is specific to each machine and
|
||||
consists of the interconnections between every audio component (including
|
||||
internal codec components). All audio components that effect power are called
|
||||
|
|
|
|||
|
|
@ -2,18 +2,19 @@ ALSA SoC Layer
|
|||
==============
|
||||
|
||||
The overall project goal of the ALSA System on Chip (ASoC) layer is to provide
|
||||
better ALSA support for embedded system on chip procesors (e.g. pxa2xx, au1x00,
|
||||
better ALSA support for embedded system-on-chip processors (e.g. pxa2xx, au1x00,
|
||||
iMX, etc) and portable audio codecs. Currently there is some support in the
|
||||
kernel for SoC audio, however it has some limitations:-
|
||||
|
||||
* Currently, codec drivers are often tightly coupled to the underlying SoC
|
||||
cpu. This is not ideal and leads to code duplication i.e. Linux now has 4
|
||||
CPU. This is not ideal and leads to code duplication i.e. Linux now has 4
|
||||
different wm8731 drivers for 4 different SoC platforms.
|
||||
|
||||
* There is no standard method to signal user initiated audio events.
|
||||
e.g. Headphone/Mic insertion, Headphone/Mic detection after an insertion
|
||||
event. These are quite common events on portable devices and ofter require
|
||||
machine specific code to re route audio, enable amps etc after such an event.
|
||||
* There is no standard method to signal user initiated audio events (e.g.
|
||||
Headphone/Mic insertion, Headphone/Mic detection after an insertion
|
||||
event). These are quite common events on portable devices and often require
|
||||
machine specific code to re-route audio, enable amps, etc., after such an
|
||||
event.
|
||||
|
||||
* Current drivers tend to power up the entire codec when playing
|
||||
(or recording) audio. This is fine for a PC, but tends to waste a lot of
|
||||
|
|
@ -44,7 +45,7 @@ features :-
|
|||
signals the codec when to change power states.
|
||||
|
||||
* Machine specific controls: Allow machines to add controls to the sound card
|
||||
e.g. volume control for speaker amp.
|
||||
(e.g. volume control for speaker amp).
|
||||
|
||||
To achieve all this, ASoC basically splits an embedded audio system into 3
|
||||
components :-
|
||||
|
|
@ -57,7 +58,7 @@ components :-
|
|||
interface drivers (e.g. I2S, AC97, PCM) for that platform.
|
||||
|
||||
* Machine driver: The machine driver handles any machine specific controls and
|
||||
audio events. i.e. turing on an amp at start of playback.
|
||||
audio events (e.g. turning on an amp at start of playback).
|
||||
|
||||
|
||||
Documentation
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ struct snd_soc_ops {
|
|||
int (*trigger)(struct snd_pcm_substream *, int);
|
||||
};
|
||||
|
||||
The platform driver exports it's DMA functionailty via struct snd_soc_platform:-
|
||||
The platform driver exports its DMA functionality via struct snd_soc_platform:-
|
||||
|
||||
struct snd_soc_platform {
|
||||
char *name;
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Audio Pops and Clicks
|
|||
=====================
|
||||
|
||||
Pops and clicks are unwanted audio artifacts caused by the powering up and down
|
||||
of components within the audio subsystem. This is noticable on PC's when an
|
||||
of components within the audio subsystem. This is noticeable on PCs when an
|
||||
audio module is either loaded or unloaded (at module load time the sound card is
|
||||
powered up and causes a popping noise on the speakers).
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ Minimising Playback Pops and Clicks
|
|||
===================================
|
||||
|
||||
Playback pops in portable audio subsystems cannot be completely eliminated atm,
|
||||
however future audio codec hardware will have better pop and click supression.
|
||||
however future audio codec hardware will have better pop and click suppression.
|
||||
Pops can be reduced within playback by powering the audio components in a
|
||||
specific order. This order is different for startup and shutdown and follows
|
||||
some basic rules:-
|
||||
|
|
@ -33,7 +33,7 @@ Minimising Capture Pops and Clicks
|
|||
==================================
|
||||
|
||||
Capture artifacts are somewhat easier to get rid as we can delay activating the
|
||||
ADC until all the pops have occured. This follows similar power rules to
|
||||
ADC until all the pops have occurred. This follows similar power rules to
|
||||
playback in that components are powered in a sequence depending upon stream
|
||||
startup or shutdown.
|
||||
|
||||
|
|
|
|||
|
|
@ -1035,7 +1035,7 @@ enable it if necessary to avoid overheating.
|
|||
|
||||
An enabled fan in level "auto" may stop spinning if the EC decides the
|
||||
ThinkPad is cool enough and doesn't need the extra airflow. This is
|
||||
normal, and the EC will spin the fan up if the varios thermal readings
|
||||
normal, and the EC will spin the fan up if the various thermal readings
|
||||
rise too much.
|
||||
|
||||
On the X40, this seems to depend on the CPU and HDD temperatures.
|
||||
|
|
|
|||
|
|
@ -851,7 +851,7 @@ config KEXEC
|
|||
help
|
||||
kexec is a system call that implements the ability to shutdown your
|
||||
current kernel, and to start another kernel. It is like a reboot
|
||||
but it is indepedent of the system firmware. And like a reboot
|
||||
but it is independent of the system firmware. And like a reboot
|
||||
you can start any kernel with it, not just Linux.
|
||||
|
||||
It is an ongoing process to be certain the hardware in a machine
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@ config CMDLINE
|
|||
|
||||
endmenu
|
||||
|
||||
menu "Power managment options"
|
||||
menu "Power management options"
|
||||
|
||||
menu "CPU Frequency scaling"
|
||||
|
||||
|
|
|
|||
|
|
@ -613,85 +613,86 @@ config I_ENTRY_L1
|
|||
bool "Locate interrupt entry code in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, interrupt entry code (STORE/RESTORE CONTEXT) is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config EXCPT_IRQ_SYSC_L1
|
||||
bool "Locate entire ASM lowlevel excepetion / interrupt - Syscall and CPLB handler code in L1 Memory"
|
||||
bool "Locate entire ASM lowlevel exception / interrupt - Syscall and CPLB handler code in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled entire ASM lowlevel exception and interrupt entry code (STORE/RESTORE CONTEXT) is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the entire ASM lowlevel exception and interrupt entry code
|
||||
(STORE/RESTORE CONTEXT) is linked into L1 instruction memory.
|
||||
(less latency)
|
||||
|
||||
config DO_IRQ_L1
|
||||
bool "Locate frequently called do_irq dispatcher function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled frequently called do_irq dispatcher function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the frequently called do_irq dispatcher function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config CORE_TIMER_IRQ_L1
|
||||
bool "Locate frequently called timer_interrupt() function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled frequently called timer_interrupt() function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the frequently called timer_interrupt() function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config IDLE_L1
|
||||
bool "Locate frequently idle function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled frequently called idle function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the frequently called idle function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config SCHEDULE_L1
|
||||
bool "Locate kernel schedule function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled frequently called kernel schedule is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the frequently called kernel schedule is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config ARITHMETIC_OPS_L1
|
||||
bool "Locate kernel owned arithmetic functions in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled arithmetic functions are linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, arithmetic functions are linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config ACCESS_OK_L1
|
||||
bool "Locate access_ok function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled access_ok function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the access_ok function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config MEMSET_L1
|
||||
bool "Locate memset function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled memset function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the memset function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config MEMCPY_L1
|
||||
bool "Locate memcpy function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled memcpy function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the memcpy function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config SYS_BFIN_SPINLOCK_L1
|
||||
bool "Locate sys_bfin_spinlock function in L1 Memory"
|
||||
default y
|
||||
help
|
||||
If enabled sys_bfin_spinlock function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, sys_bfin_spinlock function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config IP_CHECKSUM_L1
|
||||
bool "Locate IP Checksum function in L1 Memory"
|
||||
default n
|
||||
help
|
||||
If enabled IP Checksum function is linked
|
||||
into L1 instruction memory.(less latency)
|
||||
If enabled, the IP Checksum function is linked
|
||||
into L1 instruction memory. (less latency)
|
||||
|
||||
config CACHELINE_ALIGNED_L1
|
||||
bool "Locate cacheline_aligned data to L1 Data Memory"
|
||||
|
|
@ -699,24 +700,24 @@ config CACHELINE_ALIGNED_L1
|
|||
default n if BF54x
|
||||
depends on !BF531
|
||||
help
|
||||
If enabled cacheline_anligned data is linked
|
||||
into L1 data memory.(less latency)
|
||||
If enabled, cacheline_anligned data is linked
|
||||
into L1 data memory. (less latency)
|
||||
|
||||
config SYSCALL_TAB_L1
|
||||
bool "Locate Syscall Table L1 Data Memory"
|
||||
default n
|
||||
depends on !BF531
|
||||
help
|
||||
If enabled the Syscall LUT is linked
|
||||
into L1 data memory.(less latency)
|
||||
If enabled, the Syscall LUT is linked
|
||||
into L1 data memory. (less latency)
|
||||
|
||||
config CPLB_SWITCH_TAB_L1
|
||||
bool "Locate CPLB Switch Tables L1 Data Memory"
|
||||
default n
|
||||
depends on !BF531
|
||||
help
|
||||
If enabled the CPLB Switch Tables are linked
|
||||
into L1 data memory.(less latency)
|
||||
If enabled, the CPLB Switch Tables are linked
|
||||
into L1 data memory. (less latency)
|
||||
|
||||
endmenu
|
||||
|
||||
|
|
@ -1029,13 +1030,13 @@ config DEBUG_HWERR
|
|||
from.
|
||||
|
||||
config DEBUG_ICACHE_CHECK
|
||||
bool "Check Instruction cache coherancy"
|
||||
bool "Check Instruction cache coherency"
|
||||
depends on DEBUG_KERNEL
|
||||
depends on DEBUG_HWERR
|
||||
help
|
||||
Say Y here if you are getting wierd unexplained errors. This will
|
||||
ensure that icache is what SDRAM says it should be, by doing a
|
||||
byte wise comparision between SDRAM and instruction cache. This
|
||||
Say Y here if you are getting weird unexplained errors. This will
|
||||
ensure that icache is what SDRAM says it should be by doing a
|
||||
byte wise comparison between SDRAM and instruction cache. This
|
||||
also relocates the irq_panic() function to L1 memory, (which is
|
||||
un-cached).
|
||||
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ config ETRAX_LED7G
|
|||
set this to same as CONFIG_ETRAX_LED1G (normally 2).
|
||||
|
||||
config ETRAX_LED8Y
|
||||
int "Eigth yellow LED bit"
|
||||
int "Eighth yellow LED bit"
|
||||
depends on ETRAX_CSP0_LEDS
|
||||
default "2"
|
||||
help
|
||||
|
|
|
|||
|
|
@ -452,9 +452,9 @@ config IA64_PALINFO
|
|||
config IA64_MC_ERR_INJECT
|
||||
tristate "MC error injection support"
|
||||
help
|
||||
Selets whether support for MC error injection. By enabling the
|
||||
support, kernel provide sysfs interface for user application to
|
||||
call MC error injection PAL procedure to inject various errors.
|
||||
Adds support for MC error injection. If enabled, the kernel
|
||||
will provide a sysfs interface for user applications to
|
||||
call MC error injection PAL procedures to inject various errors.
|
||||
This is a useful tool for MCA testing.
|
||||
|
||||
If you're unsure, do not select this option.
|
||||
|
|
@ -491,7 +491,7 @@ config KEXEC
|
|||
but it is independent of the system firmware. And like a reboot
|
||||
you can start any kernel with it, not just Linux.
|
||||
|
||||
The name comes from the similiarity to the exec system call.
|
||||
The name comes from the similarity to the exec system call.
|
||||
|
||||
It is an ongoing process to be certain the hardware in a machine
|
||||
is properly shutdown, so do not be surprised if this code does not
|
||||
|
|
|
|||
|
|
@ -1812,7 +1812,7 @@ config KEXEC
|
|||
but it is independent of the system firmware. And like a reboot
|
||||
you can start any kernel with it, not just Linux.
|
||||
|
||||
The name comes from the similiarity to the exec system call.
|
||||
The name comes from the similarity to the exec system call.
|
||||
|
||||
It is an ongoing process to be certain the hardware in a machine
|
||||
is properly shutdown, so do not be surprised if this code does not
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ config PPC_PMI
|
|||
depends on PPC_IBM_CELL_BLADE
|
||||
help
|
||||
PMI (Platform Management Interrupt) is a way to
|
||||
communicate with the BMC (Baseboard Mangement Controller).
|
||||
communicate with the BMC (Baseboard Management Controller).
|
||||
It is used in some IBM Cell blades.
|
||||
default m
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ config DEFCONFIG_LIST
|
|||
option defconfig_list
|
||||
default "arch/$ARCH/defconfig"
|
||||
|
||||
# UML uses the generic IRQ sugsystem
|
||||
# UML uses the generic IRQ subsystem
|
||||
config GENERIC_HARDIRQS
|
||||
bool
|
||||
default y
|
||||
|
|
|
|||
|
|
@ -278,7 +278,7 @@ config I2C_IXP2000
|
|||
depends on ARCH_IXP2000
|
||||
select I2C_ALGOBIT
|
||||
help
|
||||
Say Y here if you have an Intel IXP2000(2400, 2800, 2850) based
|
||||
Say Y here if you have an Intel IXP2000 (2400, 2800, 2850) based
|
||||
system and are using GPIO lines for an I2C bus.
|
||||
|
||||
This support is also available as a module. If so, the module
|
||||
|
|
@ -293,8 +293,8 @@ config I2C_POWERMAC
|
|||
default y
|
||||
help
|
||||
This exposes the various PowerMac i2c interfaces to the linux i2c
|
||||
layer and to userland. It is used by various drivers on the powemac
|
||||
platform, thus should generally be enabled.
|
||||
layer and to userland. It is used by various drivers on the PowerMac
|
||||
platform, and should generally be enabled.
|
||||
|
||||
This support is also available as a module. If so, the module
|
||||
will be called i2c-powermac.
|
||||
|
|
@ -438,12 +438,12 @@ config I2C_SIMTEC
|
|||
tristate "Simtec Generic I2C interface"
|
||||
select I2C_ALGOBIT
|
||||
help
|
||||
If you say yes to this option, support will be inclyded for
|
||||
If you say yes to this option, support will be included for
|
||||
the Simtec Generic I2C interface. This driver is for the
|
||||
simple I2C bus used on newer Simtec products for general
|
||||
I2C, such as DDC on the Simtec BBD2016A.
|
||||
|
||||
This driver can also be build as a module. If so, the module
|
||||
This driver can also be built as a module. If so, the module
|
||||
will be called i2c-simtec.
|
||||
|
||||
config SCx200_I2C
|
||||
|
|
|
|||
|
|
@ -70,9 +70,9 @@ config INPUT_WISTRON_BTNS
|
|||
select LEDS_CLASS
|
||||
select CHECK_SIGNATURE
|
||||
help
|
||||
Say Y here for support of Winstron laptop button interface, used on
|
||||
Say Y here for support of Wistron laptop button interfaces, used on
|
||||
laptops of various brands, including Acer and Fujitsu-Siemens. If
|
||||
available, mail and wifi leds will be controlable via /sys/class/leds.
|
||||
available, mail and wifi LEDs will be controllable via /sys/class/leds.
|
||||
|
||||
To compile this driver as a module, choose M here: the module will
|
||||
be called wistron_btns.
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ config MFD_SM501
|
|||
---help---
|
||||
This is the core driver for the Silicon Motion SM501 multimedia
|
||||
companion chip. This device is a multifunction device which may
|
||||
provide numerous interfaces including USB host controller USB gadget,
|
||||
Asyncronous Serial ports, Audio functions and a dual display video
|
||||
provide numerous interfaces including USB host controller, USB gadget,
|
||||
asynchronous serial ports, audio functions, and a dual display video
|
||||
interface. The device may be connected by PCI or local bus with
|
||||
varying functions enabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -180,7 +180,7 @@ config THINKPAD_ACPI
|
|||
For more information about this driver see
|
||||
<file:Documentation/thinkpad-acpi.txt> and <http://ibm-acpi.sf.net/> .
|
||||
|
||||
This driver was formely known as ibm-acpi.
|
||||
This driver was formerly known as ibm-acpi.
|
||||
|
||||
If you have an IBM or Lenovo ThinkPad laptop, say Y or M here.
|
||||
|
||||
|
|
@ -214,7 +214,7 @@ config THINKPAD_ACPI_BAY
|
|||
default y
|
||||
---help---
|
||||
Allows the thinkpad_acpi driver to handle removable bays. It will
|
||||
eletrically disable the device in the bay, and also generate
|
||||
electrically disable the device in the bay, and also generate
|
||||
notifications when the bay lever is ejected or inserted.
|
||||
|
||||
If you are not sure, say Y here.
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ config MTD_PHYSMAP_BANKWIDTH
|
|||
help
|
||||
This is the total width of the data bus of the flash devices
|
||||
in octets. For example, if you have a data bus width of 32
|
||||
bits, you would set the bus width octect value to 4. This is
|
||||
bits, you would set the bus width octet value to 4. This is
|
||||
used internally by the CFI drivers.
|
||||
Ignore this option if you use run-time physmap configuration
|
||||
(i.e., run-time calling physmap_configure()).
|
||||
|
|
@ -73,12 +73,12 @@ config MTD_PMC_MSP_EVM
|
|||
depends on PMC_MSP && MTD_CFI
|
||||
select MTD_PARTITIONS
|
||||
help
|
||||
This provides a 'mapping' driver which support the way
|
||||
in which user-programmable flash chips are connected on the
|
||||
PMC-Sierra MSP eval/demo boards
|
||||
This provides a 'mapping' driver which supports the way
|
||||
in which user-programmable flash chips are connected on the
|
||||
PMC-Sierra MSP eval/demo boards.
|
||||
|
||||
choice
|
||||
prompt "Maximum mappable memory avialable for flash IO"
|
||||
prompt "Maximum mappable memory available for flash IO"
|
||||
depends on MTD_PMC_MSP_EVM
|
||||
default MSP_FLASH_MAP_LIMIT_32M
|
||||
|
||||
|
|
|
|||
|
|
@ -855,7 +855,7 @@ config BFIN_MAC_USE_L1
|
|||
depends on BFIN_MAC && BF537
|
||||
default y
|
||||
help
|
||||
To get maximum network performace, you should use L1 memory as rx/tx buffers.
|
||||
To get maximum network performance, you should use L1 memory as rx/tx buffers.
|
||||
Say N here if you want to reserve L1 memory for other uses.
|
||||
|
||||
config BFIN_TX_DESC_NUM
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ config RTC_DRV_TWL92330
|
|||
depends on MENELAUS
|
||||
help
|
||||
If you say yes here you get support for the RTC on the
|
||||
TWL92330 "Menelaus" power mangement chip, used with OMAP2
|
||||
TWL92330 "Menelaus" power management chip, used with OMAP2
|
||||
platforms. The support is integrated with the rest of
|
||||
the Menelaus driver; it's not separate module.
|
||||
|
||||
|
|
|
|||
|
|
@ -62,11 +62,11 @@ config SERIAL_8250_CONSOLE
|
|||
kernel will automatically use the first serial line, /dev/ttyS0, as
|
||||
system console.
|
||||
|
||||
you can set that using a kernel command line option such as
|
||||
You can set that using a kernel command line option such as
|
||||
"console=uart8250,io,0x3f8,9600n8"
|
||||
"console=uart8250,mmio,0xff5e0000,115200n8".
|
||||
and it will switch to normal serial console when correponding port is
|
||||
ready.
|
||||
and it will switch to normal serial console when the corresponding
|
||||
port is ready.
|
||||
"earlycon=uart8250,io,0x3f8,9600n8"
|
||||
"earlycon=uart8250,mmio,0xff5e0000,115200n8".
|
||||
it will not only setup early console.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
#
|
||||
# USB Imageing devices configuration
|
||||
# USB Imaging devices configuration
|
||||
#
|
||||
comment "USB Imaging devices"
|
||||
depends on USB
|
||||
|
|
|
|||
|
|
@ -527,7 +527,7 @@ config USB_SERIAL_CYBERJACK
|
|||
depends on USB_SERIAL && EXPERIMENTAL
|
||||
---help---
|
||||
Say Y here if you want to use a cyberJack pinpad/e-com USB chipcard
|
||||
reader. This is an interface to ISO 7816 compatible contactbased
|
||||
reader. This is an interface to ISO 7816 compatible contact-based
|
||||
chipcards, e.g. GSM SIMs.
|
||||
|
||||
To compile this driver as a module, choose M here: the
|
||||
|
|
|
|||
|
|
@ -661,7 +661,7 @@ config FB_HECUBA
|
|||
help
|
||||
This enables support for the Hecuba board. This driver was tested
|
||||
with an E-Ink 800x600 display and x86 SBCs through a 16 bit GPIO
|
||||
interface (8 bit data, 4 bit control). If you anticpate using
|
||||
interface (8 bit data, 4 bit control). If you anticipate using
|
||||
this driver, say Y or M; otherwise say N. You must specify the
|
||||
GPIO IO address to be used for setting control and data.
|
||||
|
||||
|
|
@ -815,7 +815,7 @@ config FB_XVR500
|
|||
help
|
||||
This is the framebuffer device for the Sun XVR-500 and similar
|
||||
graphics cards based upon the 3DLABS Wildcat chipset. The driver
|
||||
only works on sparc64 systems where the system firwmare has
|
||||
only works on sparc64 systems where the system firmware has
|
||||
mostly initialized the card already. It is treated as a
|
||||
completely dumb framebuffer device.
|
||||
|
||||
|
|
@ -828,7 +828,7 @@ config FB_XVR2500
|
|||
help
|
||||
This is the framebuffer device for the Sun XVR-2500 and similar
|
||||
graphics cards based upon the 3DLABS Wildcat chipset. The driver
|
||||
only works on sparc64 systems where the system firwmare has
|
||||
only works on sparc64 systems where the system firmware has
|
||||
mostly initialized the card already. It is treated as a
|
||||
completely dumb framebuffer device.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ config VGACON_SOFT_SCROLLBACK
|
|||
The scrollback buffer of the standard VGA console is located in
|
||||
the VGA RAM. The size of this RAM is fixed and is quite small.
|
||||
If you require a larger scrollback buffer, this can be placed in
|
||||
System RAM which is dynamically allocated during intialization.
|
||||
System RAM which is dynamically allocated during initialization.
|
||||
Placing the scrollback buffer in System RAM will slightly slow
|
||||
down the console.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ config FB_OMAP
|
|||
Frame buffer driver for OMAP based boards.
|
||||
|
||||
config FB_OMAP_BOOTLOADER_INIT
|
||||
bool "Check bootloader initializaion"
|
||||
bool "Check bootloader initialization"
|
||||
depends on FB_OMAP
|
||||
help
|
||||
Say Y here if you want to enable checking if the bootloader has
|
||||
|
|
|
|||
|
|
@ -27,5 +27,5 @@ config NET_9P_DEBUG
|
|||
bool "Debug information"
|
||||
depends on NET_9P
|
||||
help
|
||||
Say Y if you want the 9P subsistem to log debug information.
|
||||
Say Y if you want the 9P subsystem to log debug information.
|
||||
|
||||
|
|
|
|||
|
|
@ -560,7 +560,7 @@ config TCP_CONG_ILLINOIS
|
|||
depends on EXPERIMENTAL
|
||||
default n
|
||||
---help---
|
||||
TCP-Illinois is a sender-side modificatio of TCP Reno for
|
||||
TCP-Illinois is a sender-side modification of TCP Reno for
|
||||
high speed long delay links. It uses round-trip-time to
|
||||
adjust the alpha and beta parameters to achieve a higher average
|
||||
throughput and maintain fairness.
|
||||
|
|
|
|||
Loading…
Reference in a new issue