mirror of
https://github.com/adulau/aha.git
synced 2024-12-27 03:06:10 +00:00
Fix typos in Documentation/: 'D'-'E'
This patch fixes typos in various Documentation txts. This patch addresses some words starting with the letters 'D'-'E'. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
Matt LaPlante
Adrian Bunk
parent
6c28f2c0f2
commit
fff9289b21
38 changed files with 63 additions and 64 deletions
|
|
@ -7,7 +7,7 @@ not been observed, but it would be nice to eliminate any potential for
|
|||
deadlock under memory pressure.
|
||||
|
||||
Because ATA over Ethernet is not fragmented by the kernel's IP code,
|
||||
the destructore member of the struct sk_buff is available to the aoe
|
||||
the destructor member of the struct sk_buff is available to the aoe
|
||||
driver. By using a mempool for allocating all but the first few
|
||||
sk_buffs, and by registering a destructor, we should be able to
|
||||
efficiently allocate sk_buffs without introducing any potential for
|
||||
|
|
|
|||
|
|
@ -1203,6 +1203,6 @@ temporarily map a bio into the virtual address space.
|
|||
and Linus' comments - Jan 2001)
|
||||
9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan
|
||||
et al - Feb-March 2001 (many of the initial thoughts that led to bio were
|
||||
brought up in this discusion thread)
|
||||
brought up in this discussion thread)
|
||||
9.3 Discussions on mempool on lkml - Dec 2001.
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ the /proc filesystem entry which the "block" side of the driver creates as
|
|||
the SCSI core may not yet be initialized (because the driver is a block
|
||||
driver) and attempting to register it with the SCSI core in such a case
|
||||
would cause a hang. This is best done via an initialization script
|
||||
(typically in /etc/init.d, but could vary depending on distibution).
|
||||
(typically in /etc/init.d, but could vary depending on distribution).
|
||||
For example:
|
||||
|
||||
for x in /proc/driver/cciss/cciss[0-9]*
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ The type of **_id is int.
|
|||
The type of siblings is cpumask_t.
|
||||
|
||||
To be consistent on all architectures, the 4 attributes should have
|
||||
deafult values if their values are unavailable. Below is the rule.
|
||||
default values if their values are unavailable. Below is the rule.
|
||||
1) physical_package_id: If cpu has no physical package id, -1 is the
|
||||
default value.
|
||||
2) core_id: If cpu doesn't support multi-core, its core id is 0.
|
||||
|
|
|
|||
|
|
@ -3205,7 +3205,7 @@ for a session; this includes virtual consoles, serial ports, and
|
|||
pseudoterminals (PTYs).
|
||||
|
||||
All terminal devices share a common set of capabilities known as line
|
||||
diciplines; these include the common terminal line dicipline as well
|
||||
disciplines; these include the common terminal line discipline as well
|
||||
as SLIP and PPP modes.
|
||||
|
||||
All terminal devices are named similarly; this section explains the
|
||||
|
|
@ -3285,7 +3285,7 @@ port TTY, for which no alternate device would exist.
|
|||
Pseudoterminals (PTYs)
|
||||
|
||||
Pseudoterminals, or PTYs, are used to create login sessions or provide
|
||||
other capabilities requiring a TTY line dicipline (including SLIP or
|
||||
other capabilities requiring a TTY line discipline (including SLIP or
|
||||
PPP capability) to arbitrary data-generation processes. Each PTY has
|
||||
a master side, named /dev/pty[p-za-e][0-9a-f], and a slave side, named
|
||||
/dev/tty[p-za-e][0-9a-f]. The kernel arbitrates the use of PTYs by
|
||||
|
|
|
|||
|
|
@ -48,12 +48,12 @@ Module Usage
|
|||
|
||||
Module insertion:
|
||||
# insmod sstfb.o
|
||||
you should see some strange output frome the board:
|
||||
you should see some strange output from the board:
|
||||
a big blue square, a green and a red small squares and a vertical
|
||||
white rectangle. why ? the function's name is self explanatory :
|
||||
white rectangle. why? the function's name is self-explanatory:
|
||||
"sstfb_test()"...
|
||||
(if you don't have a second monitor, you'll have to plug your monitor
|
||||
directely to the 2D videocard to see what you're typing)
|
||||
directly to the 2D videocard to see what you're typing)
|
||||
# con2fb /dev/fbx /dev/ttyx
|
||||
bind a tty to the new frame buffer. if you already have a frame
|
||||
buffer driver, the voodoo fb will likely be /dev/fb1. if not,
|
||||
|
|
@ -95,11 +95,11 @@ inverse=1 inverse Supposed to enable inverse console.
|
|||
|
||||
clipping=1 clipping Enable or disable clipping.
|
||||
clipping=0 noclipping With clipping enabled, all offscreen
|
||||
reads and writes are disgarded.
|
||||
reads and writes are discarded.
|
||||
Default: enable clipping.
|
||||
|
||||
gfxclk=x gfxclk:x Force graphic clock frequency (in MHz).
|
||||
Be carefull with this option, it may be
|
||||
Be careful with this option, it may be
|
||||
DANGEROUS.
|
||||
Default: auto
|
||||
50Mhz for Voodoo 1,
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ request for an already acquired lock will not generate another DLM
|
|||
call. Userspace programs are assumed to handle their own local
|
||||
locking.
|
||||
|
||||
Two levels of locks are supported - Shared Read, and Exlcusive.
|
||||
Two levels of locks are supported - Shared Read, and Exclusive.
|
||||
Also supported is a Trylock operation.
|
||||
|
||||
For information on the libo2dlm interface, please see o2dlm.h,
|
||||
|
|
|
|||
|
|
@ -390,7 +390,7 @@ stripes with parity, i.e. raid level 5, should not work, too.
|
|||
|
||||
You have to use the "persistent-superblock 0" option for each raid-disk in the
|
||||
NTFS volume/stripe you are configuring in /etc/raidtab as the persistent
|
||||
superblock used by the MD driver would damange the NTFS volume.
|
||||
superblock used by the MD driver would damage the NTFS volume.
|
||||
|
||||
Windows by default uses a stripe chunk size of 64k, so you probably want the
|
||||
"chunk-size 64k" option for each raid-disk, too.
|
||||
|
|
|
|||
|
|
@ -238,7 +238,7 @@ Top Level Directory Layout
|
|||
The sysfs directory arrangement exposes the relationship of kernel
|
||||
data structures.
|
||||
|
||||
The top level sysfs diretory looks like:
|
||||
The top level sysfs directory looks like:
|
||||
|
||||
block/
|
||||
bus/
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ back and forth trying to integrate high-resolution and high-precision
|
|||
features into the existing timer framework, and after testing various
|
||||
such high-resolution timer implementations in practice, we came to the
|
||||
conclusion that the timer wheel code is fundamentally not suitable for
|
||||
such an approach. We initially didnt believe this ('there must be a way
|
||||
such an approach. We initially didn't believe this ('there must be a way
|
||||
to solve this'), and spent a considerable effort trying to integrate
|
||||
things into the timer wheel, but we failed. In hindsight, there are
|
||||
several reasons why such integration is hard/impossible:
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ is obtained by ORing 0x80 with the make code.
|
|||
The special codes 0xF6 through 0xFF are reserved for use as follows:
|
||||
0xF6 status report
|
||||
0xF7 absolute mouse position record
|
||||
0xF8-0xFB relative mouse position records(lsbs determind by
|
||||
0xF8-0xFB relative mouse position records (lsbs determined by
|
||||
mouse button states)
|
||||
0xFC time-of-day
|
||||
0xFD joystick report (both sticks)
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ This driver have the basic support for PCI devices only; there is no
|
|||
ISA or PnP ISA cards supported. AFAIK the ns558 have support for Crystal
|
||||
ISA and PnP ISA series.
|
||||
|
||||
The driver works witn ALSA drivers simultaneously. For exmple, the xracer
|
||||
The driver works with ALSA drivers simultaneously. For example, the xracer
|
||||
uses joystick as input device and PCM device as sound output in one time.
|
||||
There are no sound or input collisions detected. The source code have
|
||||
comments about them; but I've found the joystick can be initialized
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ joystick.txt for details.
|
|||
There is an utility called fftest that will allow you to test the driver.
|
||||
% fftest /dev/input/eventXX
|
||||
|
||||
3. Instructions to the developper
|
||||
3. Instructions to the developer
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
All interactions are done using the event API. That is, you can use ioctl()
|
||||
and write() on /dev/input/eventXX.
|
||||
|
|
|
|||
|
|
@ -154,7 +154,7 @@ about it.
|
|||
|
||||
3.2 Event handlers
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Event handlers distrubite the events from the devices to userland and
|
||||
Event handlers distribute the events from the devices to userland and
|
||||
kernel, as needed.
|
||||
|
||||
3.2.1 keybdev
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ more complex object types. It provides a set of basic fields that
|
|||
almost all complex data types share. kobjects are intended to be
|
||||
embedded in larger data structures and replace fields they duplicate.
|
||||
|
||||
1.2 Defintion
|
||||
1.2 Definition
|
||||
|
||||
struct kobject {
|
||||
char name[KOBJ_NAME_LEN];
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ be reconstructed (due to no parity).
|
|||
|
||||
For this reason, md will normally refuse to start such an array. This
|
||||
requires the sysadmin to take action to explicitly start the array
|
||||
desipite possible corruption. This is normally done with
|
||||
despite possible corruption. This is normally done with
|
||||
mdadm --assemble --force ....
|
||||
|
||||
This option is not really available if the array has the root
|
||||
|
|
@ -214,8 +214,8 @@ All md devices contain:
|
|||
safe_mode_delay
|
||||
When an md array has seen no write requests for a certain period
|
||||
of time, it will be marked as 'clean'. When another write
|
||||
request arrive, the array is marked as 'dirty' before the write
|
||||
commenses. This is known as 'safe_mode'.
|
||||
request arrives, the array is marked as 'dirty' before the write
|
||||
commences. This is known as 'safe_mode'.
|
||||
The 'certain period' is controlled by this file which stores the
|
||||
period as a number of seconds. The default is 200msec (0.200).
|
||||
Writing a value of 0 disables safemode.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Legend:
|
|||
packets out of the rx ring. Note from this that the lower the
|
||||
load the more we could clean up the rxring
|
||||
"Ndone" == is the converse of "Done". Note again, that the higher
|
||||
the load the more times we couldnt clean up the rxring.
|
||||
the load the more times we couldn't clean up the rxring.
|
||||
|
||||
Observe that:
|
||||
when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated.
|
||||
|
|
|
|||
|
|
@ -103,8 +103,8 @@ In the kernel when setting up:
|
|||
else
|
||||
failed
|
||||
|
||||
From now on, everytime you dump my_rate_est_stats it will contain
|
||||
uptodate info.
|
||||
From now on, every time you dump my_rate_est_stats it will contain
|
||||
up-to-date info.
|
||||
|
||||
Once you are done, call gen_kill_estimator(my_basicstats,
|
||||
my_rate_est_stats) Make sure that my_basicstats and my_rate_est_stats
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ Examples:
|
|||
Example scripts
|
||||
===============
|
||||
|
||||
A collection of small tutorial scripts for pktgen is in expamples dir.
|
||||
A collection of small tutorial scripts for pktgen is in examples dir.
|
||||
|
||||
pktgen.conf-1-1 # 1 CPU 1 dev
|
||||
pktgen.conf-1-2 # 1 CPU 2 dev
|
||||
|
|
|
|||
|
|
@ -570,7 +570,7 @@ bata1-2.2.1 Feb 09 2001
|
|||
|
||||
Option to COMPILE WANPIPE modules against the currently
|
||||
running kernel, thus no need for manual kernel and module
|
||||
re-compilatin.
|
||||
re-compilation.
|
||||
|
||||
o Updates and Bug Fixes to wancfg utility.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Updated 2006 by Horms <horms@verge.net.au>
|
|||
In order to use a diskless system, such as an X-terminal or printer server
|
||||
for example, it is necessary for the root filesystem to be present on a
|
||||
non-disk device. This may be an initramfs (see Documentation/filesystems/
|
||||
ramfs-rootfs-initramfs.txt), a ramdisk (see Documenation/initrd.txt) or a
|
||||
ramfs-rootfs-initramfs.txt), a ramdisk (see Documentation/initrd.txt) or a
|
||||
filesystem mounted via NFS. The following text describes on how to use NFS
|
||||
for the root filesystem. For the rest of this text 'client' means the
|
||||
diskless system, and 'server' means the NFS server.
|
||||
|
|
|
|||
|
|
@ -326,7 +326,7 @@ A reference implementation
|
|||
|
||||
This is a typical implementation. Drivers can slightly change the order
|
||||
of the operations in the implementation, ignore some operations or add
|
||||
more deriver specific operations in it, but drivers should do something like
|
||||
more driver specific operations in it, but drivers should do something like
|
||||
this on the whole.
|
||||
|
||||
5. Resources
|
||||
|
|
|
|||
|
|
@ -335,7 +335,7 @@ struct boot_param_header {
|
|||
"compact" format for the tree itself that is however not backward
|
||||
compatible. You should always generate a structure of the highest
|
||||
version defined at the time of your implementation. Currently
|
||||
that is version 16, unless you explicitely aim at being backward
|
||||
that is version 16, unless you explicitly aim at being backward
|
||||
compatible.
|
||||
|
||||
- last_comp_version
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ second, third, and fourth Rocketport cards (if present) are set via
|
|||
software control. The DIP switch settings for the I/O address must be
|
||||
set to the value of the first Rocketport cards.
|
||||
|
||||
In order to destinguish each of the card from the others, each card
|
||||
In order to distinguish each of the card from the others, each card
|
||||
must have a unique board ID set on the dip switches. The first
|
||||
Rocketport board must be set with the DIP switches corresponding to
|
||||
the first board, the second board must be set with the DIP switches
|
||||
|
|
@ -120,7 +120,7 @@ conflict with any other cards in the system, including other
|
|||
RocketPort cards. Below, you will find a list of commonly used I/O
|
||||
address ranges which may be in use by other devices in your system.
|
||||
On a Linux system, "cat /proc/ioports" will also be helpful in
|
||||
identifying what I/O addresses are being used by devics on your
|
||||
identifying what I/O addresses are being used by devices on your
|
||||
system.
|
||||
|
||||
Remember, the FIRST RocketPort uses 68 I/O addresses. So, if you set it
|
||||
|
|
|
|||
|
|
@ -8,8 +8,8 @@
|
|||
Overview of Document:
|
||||
=====================
|
||||
This document is intended to give an good overview of how to debug
|
||||
Linux for s/390 & z/Architecture it isn't intended as a complete reference & not a
|
||||
tutorial on the fundamentals of C & assembly, it dosen't go into
|
||||
Linux for s/390 & z/Architecture. It isn't intended as a complete reference & not a
|
||||
tutorial on the fundamentals of C & assembly. It doesn't go into
|
||||
390 IO in any detail. It is intended to complement the documents in the
|
||||
reference section below & any other worthwhile references you get.
|
||||
|
||||
|
|
@ -354,7 +354,7 @@ static inline struct task_struct * get_current(void)
|
|||
}
|
||||
|
||||
i.e. just anding the current kernel stack pointer with the mask -8192.
|
||||
Thankfully because Linux dosen't have support for nested IO interrupts
|
||||
Thankfully because Linux doesn't have support for nested IO interrupts
|
||||
& our devices have large buffers can survive interrupts being shut for
|
||||
short amounts of time we don't need a separate stack for interrupts.
|
||||
|
||||
|
|
@ -394,7 +394,7 @@ i.e they aren't in registers & they aren't static.
|
|||
back-chain:
|
||||
This is a pointer to the stack pointer before entering a
|
||||
framed functions ( see frameless function ) prologue got by
|
||||
deferencing the address of the current stack pointer,
|
||||
dereferencing the address of the current stack pointer,
|
||||
i.e. got by accessing the 32 bit value at the stack pointers
|
||||
current location.
|
||||
|
||||
|
|
@ -724,7 +724,7 @@ This is useful for debugging because
|
|||
1) You can double check whether the files you expect to be included are the ones
|
||||
that are being included ( e.g. double check that you aren't going to the i386 asm directory ).
|
||||
2) Check that macro definitions aren't clashing with typedefs,
|
||||
3) Check that definitons aren't being used before they are being included.
|
||||
3) Check that definitions aren't being used before they are being included.
|
||||
4) Helps put the line emitting the error under the microscope if it contains macros.
|
||||
|
||||
For convenience the Linux kernel's makefile will do preprocessing automatically for you
|
||||
|
|
@ -840,12 +840,11 @@ using the strip command to make it a more reasonable size to boot it.
|
|||
|
||||
A source/assembly mixed dump of the kernel can be done with the line
|
||||
objdump --source vmlinux > vmlinux.lst
|
||||
Also if the file isn't compiled -g this will output as much debugging information
|
||||
as it can ( e.g. function names ), however, this is very slow as it spends lots
|
||||
of time searching for debugging info, the following self explanitory line should be used
|
||||
instead if the code isn't compiled -g.
|
||||
Also, if the file isn't compiled -g, this will output as much debugging information
|
||||
as it can (e.g. function names). This is very slow as it spends lots
|
||||
of time searching for debugging info. The following self explanatory line should be used
|
||||
instead if the code isn't compiled -g, as it is much faster:
|
||||
objdump --disassemble-all --syms vmlinux > vmlinux.lst
|
||||
as it is much faster
|
||||
|
||||
As hard drive space is valuble most of us use the following approach.
|
||||
1) Look at the emitted psw on the console to find the crash address in the kernel.
|
||||
|
|
@ -1674,8 +1673,8 @@ channel is idle & the second for device end ( secondary status ) sometimes you g
|
|||
concurrently, you check how the IO went on by issuing a TEST SUBCHANNEL at each interrupt,
|
||||
from which you receive an Interruption response block (IRB). If you get channel & device end
|
||||
status in the IRB without channel checks etc. your IO probably went okay. If you didn't you
|
||||
probably need a doctorto examine the IRB & extended status word etc.
|
||||
If an error occurs more sophistocated control units have a facitity known as
|
||||
probably need a doctor to examine the IRB & extended status word etc.
|
||||
If an error occurs, more sophistocated control units have a facitity known as
|
||||
concurrent sense this means that if an error occurs Extended sense information will
|
||||
be presented in the Extended status word in the IRB if not you have to issue a
|
||||
subsequent SENSE CCW command after the test subchannel.
|
||||
|
|
@ -1916,7 +1915,7 @@ Assembly
|
|||
--------
|
||||
info registers: displays registers other than floating point.
|
||||
info all-registers: displays floating points as well.
|
||||
disassemble: dissassembles
|
||||
disassemble: disassembles
|
||||
e.g.
|
||||
disassemble without parameters will disassemble the current function
|
||||
disassemble $pc $pc+10
|
||||
|
|
@ -1935,7 +1934,7 @@ undisplay : undo's display's
|
|||
|
||||
info breakpoints: shows all current breakpoints
|
||||
|
||||
info stack: shows stack back trace ( if this dosent work too well, I'll show you the
|
||||
info stack: shows stack back trace ( if this doesn't work too well, I'll show you the
|
||||
stacktrace by hand below ).
|
||||
|
||||
info locals: displays local variables.
|
||||
|
|
|
|||
|
|
@ -433,7 +433,7 @@ puts the CPU into I/O disabled state by preserving the current PSW flags.
|
|||
|
||||
The device driver is allowed to issue the next ccw_device_start() call from
|
||||
within its interrupt handler already. It is not required to schedule a
|
||||
bottom-half, unless an non deterministicly long running error recovery procedure
|
||||
bottom-half, unless an non deterministically long running error recovery procedure
|
||||
or similar needs to be scheduled. During I/O processing the Linux/390 generic
|
||||
I/O device driver support has already obtained the IRQ lock, i.e. the handler
|
||||
must not try to obtain it again when calling ccw_device_start() or we end in a
|
||||
|
|
|
|||
|
|
@ -468,7 +468,7 @@ The hex_ascii view shows the data field in hex and ascii representation
|
|||
The raw view returns a bytestream as the debug areas are stored in memory.
|
||||
|
||||
The sprintf view formats the debug entries in the same way as the sprintf
|
||||
function would do. The sprintf event/expection functions write to the
|
||||
function would do. The sprintf event/exception functions write to the
|
||||
debug entry a pointer to the format string (size = sizeof(long))
|
||||
and for each vararg a long value. So e.g. for a debug entry with a format
|
||||
string plus two varargs one would need to allocate a (3 * sizeof(long))
|
||||
|
|
|
|||
|
|
@ -96,10 +96,10 @@ The original driver has been written for 386bsd and FreeBSD by:
|
|||
It is now available as a bundle of 2 drivers:
|
||||
|
||||
- ncr53c8xx generic driver that supports all the SYM53C8XX family including
|
||||
the ealiest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and
|
||||
the earliest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and
|
||||
the new 895A (1 channel LVD SCSI controller).
|
||||
- sym53c8xx enhanced driver (a.k.a. 896 drivers) that drops support of oldest
|
||||
chips in order to gain advantage of new features, as LOAD/STORE intructions
|
||||
chips in order to gain advantage of new features, as LOAD/STORE instructions
|
||||
available since the 810A and hardware phase mismatch available with the
|
||||
896 and the 895A.
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ The 896 and the 895A allows handling of the phase mismatch context from
|
|||
SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor
|
||||
until the C code has saved the context of the transfer).
|
||||
Implementing this without using LOAD/STORE instructions would be painfull
|
||||
and I did'nt even want to try it.
|
||||
and I didn't even want to try it.
|
||||
|
||||
The 896 chip supports 64 bit PCI transactions and addressing, while the
|
||||
895A supports 32 bit PCI transactions and 64 bit addressing.
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ ways.
|
|||
- Fine-grained EH callbacks
|
||||
LLDD can implement fine-grained EH callbacks and let SCSI
|
||||
midlayer drive error handling and call appropriate callbacks.
|
||||
This will be dicussed further in [2-1].
|
||||
This will be discussed further in [2-1].
|
||||
|
||||
- eh_strategy_handler() callback
|
||||
This is one big callback which should perform whole error
|
||||
|
|
|
|||
|
|
@ -381,7 +381,7 @@ Please see http://www.garloff.de/kurt/linux/dc390/problems.html
|
|||
replaced by the dev index of your scanner). You may try to reset your SCSI
|
||||
bus afterwards (echo "RESET" >/proc/scsi/tmscsim/?).
|
||||
The problem seems to be solved as of 2.0d18, thanks to Andreas Rick.
|
||||
* If there is a valid partition table, the driver will use it for determing
|
||||
* If there is a valid partition table, the driver will use it for determining
|
||||
the mapping. If there's none, a reasonable mapping (Symbios-like) will be
|
||||
assumed. Other operating systems may not like this mapping, though
|
||||
it's consistent with the BIOS' behaviour. Old DC390 drivers ignored the
|
||||
|
|
|
|||
|
|
@ -1263,8 +1263,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
Note: on some notebooks the buffer address cannot be detected
|
||||
automatically, or causes hang-up during initialization.
|
||||
In such a case, specify the buffer top address explicity via
|
||||
buffer_top option.
|
||||
In such a case, specify the buffer top address explicitly via
|
||||
the buffer_top option.
|
||||
For example,
|
||||
Sony F250: buffer_top=0x25a800
|
||||
Sony F270: buffer_top=0x272800
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ Here is a list of supported device_setup values for this device:
|
|||
- Alsa driver default mode
|
||||
- maintains backward compatibility with setups that do not use this
|
||||
parameter by not introducing any change
|
||||
- results sometimes in corrupted sound as decribed earlier
|
||||
- results sometimes in corrupted sound as described earlier
|
||||
* device_setup=0x01
|
||||
- 16bits 48kHz mode with Di disabled
|
||||
- Ai,Ao,Do can be used at the same time
|
||||
|
|
|
|||
|
|
@ -97,4 +97,4 @@ COPYRIGHT
|
|||
=========
|
||||
|
||||
Copyright (c) 2003 Digigram SA <alsa@digigram.com>
|
||||
Distributalbe under GPL.
|
||||
Distributable under GPL.
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ The status of MIDI I/O is found in midi* files. It shows the device
|
|||
name and the received/transmitted bytes through the MIDI device.
|
||||
|
||||
When the card is equipped with AC97 codecs, there are codec97#*
|
||||
subdirectories (desribed later).
|
||||
subdirectories (described later).
|
||||
|
||||
When the OSS mixer emulation is enabled (and the module is loaded),
|
||||
oss_mixer file appears here, too. This shows the current mapping of
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ one or more packets could finish before an error stops further endpoint I/O.
|
|||
urb->transfer_flags.
|
||||
|
||||
-ENODEV Device was removed. Often preceded by a burst of
|
||||
other errors, since the hub driver does't detect
|
||||
other errors, since the hub driver doesn't detect
|
||||
device removal events immediately.
|
||||
|
||||
-EXDEV ISO transfer only partially completed
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ TODO:
|
|||
Implement a control urb again to handle requests to and from the device
|
||||
such as calibration, etc once/if it becomes available.
|
||||
|
||||
DISCLAMER:
|
||||
DISCLAIMER:
|
||||
|
||||
I am not a MicroTouch/3M employee, nor have I ever been. 3M does not support
|
||||
this driver! If you want touch drivers only supported within X, please go to:
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ driver (PCI vendor/device is 0x136b/0xff01)
|
|||
|
||||
The third one, present in recent (more or less last year) Picturebooks
|
||||
(C1M* models), is not supported. The manufacturer has given the specs
|
||||
to the developers under a NDA (which allows the develoment of a GPL
|
||||
to the developers under a NDA (which allows the development of a GPL
|
||||
driver however), but things are not moving very fast (see
|
||||
http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
|
||||
|
||||
|
|
|
|||
|
|
@ -118,9 +118,9 @@ card is not there, please try if any other card gives some
|
|||
response, and mail me if you got a working tvcard addition.
|
||||
|
||||
PS. <TVCard editors behold!)
|
||||
Dont forget to set video_input to the number of inputs
|
||||
Don't forget to set video_input to the number of inputs
|
||||
you defined in the video_mux part of the tvcard definition.
|
||||
Its a common error to add a channel but not incrementing
|
||||
It's a common error to add a channel but not incrementing
|
||||
video_input and getting angry with me/v4l/linux/linus :(
|
||||
|
||||
You are now ready to test the framegrabber with your favorite
|
||||
|
|
|
|||
Loading…
Reference in a new issue