Documentation: remove duplicated words
Remove many duplicated words under Documentation/ and do other small
cleanups.
Examples:
"and and" --> "and"
"in in" --> "in"
"the the" --> "the"
"the the" --> "to the"
...
Signed-off-by: Paolo Ornati <ornati@fastwebnet.it>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
Paolo Ornati
Adrian Bunk
parent
53cb47268e
commit
670e9f34ee
52 changed files with 61 additions and 62 deletions
|
|
@ -107,7 +107,7 @@ The query is performed via a call to pci_set_dma_mask():
|
|||
|
||||
int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask);
|
||||
|
||||
The query for consistent allocations is performed via a a call to
|
||||
The query for consistent allocations is performed via a call to
|
||||
pci_set_consistent_dma_mask():
|
||||
|
||||
int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask);
|
||||
|
|
|
|||
|
|
@ -1400,7 +1400,7 @@ and other resources, etc.
|
|||
<listitem>
|
||||
<para>
|
||||
When it's known that HBA is in ready state but ATA/ATAPI
|
||||
device in in unknown state, reset only device.
|
||||
device is in unknown state, reset only device.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
|
|
|||
|
|
@ -740,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
|
|||
<title>Synchronous I/O Support</title>
|
||||
|
||||
<para>Synchronous requests involve the kernel blocking
|
||||
until until the user mode request completes, either by
|
||||
until the user mode request completes, either by
|
||||
finishing successfully or by reporting an error.
|
||||
In most cases this is the simplest way to use usbfs,
|
||||
although as noted above it does prevent performing I/O
|
||||
|
|
|
|||
|
|
@ -750,7 +750,7 @@ Or, for those who prefer a side-by-side listing:
|
|||
|
||||
Either way, the differences are quite small. Read-side locking moves
|
||||
to rcu_read_lock() and rcu_read_unlock, update-side locking moves from
|
||||
from a reader-writer lock to a simple spinlock, and a synchronize_rcu()
|
||||
a reader-writer lock to a simple spinlock, and a synchronize_rcu()
|
||||
precedes the kfree().
|
||||
|
||||
However, there is one potential catch: the read-side and update-side
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ Some new queue property settings:
|
|||
Sets two variables that limit the size of the request.
|
||||
|
||||
- The request queue's max_sectors, which is a soft size in
|
||||
in units of 512 byte sectors, and could be dynamically varied
|
||||
units of 512 byte sectors, and could be dynamically varied
|
||||
by the core kernel.
|
||||
|
||||
- The request queue's max_hw_sectors, which is a hard limit
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ the two.
|
|||
|
||||
The PCI bus layer freely accesses the fields of struct device. It knows about
|
||||
the structure of struct pci_dev, and it should know the structure of struct
|
||||
device. Individual PCI device drivers that have been converted the the current
|
||||
device. Individual PCI device drivers that have been converted to the current
|
||||
driver model generally do not and should not touch the fields of struct device,
|
||||
unless there is a strong compelling reason to do so.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ int verify_area(int type, const void * addr, unsigned long size)
|
|||
function (which has since been replaced by access_ok()).
|
||||
|
||||
This function verified that the memory area starting at address
|
||||
addr and of size size was accessible for the operation specified
|
||||
'addr' and of size 'size' was accessible for the operation specified
|
||||
in type (read or write). To do this, verify_read had to look up the
|
||||
virtual memory area (vma) that contained the address addr. In the
|
||||
normal case (correctly working program), this test was successful.
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ from the console layer before unloading the driver. The VGA driver cannot be
|
|||
unloaded if it is still bound to the console layer. (See
|
||||
Documentation/console/console.txt for more information).
|
||||
|
||||
This is more complicated in the case of the the framebuffer console (fbcon),
|
||||
This is more complicated in the case of the framebuffer console (fbcon),
|
||||
because fbcon is an intermediate layer between the console and the drivers:
|
||||
|
||||
console ---> fbcon ---> fbdev drivers ---> hardware
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ own descendent. Moreover, there is exactly one cross-directory rename
|
|||
|
||||
Consider the object blocking the cross-directory rename. One
|
||||
of its descendents is locked by cross-directory rename (otherwise we
|
||||
would again have an infinite set of of contended objects). But that
|
||||
would again have an infinite set of contended objects). But that
|
||||
means that cross-directory rename is taking locks out of order. Due
|
||||
to (2) the order hadn't changed since we had acquired filesystem lock.
|
||||
But locking rules for cross-directory rename guarantee that we do not
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ the fdtable structure -
|
|||
2. Reading of the fdtable as described above must be protected
|
||||
by rcu_read_lock()/rcu_read_unlock().
|
||||
|
||||
3. For any update to the the fd table, files->file_lock must
|
||||
3. For any update to the fd table, files->file_lock must
|
||||
be held.
|
||||
|
||||
4. To look up the file structure given an fd, a reader
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ FILES
|
|||
|
||||
|
||||
/wbox
|
||||
The CPU to SPU communation mailbox. It is write-only can can be written
|
||||
The CPU to SPU communation mailbox. It is write-only and can be written
|
||||
in units of 32 bits. If the mailbox is full, write() will block and
|
||||
poll can be used to wait for it becoming empty again. The possible
|
||||
operations on an open wbox file are: write(2) If a count smaller than
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ size: The limit of allocated bytes for this tmpfs instance. The
|
|||
nr_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE.
|
||||
nr_inodes: The maximum number of inodes for this instance. The default
|
||||
is half of the number of your physical RAM pages, or (on a
|
||||
a machine with highmem) the number of lowmem RAM pages,
|
||||
machine with highmem) the number of lowmem RAM pages,
|
||||
whichever is the lower.
|
||||
|
||||
These parameters accept a suffix k, m or g for kilo, mega and giga and
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ iocharset=name -- Character set to use for converting between the
|
|||
you should consider the following option instead.
|
||||
|
||||
utf8=<bool> -- UTF-8 is the filesystem safe version of Unicode that
|
||||
is used by the console. It can be be enabled for the
|
||||
is used by the console. It can be enabled for the
|
||||
filesystem with this option. If 'uni_xlate' gets set,
|
||||
UTF-8 gets disabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -410,7 +410,7 @@ otherwise noted.
|
|||
|
||||
put_link: called by the VFS to release resources allocated by
|
||||
follow_link(). The cookie returned by follow_link() is passed
|
||||
to to this method as the last parameter. It is used by
|
||||
to this method as the last parameter. It is used by
|
||||
filesystems such as NFS where page cache is not stable
|
||||
(i.e. page that was installed when the symbolic link walk
|
||||
started might not be in the page cache at the end of the
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ related kernel services:
|
|||
(*) __debug_mmu.iamr[]
|
||||
(*) __debug_mmu.damr[]
|
||||
|
||||
These receive the current IAMR and DAMR contents. These can be viewed with with the _amr
|
||||
These receive the current IAMR and DAMR contents. These can be viewed with the _amr
|
||||
GDB macro:
|
||||
|
||||
(gdb) _amr
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ to initialize the system view of the time during boot.
|
|||
Because we wanted to minimize the impact on existing user-level apps using
|
||||
the CMOS clock, we decided to expose an API that was very similar to the one
|
||||
used today with the legacy RTC driver (driver/char/rtc.c). However, because
|
||||
EFI provides a simpler services, not all all ioctl() are available. Also
|
||||
EFI provides a simpler services, not all ioctl() are available. Also
|
||||
new ioctl()s have been introduced for things that EFI provides but not the
|
||||
legacy.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ by locks is indeterminate, including linked lists.
|
|||
---
|
||||
|
||||
The complicated ia64 MCA process. All of this is mandated by Intel's
|
||||
specification for ia64 SAL, error recovery and and unwind, it is not as
|
||||
specification for ia64 SAL, error recovery and unwind, it is not as
|
||||
if we have a choice here.
|
||||
|
||||
* MCA occurs on one cpu, usually due to a double bit memory error.
|
||||
|
|
@ -94,7 +94,7 @@ if we have a choice here.
|
|||
|
||||
INIT is less complicated than MCA. Pressing the nmi button or using
|
||||
the equivalent command on the management console sends INIT to all
|
||||
cpus. SAL picks one one of the cpus as the monarch and the rest are
|
||||
cpus. SAL picks one of the cpus as the monarch and the rest are
|
||||
slaves. All the OS INIT handlers are entered at approximately the same
|
||||
time. The OS monarch prints the state of all tasks and returns, after
|
||||
which the slaves return and the system resumes.
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ generated in the kernel straight to the program, with timestamps. The
|
|||
API is still evolving, but should be useable now. It's described in
|
||||
section 5.
|
||||
|
||||
This should be the way for GPM and X to get keyboard and mouse mouse
|
||||
This should be the way for GPM and X to get keyboard and mouse
|
||||
events. It allows for multihead in X without any specific multihead
|
||||
kernel support. The event codes are the same on all architectures and
|
||||
are hardware independent.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Structure T30_s description:
|
|||
If the HL-driver receives ISDN_CMD_FAXCMD, all needed information
|
||||
is in this struct set by the LL.
|
||||
To signal information to the LL, the HL-driver has to set the
|
||||
the parameters and use ISDN_STAT_FAXIND.
|
||||
parameters and use ISDN_STAT_FAXIND.
|
||||
(Please refer to INTERFACE)
|
||||
|
||||
Structure T30_s:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
$Id: README.hysdn,v 1.3.6.1 2001/02/10 14:41:19 kai Exp $
|
||||
The hysdn driver has been written by
|
||||
by Werner Cornelius (werner@isdn4linux.de or werner@titro.de)
|
||||
Werner Cornelius (werner@isdn4linux.de or werner@titro.de)
|
||||
for Hypercope GmbH Aachen Germany. Hypercope agreed to publish this driver
|
||||
under the GNU General Public License.
|
||||
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ If die() is called, and it happens to be a thread with pid 0 or 1, or die()
|
|||
is called inside interrupt context or die() is called and panic_on_oops is set,
|
||||
the system will boot into the dump-capture kernel.
|
||||
|
||||
On powererpc systems when a soft-reset is generated, die() is called by all cpus and the system system will boot into the dump-capture kernel.
|
||||
On powererpc systems when a soft-reset is generated, die() is called by all cpus and the system will boot into the dump-capture kernel.
|
||||
|
||||
For testing purposes, you can trigger a crash by using "ALT-SysRq-c",
|
||||
"echo c > /proc/sysrq-trigger or write a module to force the panic.
|
||||
|
|
|
|||
|
|
@ -671,7 +671,7 @@ The keyctl syscall functions are:
|
|||
|
||||
Note that this setting is inherited across fork/exec.
|
||||
|
||||
[1] The default default is: the thread keyring if there is one, otherwise
|
||||
[1] The default is: the thread keyring if there is one, otherwise
|
||||
the process keyring if there is one, otherwise the session keyring if
|
||||
there is one, otherwise the user default session keyring.
|
||||
|
||||
|
|
|
|||
|
|
@ -415,7 +415,7 @@ switch to another mode once Linux has started.
|
|||
|
||||
The first 3 parameters of this sub-option should be obvious: <xres>,
|
||||
<yres> and <depth> give the dimensions of the screen and the number of
|
||||
planes (depth). The depth is is the logarithm to base 2 of the number
|
||||
planes (depth). The depth is the logarithm to base 2 of the number
|
||||
of colors possible. (Or, the other way round: The number of colors is
|
||||
2^depth).
|
||||
|
||||
|
|
|
|||
|
|
@ -670,7 +670,7 @@ effectively random order, despite the write barrier issued by CPU 1:
|
|||
|
||||
|
||||
In the above example, CPU 2 perceives that B is 7, despite the load of *C
|
||||
(which would be B) coming after the the LOAD of C.
|
||||
(which would be B) coming after the LOAD of C.
|
||||
|
||||
If, however, a data dependency barrier were to be placed between the load of C
|
||||
and the load of *C (ie: B) on CPU 2:
|
||||
|
|
|
|||
|
|
@ -1023,7 +1023,7 @@ Changing a Bond's Configuration
|
|||
files located in /sys/class/net/<bond name>/bonding
|
||||
|
||||
The names of these files correspond directly with the command-
|
||||
line parameters described elsewhere in in this file, and, with the
|
||||
line parameters described elsewhere in this file, and, with the
|
||||
exception of arp_ip_target, they accept the same values. To see the
|
||||
current setting, simply cat the appropriate file.
|
||||
|
||||
|
|
|
|||
|
|
@ -684,7 +684,7 @@ ethernet@crystal.cirrus.com) and request that you be registered for automatic
|
|||
software-update notification.
|
||||
|
||||
Cirrus Logic maintains a web page at http://www.cirrus.com with the
|
||||
the latest drivers and technical publications.
|
||||
latest drivers and technical publications.
|
||||
|
||||
|
||||
6.4 Current maintainer
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ ethernet address of your ethernet card has to be set according to the DECnet
|
|||
address of the node in order for it to be autoconfigured (and then appear in
|
||||
/proc/net/decnet_dev). There is a utility available at the above
|
||||
FTP sites called dn2ethaddr which can compute the correct ethernet
|
||||
address to use. The address can be set by ifconfig either before at
|
||||
address to use. The address can be set by ifconfig either before or
|
||||
at the time the device is brought up. If you are using RedHat you can
|
||||
add the line:
|
||||
|
||||
|
|
|
|||
|
|
@ -350,7 +350,7 @@ Additional Configurations
|
|||
|
||||
As an example, if you install the e1000 driver for two PRO/1000 adapters
|
||||
(eth0 and eth1) and set the speed and duplex to 10full and 100half, add
|
||||
the following to modules.conf or or modprobe.conf:
|
||||
the following to modules.conf or modprobe.conf:
|
||||
|
||||
alias eth0 e1000
|
||||
alias eth1 e1000
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ However, you may want to set PCI latency timer to 248.
|
|||
#setpci -d 17d5:* LATENCY_TIMER=f8
|
||||
For detailed description of the PCI registers, please see Xframe User Guide.
|
||||
b. Use 2-buffer mode. This results in large performance boost on
|
||||
on certain platforms(eg. SGI Altix, IBM xSeries).
|
||||
certain platforms(eg. SGI Altix, IBM xSeries).
|
||||
c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to
|
||||
set/verify this option.
|
||||
d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network
|
||||
|
|
|
|||
|
|
@ -497,7 +497,7 @@ Solution: In /proc/pci search for the following entry:
|
|||
www.syskonnect.com
|
||||
|
||||
Some COMPAQ machines have problems dealing with PCI under Linux.
|
||||
Linux. This problem is described in the 'PCI howto' document
|
||||
This problem is described in the 'PCI howto' document
|
||||
(included in some distributions or available from the
|
||||
web, e.g. at 'www.linux.org').
|
||||
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ is STEP 6 (Permanent Failure).
|
|||
>>> a value of 0xff on read, and writes will be dropped. If the device
|
||||
>>> driver attempts more than 10K I/O's to a frozen adapter, it will
|
||||
>>> assume that the device driver has gone into an infinite loop, and
|
||||
>>> it will panic the the kernel. There doesn't seem to be any other
|
||||
>>> it will panic the kernel. There doesn't seem to be any other
|
||||
>>> way of stopping a device driver that insists on spinning on I/O.
|
||||
|
||||
STEP 2: MMIO Enabled
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ instead set the PF_NOFREEZE process flag when creating the thread (and
|
|||
be very carefull).
|
||||
|
||||
|
||||
Q: What is the difference between between "platform", "shutdown" and
|
||||
Q: What is the difference between "platform", "shutdown" and
|
||||
"firmware" in /sys/power/disk?
|
||||
|
||||
A:
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ path which is not desirable. Hence, we do not optimize the height of the
|
|||
heap-and-size indexed overflow-sub-trees using prio_tree->index_bits.
|
||||
Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits
|
||||
of size_index. This may lead to skewed sub-trees because most of the
|
||||
higher significant bits of the size_index are likely to be be 0 (zero). In
|
||||
higher significant bits of the size_index are likely to be 0 (zero). In
|
||||
the example above, all 3 overflow-sub-trees are skewed. This may marginally
|
||||
affect the performance. However, processes rarely map many vmas with the
|
||||
same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Creating a Cache
|
|||
structure
|
||||
void cache_put(struct kref *)
|
||||
This is called when the last reference to an item is
|
||||
is dropped. The pointer passed is to the 'ref' field
|
||||
dropped. The pointer passed is to the 'ref' field
|
||||
in the cache_head. cache_put should release any
|
||||
references create by 'cache_init' and, if CACHE_VALID
|
||||
is set, any references created by cache_update.
|
||||
|
|
|
|||
|
|
@ -1085,8 +1085,7 @@ Notes
|
|||
-----
|
||||
Addresses & values in the VM debugger are always hex never decimal
|
||||
Address ranges are of the format <HexValue1>-<HexValue2> or <HexValue1>.<HexValue2>
|
||||
e.g. The address range 0x2000 to 0x3000 can be described described as
|
||||
2000-3000 or 2000.1000
|
||||
e.g. The address range 0x2000 to 0x3000 can be described as 2000-3000 or 2000.1000
|
||||
|
||||
The VM Debugger is case insensitive.
|
||||
|
||||
|
|
@ -1413,7 +1412,7 @@ SMP Specific commands
|
|||
To find out how many cpus you have
|
||||
Q CPUS displays all the CPU's available to your virtual machine
|
||||
To find the cpu that the current cpu VM debugger commands are being directed at do
|
||||
Q CPU to change the current cpu cpu VM debugger commands are being directed at do
|
||||
Q CPU to change the current cpu VM debugger commands are being directed at do
|
||||
CPU <desired cpu no>
|
||||
|
||||
On a SMP guest issue a command to all CPUs try prefixing the command with cpu all.
|
||||
|
|
@ -2184,7 +2183,7 @@ ps -aux | grep gdb
|
|||
kill -SIGSEGV <gdb's pid>
|
||||
or alternatively use killall -SIGSEGV gdb if you have the killall command.
|
||||
Now look at the core dump.
|
||||
./gdb ./gdb core
|
||||
./gdb core
|
||||
Displays the following
|
||||
GNU gdb 4.18
|
||||
Copyright 1998 Free Software Foundation, Inc.
|
||||
|
|
@ -2477,7 +2476,7 @@ Lcrash is a perfectly normal program,however, it requires 2
|
|||
additional files, Kerntypes which is built using a patch to the
|
||||
linux kernel sources in the linux root directory & the System.map.
|
||||
|
||||
Kerntypes is an an objectfile whose sole purpose in life
|
||||
Kerntypes is an objectfile whose sole purpose in life
|
||||
is to provide stabs debug info to lcrash, to do this
|
||||
Kerntypes is built from kerntypes.c which just includes the most commonly
|
||||
referenced header files used when debugging, lcrash can then read the
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Predefined views for hex/ascii, sprintf and raw binary data are provided.
|
|||
It is also possible to define other views. The content of
|
||||
a view can be inspected simply by reading the corresponding debugfs file.
|
||||
|
||||
All debug logs have an an actual debug level (range from 0 to 6).
|
||||
All debug logs have an actual debug level (range from 0 to 6).
|
||||
The default level is 3. Event and Exception functions have a 'level'
|
||||
parameter. Only debug entries with a level that is lower or equal
|
||||
than the actual level are written to the log. This means, when
|
||||
|
|
@ -556,7 +556,7 @@ The input_proc can be used to implement functionality when it is written to
|
|||
the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
|
||||
|
||||
For header_proc there can be used the default function
|
||||
debug_dflt_header_fn() which is defined in in debug.h.
|
||||
debug_dflt_header_fn() which is defined in debug.h.
|
||||
and which produces the same header output as the predefined views.
|
||||
E.g:
|
||||
00 00964419409:440761 2 - 00 88023ec
|
||||
|
|
|
|||
|
|
@ -1214,7 +1214,7 @@ Thu Jul 21 10:37:39 1994 Eric Youngdale (eric@esp22)
|
|||
|
||||
* sr.c(sr_open): Do not allow opens with write access.
|
||||
|
||||
Mon Jul 18 09:51:22 1994 1994 Eric Youngdale (eric@esp22)
|
||||
Mon Jul 18 09:51:22 1994 Eric Youngdale (eric@esp22)
|
||||
|
||||
* Linux 1.1.31 released.
|
||||
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ BOOT TIME CONFIGURATION
|
|||
|
||||
If the driver is compiled into the kernel, the same parameters can be
|
||||
also set using, e.g., the LILO command line. The preferred syntax is
|
||||
is to use the same keyword used when loading as module but prepended
|
||||
to use the same keyword used when loading as module but prepended
|
||||
with 'st.'. For instance, to set the maximum number of scatter/gather
|
||||
segments, the parameter 'st.max_sg_segs=xx' should be used (xx is the
|
||||
number of scatter/gather segments).
|
||||
|
|
|
|||
|
|
@ -5486,7 +5486,7 @@ struct _snd_pcm_runtime {
|
|||
<chapter id="power-management">
|
||||
<title>Power Management</title>
|
||||
<para>
|
||||
If the chip is supposed to work with with suspend/resume
|
||||
If the chip is supposed to work with suspend/resume
|
||||
functions, you need to add the power-management codes to the
|
||||
driver. The additional codes for the power-management should be
|
||||
<function>ifdef</function>'ed with
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ SB32.
|
|||
install awe_wave /sbin/modprobe --first-time -i awe_wave && /usr/local/bin/sfxload PATH_TO_SOUND_BANK_FILE
|
||||
|
||||
You will of course have to change "PATH_TO_SOUND_BANK_FILE" to the full
|
||||
path of of the sound bank file. That will enable the Sound Blaster and AWE
|
||||
path of the sound bank file. That will enable the Sound Blaster and AWE
|
||||
wave synthesis. To play midi files you should get one of these programs if
|
||||
you don't already have them:
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ is at least one report of it working on later silicon.
|
|||
The chip behaves differently than described in the data sheet,
|
||||
likely due to a chip bug. Working around this would require
|
||||
the help of ESS (for example by publishing an errata sheet),
|
||||
but ESS has not done so so far.
|
||||
but ESS has not done so far.
|
||||
|
||||
Also, the chip only supports 24 bit addresses for recording,
|
||||
which means it cannot work on some Alpha mainboards.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ db16 ???
|
|||
no_wave_dma option
|
||||
|
||||
This option defaults to a value of 0, which allows the Ultrasound wavetable
|
||||
DSP to use DMA for for playback and downloading samples. This is the same
|
||||
DSP to use DMA for playback and downloading samples. This is the same
|
||||
as the old behaviour. If set to 1, no DMA is needed for downloading samples,
|
||||
and allows owners of a GUS MAX to make use of simultaneous digital audio
|
||||
(/dev/dsp), MIDI, and wavetable playback.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ boxes.
|
|||
|
||||
The Visual Workstation has an Analog Devices AD1843 "SoundComm" audio
|
||||
codec chip. The AD1843 is accessed through the Cobalt I/O ASIC, also
|
||||
known as Lithium. This driver programs both both chips.
|
||||
known as Lithium. This driver programs both chips.
|
||||
|
||||
==============================================================================
|
||||
QUICK CONFIGURATION
|
||||
|
|
|
|||
|
|
@ -124,12 +124,12 @@ use a value of 8.
|
|||
The "pxa2xx_spi_chip.timeout_microsecs" fields is used to efficiently handle
|
||||
trailing bytes in the SSP receiver fifo. The correct value for this field is
|
||||
dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific
|
||||
slave device. Please note the the PXA2xx SSP 1 does not support trailing byte
|
||||
slave device. Please note that the PXA2xx SSP 1 does not support trailing byte
|
||||
timeouts and must busy-wait any trailing bytes.
|
||||
|
||||
The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting
|
||||
into internal loopback mode. In this mode the SSP controller internally
|
||||
connects the SSPTX pin the the SSPRX pin. This is useful for initial setup
|
||||
connects the SSPTX pin to the SSPRX pin. This is useful for initial setup
|
||||
testing.
|
||||
|
||||
The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific
|
||||
|
|
@ -208,7 +208,7 @@ DMA and PIO I/O Support
|
|||
-----------------------
|
||||
The pxa2xx_spi driver support both DMA and interrupt driven PIO message
|
||||
transfers. The driver defaults to PIO mode and DMA transfers must enabled by
|
||||
setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and and
|
||||
setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and
|
||||
ensuring that the "pxa2xx_spi_chip.dma_burst_size" field is non-zero. The DMA
|
||||
mode support both coherent and stream based DMA mappings.
|
||||
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ NON-STATIC CONFIGURATIONS
|
|||
Developer boards often play by different rules than product boards, and one
|
||||
example is the potential need to hotplug SPI devices and/or controllers.
|
||||
|
||||
For those cases you might need to use use spi_busnum_to_master() to look
|
||||
For those cases you might need to use spi_busnum_to_master() to look
|
||||
up the spi bus master, and will likely need spi_new_device() to provide the
|
||||
board info based on the board that was hotplugged. Of course, you'd later
|
||||
call at least spi_unregister_device() when that board is removed.
|
||||
|
|
@ -322,7 +322,7 @@ As soon as it enters probe(), the driver may issue I/O requests to
|
|||
the SPI device using "struct spi_message". When remove() returns,
|
||||
the driver guarantees that it won't submit any more such messages.
|
||||
|
||||
- An spi_message is a sequence of of protocol operations, executed
|
||||
- An spi_message is a sequence of protocol operations, executed
|
||||
as one atomic sequence. SPI driver controls include:
|
||||
|
||||
+ when bidirectional reads and writes start ... by how its
|
||||
|
|
|
|||
|
|
@ -260,7 +260,7 @@ items:
|
|||
a pointer to it.
|
||||
|
||||
7.4) Appropriately modify architecture specific code to register the
|
||||
the new system call.
|
||||
new system call.
|
||||
|
||||
8) Test Specification
|
||||
---------------------
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ one or more packets could finish before an error stops further endpoint I/O.
|
|||
hardware problems such as bad devices (including firmware) or cables.
|
||||
|
||||
(**) This is also one of several codes that different kinds of host
|
||||
controller use to to indicate a transfer has failed because of device
|
||||
controller use to indicate a transfer has failed because of device
|
||||
disconnect. In the interval before the hub driver starts disconnect
|
||||
processing, devices may receive such fault reports for every request.
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ index, the ioctl returns -1 and sets errno to -EINVAL.
|
|||
HIDIOCGDEVINFO - struct hiddev_devinfo (read)
|
||||
Gets a hiddev_devinfo structure which describes the device.
|
||||
|
||||
HIDIOCGSTRING - struct struct hiddev_string_descriptor (read/write)
|
||||
HIDIOCGSTRING - struct hiddev_string_descriptor (read/write)
|
||||
Gets a string descriptor from the device. The caller must fill in the
|
||||
"index" field to indicate which descriptor should be returned.
|
||||
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ Cypress M8 CY4601 Family Serial Driver
|
|||
-Cypress HID->COM RS232 adapter
|
||||
|
||||
Note: Cypress Semiconductor claims no affiliation with the
|
||||
the hid->com device.
|
||||
hid->com device.
|
||||
|
||||
Most devices using chipsets under the CY4601 family should
|
||||
work with the driver. As long as they stay true to the CY4601
|
||||
|
|
@ -422,7 +422,7 @@ Options supported:
|
|||
debug - extra verbose debugging info
|
||||
(default: 0; nonzero enables)
|
||||
use_lowlatency - use low_latency flag to speed up tty layer
|
||||
when reading from from the device.
|
||||
when reading from the device.
|
||||
(default: 0; nonzero enables)
|
||||
|
||||
See http://www.uuhaus.de/linux/palmconnect.html for up-to-date
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ Source file list / functional overview:
|
|||
pvrusb2-i2c-core.[ch] - This module provides an implementation of a
|
||||
kernel-friendly I2C adaptor driver, through which other external
|
||||
I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
|
||||
operate corresponding chips within the the pvrusb2 device. It is
|
||||
operate corresponding chips within the pvrusb2 device. It is
|
||||
through here that other V4L modules can reach into this driver to
|
||||
operate specific pieces (and those modules are in turn driven by
|
||||
glue logic which is coordinated by pvrusb2-hdw, doled out by
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ tv broadcast formats all aver the world.
|
|||
|
||||
The CCIR defines parameters needed for broadcasting the signal.
|
||||
The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
|
||||
The CCIR says not much about about the colorsystem used !!!
|
||||
The CCIR says not much about the colorsystem used !!!
|
||||
And talking about a colorsystem says not to much about how it is broadcast.
|
||||
|
||||
The CCIR standards A,E,F are not used any more.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The initial port includes NUMAizing the bootmem allocator code by
|
|||
encapsulating all the pieces of information into a bootmem_data_t
|
||||
structure. Node specific calls have been added to the allocator.
|
||||
In theory, any platform which uses the bootmem allocator should
|
||||
be able to to put the bootmem and mem_map data structures anywhere
|
||||
be able to put the bootmem and mem_map data structures anywhere
|
||||
it deems best.
|
||||
|
||||
Each node's page allocation data structures have also been encapsulated
|
||||
|
|
|
|||
Loading…
Reference in a new issue