diff options
| author | Jaroslav Kysela <perex@suse.cz> | 2004-11-29 12:47:59 +0100 |
|---|---|---|
| committer | Jaroslav Kysela <perex@suse.cz> | 2004-11-29 12:47:59 +0100 |
| commit | aceda15df4b94da622a0e362daf5d8b3d97026bb (patch) | |
| tree | ce3711a18405bac3cd97894ba7fa81e0b1b6a966 /Documentation | |
| parent | 771b767ca024ef0fe1d2735931cfe66d38cc9c06 (diff) | |
| parent | ceaa57fe291f4cbf94009e99e5ce65b70ff6ea9b (diff) | |
| download | history-aceda15df4b94da622a0e362daf5d8b3d97026bb.tar.gz | |
Merge suse.cz:/home/perex/bk/linux-sound/linux-2.5
into suse.cz:/home/perex/bk/linux-sound/linux-sound
Diffstat (limited to 'Documentation')
23 files changed, 959 insertions, 898 deletions
diff --git a/Documentation/DocBook/librs.tmpl b/Documentation/DocBook/librs.tmpl index ea94ae848b218c..be482c0302034a 100644 --- a/Documentation/DocBook/librs.tmpl +++ b/Documentation/DocBook/librs.tmpl @@ -83,13 +83,13 @@ <title>Initializing</title> <para> The init function init_rs returns a pointer to a - rs decoder structure, which holds the neccecary + rs decoder structure, which holds the necessary information for encoding, decoding and error correction with the given polynomial. It either uses an existing matching decoder or creates a new one. On creation all the lookup tables for fast en/decoding are created. The function may take a while, so make sure not to - call it in critical code pathes. + call it in critical code paths. </para> <programlisting> /* the Reed Solomon control structure */ @@ -123,10 +123,10 @@ rs_decoder = init_rs (10, 0x409, 0, 1, 6); results in ECC errors. </para> <para> - The databytes are expanded to the given symbolsize - on the fly. There is no support for encoding continuos - bitstreams with a symbolsize != 8 at the moment. If - it is neccecary it should be not a big deal to implement + The databytes are expanded to the given symbol size + on the fly. There is no support for encoding continuous + bitstreams with a symbol size != 8 at the moment. If + it is necessary it should be not a big deal to implement such functionality. </para> <programlisting> @@ -155,13 +155,13 @@ encode_rs8 (rs_decoder, data8, 512, par, 0); location buffer to the decoder. The decoder stores the calculated error location and the correction bitmask in the given buffers. This is useful for hardware - decoders which use a weird bitordering scheme. + decoders which use a weird bit ordering scheme. </para> <para> - The databytes are expanded to the given symbolsize - on the fly. There is no support for decoding continuos + The databytes are expanded to the given symbol size + on the fly. There is no support for decoding continuous bitstreams with a symbolsize != 8 at the moment. If - it is neccecary it should be not a big deal to implement + it is necessary it should be not a big deal to implement such functionality. </para> @@ -208,7 +208,7 @@ numerr = decode_rs8 (rs_decoder, data8, par, 512, syn, 0, NULL, 0, NULL); Decoding with syndrome given by hardware decoder, no direct data correction. </title> <para> - Note: It's not neccecary to give data and recieved parity to the decoder. + Note: It's not necessary to give data and received parity to the decoder. </para> <programlisting> /* Parity buffer. Size = number of roots */ diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index a851d039ad01b9..fad566bb02fc8f 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting @@ -118,6 +118,10 @@ to store page tables. The recommended placement is 32KiB into RAM. In either case, the following conditions must be met: +- Quiesce all DMA capable devicess so that memory does not get + corrupted by bogus network packets or disk data. This will save + you many hours of debug. + - CPU register settings r0 = 0, r1 = machine type number discovered in (3) above. diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000 index 48ba502fa598f9..969f165932f250 100644 --- a/Documentation/arm/IXP2000 +++ b/Documentation/arm/IXP2000 @@ -18,7 +18,7 @@ http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm 2. Linux Support -Linux currently supports the following features on the IXP2000 NPUS: +Linux currently supports the following features on the IXP2000 NPUs: - On-chip serial - PCI @@ -30,10 +30,10 @@ That is about all we can support under Linux ATM b/c the core networking components of the chip are accessed via Intel's closed source SDK. Please contact Intel directly on issues with using those. There is also a mailing list run by some folks at Princeton University that might -be of helpful: https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx +be of help: https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL -MAILINNG LISTS REGARDING THE INTEL SDK. +MAILING LISTS REGARDING THE INTEL SDK. 3. Supported Platforms @@ -47,12 +47,12 @@ MAILINNG LISTS REGARDING THE INTEL SDK. - The IXP2000 platforms ususally have rather complex PCI bus topologies with large memory space requirements. In addition, b/c of the way the - Intel SDK is designed, devices are enumerated in a vert specific + Intel SDK is designed, devices are enumerated in a very specific way. B/c of this this, we use "pci=firmware" option in the kernel command line so that we do not re-enumerate the bus. - IXDP2x01 systems have variable clock tick rates that we cannot determine - via HW registers. The "ixdp2x01_clk=XXX" cmd line options allows you + via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you to pass the clock rate to the board port. 5. Thanks diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx index d86d818a492d85..2e1590b42fff21 100644 --- a/Documentation/arm/IXP4xx +++ b/Documentation/arm/IXP4xx @@ -122,6 +122,15 @@ http://developer.intel.com/design/network/products/npfamily/ixdp425.htm also known as the Richfield board. It contains 4 PCI slots, 16MB of flash, two 10/100 ports and one ADSL port. +Intel IXDPG425 Development Platform + + This is basically and ADI Coyote board with a NEC EHCI controller + added. One issue with this board is that the mini-PCI slots only + have the 3.3v line connected, so you can't use a PCI to mini-PCI + adapter with an E100 card. So to NFS root you need to use either + the CSR or a WiFi card and a ramdisk that BOOTPs and then does + a pivot_root to NFS. + Motorola PrPMC1100 Processor Mezanine Card http://www.fountainsys.com/datasheet/PrPMC1100.pdf @@ -152,4 +161,4 @@ Robert E. Ranslam ------------------------------------------------------------------------- -Last Update: 5/13/2004 +Last Update: 11/16/2004 diff --git a/Documentation/arm/README b/Documentation/arm/README index 1dd5d6cb76e4d1..a6f718e90a8687 100644 --- a/Documentation/arm/README +++ b/Documentation/arm/README @@ -163,9 +163,9 @@ CONFIG_MACH_ and CONFIG_ARCH_ <http://www.arm.linux.org.uk/developer/machines/> -Kernel entry (head-armv.S) +Kernel entry (head.S) -------------------------- - The initial entry into the kernel is via head-armv.S, which uses machine + The initial entry into the kernel is via head.S, which uses machine independent code. The machine is selected by the value of 'r1' on entry, which must be kept unique. diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt index fd763cc4892d4f..6f47332c883de7 100644 --- a/Documentation/block/as-iosched.txt +++ b/Documentation/block/as-iosched.txt @@ -132,7 +132,7 @@ a combination of IO behavior from all those devices. Tuning the anticipatory IO scheduler ------------------------------------ When using 'as', the anticipatory IO scheduler there are 5 parameters under -/sys/block/*/iosched/. All are units of milliseconds. +/sys/block/*/queue/iosched/. All are units of milliseconds. The parameters are: * read_expire diff --git a/Documentation/block/deadline-iosched.txt b/Documentation/block/deadline-iosched.txt index 2b131860055821..c918b3a6022dd0 100644 --- a/Documentation/block/deadline-iosched.txt +++ b/Documentation/block/deadline-iosched.txt @@ -9,7 +9,7 @@ Each io queue has a set of io scheduler tunables associated with it. These tunables control how the io scheduler works. You can find these entries in: -/sys/block/<device>/iosched +/sys/block/<device>/queue/iosched assuming that you have sysfs mounted on /sys. If you don't have sysfs mounted, you can do so by typing: diff --git a/Documentation/cpu-freq/cpufreq-nforce2.txt b/Documentation/cpu-freq/cpufreq-nforce2.txt new file mode 100644 index 00000000000000..9188337d8f6b8f --- /dev/null +++ b/Documentation/cpu-freq/cpufreq-nforce2.txt @@ -0,0 +1,19 @@ + +The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms. + +This works better than on other plattforms, because the FSB of the CPU +can be controlled independently from the PCI/AGP clock. + +The module has two options: + + fid: multiplier * 10 (for example 8.5 = 85) + min_fsb: minimum FSB + +If not set, fid is calculated from the current CPU speed and the FSB. +min_fsb defaults to FSB at boot time - 50 MHz. + +IMPORTANT: The available range is limited downwards! + Also the minimum available FSB can differ, for systems + booting with 200 MHz, 150 should always work. + + diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 7576788f1a643e..f115145e58a2ae 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -2758,6 +2758,10 @@ Your cooperation is appreciated. 43 = /dev/ttySMX2 Motorola i.MX - port 2 44 = /dev/ttyMM0 Marvell MPSC - port 0 45 = /dev/ttyMM1 Marvell MPSC - port 1 + 46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0 + ... + 49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 + 205 char Low-density serial ports (alternate device) 0 = /dev/culu0 Callout device for ttyLU0 @@ -2786,6 +2790,9 @@ Your cooperation is appreciated. 41 = /dev/ttySMX0 Callout device for ttySMX0 42 = /dev/ttySMX1 Callout device for ttySMX1 43 = /dev/ttySMX2 Callout device for ttySMX2 + 46 = /dev/cucpm0 Callout device for ttyCPM0 + ... + 49 = /dev/cucpm5 Callout device for ttyCPM5 206 char OnStream SC-x0 tape devices 0 = /dev/osst0 First OnStream SCSI tape, mode 0 diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt index 20be482b6ec565..bb58c36b5845c9 100644 --- a/Documentation/hw_random.txt +++ b/Documentation/hw_random.txt @@ -67,72 +67,3 @@ Driver details: Special thanks to Matt Sottek. I did the "guts", he did the "brains" and all the testing. - -Change history: - - Version 1.0.0: - * Merge Intel, AMD, VIA RNG drivers into one. - Further changelog in BitKeeper. - - Version 0.9.8: - * Support other i8xx chipsets by adding 82801E detection - * 82801DB detection is the same as for 82801CA. - - Version 0.9.7: - * Support other i8xx chipsets too (by adding 82801BA(M) and - 82801CA(M) detection) - - Version 0.9.6: - * Internal driver cleanups, prep for 1.0.0 release. - - Version 0.9.5: - * Rip out entropy injection via timer. It never ever worked, - and a better solution (rngd) is now available. - - Version 0.9.4: - * Fix: Remove request_mem_region - * Fix: Horrible bugs in FIPS calculation and test execution - - Version 0.9.3: - * Clean up rng_read a bit. - * Update i810_rng driver Web site URL. - * Increase default timer interval to 4 samples per second. - * Abort if mem region is not available. - * BSS zero-initialization cleanup. - * Call misc_register() from rng_init_one. - * Fix O_NONBLOCK to occur before we schedule. - - Version 0.9.2: - * Simplify open blocking logic - - Version 0.9.1: - * Support i815 chipsets too (Matt Sottek) - * Fix reference counting when statically compiled (prumpf) - * Rewrite rng_dev_read (prumpf) - * Make module races less likely (prumpf) - * Small miscellaneous bug fixes (prumpf) - * Use pci table for PCI id list - - Version 0.9.0: - * Don't register a pci_driver, because we are really - using PCI bridge vendor/device ids, and someone - may want to register a driver for the bridge. (bug fix) - * Don't let the usage count go negative (bug fix) - * Clean up spinlocks (bug fix) - * Enable PCI device, if necessary (bug fix) - * iounmap on module unload (bug fix) - * If RNG chrdev is already in use when open(2) is called, - sleep until it is available. - * Remove redundant globals rng_allocated, rng_use_count - * Convert numeric globals to unsigned - * Module unload cleanup - - Version 0.6.2: - * Clean up spinlocks. Since we don't have any interrupts - to worry about, but we do have a timer to worry about, - we use spin_lock_bh everywhere except the timer function - itself. - * Fix module load/unload. - * Fix timer function and h/w enable/disable logic - * New timer interval sysctl - * Clean up sysctl names diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface index 4fe882cb401eeb..09d6cda2a1fb6e 100644 --- a/Documentation/i2c/dev-interface +++ b/Documentation/i2c/dev-interface @@ -3,7 +3,7 @@ possible to access all devices on an adapter from userspace, through the /dev interface. You need to load module i2c-dev for this. Each registered i2c adapter gets a number, counting from 0. You can -examine /proc/bus/i2c to see what number corresponds to which adapter. +examine /sys/class/i2c-dev/ to see what number corresponds to which adapter. I2C device files are character device files with major device number 89 and a minor device number corresponding to the number assigned as explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., @@ -19,7 +19,7 @@ Yes, I know, you should never include kernel header files, but until glibc knows about i2c, there is not much choice. Now, you have to decide which adapter you want to access. You should -inspect /proc/bus/i2c to decide this. Adapter numbers are assigned +inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned somewhat dynamically, so you can not even assume /dev/i2c-0 is the first adapter. diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index b182423fdbb6f6..011e92094c028d 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -676,14 +676,26 @@ SMBus communication extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command); extern s32 i2c_smbus_write_word_data(struct i2c_client * client, u8 command, u16 value); - extern s32 i2c_smbus_process_call(struct i2c_client * client, - u8 command, u16 value); - extern s32 i2c_smbus_read_block_data(struct i2c_client * client, - u8 command, u8 *values); extern s32 i2c_smbus_write_block_data(struct i2c_client * client, u8 command, u8 length, u8 *values); +These ones were removed in Linux 2.6.10 because they had no users, but could +be added back later if needed: + + extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, + u8 command, u8 *values); + extern s32 i2c_smbus_read_block_data(struct i2c_client * client, + u8 command, u8 *values); + extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client, + u8 command, u8 length, + u8 *values); + extern s32 i2c_smbus_process_call(struct i2c_client * client, + u8 command, u16 value); + extern s32 i2c_smbus_block_process_call(struct i2c_client *client, + u8 command, u8 length, + u8 *values) + All these transactions return -1 on failure. The 'write' transactions return 0 on success; the 'read' transactions return the read value, except for read_block, which returns the number of values read. The block buffers diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index b8933206f43586..c91caf7eb30366 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -1,68 +1,419 @@ -For now this is a raw copy from the old Documentation/kbuild/modules.txt, -which was removed in 2.6.0-test5. -The information herein is correct but not complete. - -Installing modules in a non-standard location ---------------------------------------------- -When the modules needs to be installed under another directory -the INSTALL_MOD_PATH can be used to prefix "/lib/modules" as seen -in the following example: - -make INSTALL_MOD_PATH=/frodo modules_install - -This will install the modules in the directory /frodo/lib/modules. -/frodo can be a NFS mounted filesystem on another machine, allowing -out-of-the-box support for installation on remote machines. - - -Compiling modules outside the official kernel ---------------------------------------------- - -Often modules are developed outside the official kernel. To keep up -with changes in the build system the most portable way to compile a -module outside the kernel is to use the kernel build system, -kbuild. Use the following command-line: - -make -C path/to/kernel/src M=$PWD modules - -This requires that a makefile exits made in accordance to -Documentation/kbuild/makefiles.txt. Read that file for more details on -the build system. - -The following is a short summary of how to write your Makefile to get -you up and running fast. Assuming your module will be called -yourmodule.ko, your code should be in yourmodule.c and your Makefile -should include - -obj-m := yourmodule.o - -If the code for your module is in multiple files that need to be -linked, you need to tell the build system which files to compile. In -the case of multiple files, none of these files can be named -yourmodule.c because doing so would cause a problem with the linking -step. Assuming your code exists in file1.c, file2.c, and file3.c and -you want to build yourmodule.ko from them, your Makefile should -include - -obj-m := yourmodule.o -yourmodule-objs := file1.o file2.o file3.o - -Now for a final example to put it all together. Assuming the -KERNEL_SOURCE environment variable is set to the directory where you -compiled the kernel, a simple Makefile that builds yourmodule.ko as -described above would look like - -# Tells the build system to build yourmodule.ko. -obj-m := yourmodule.o - -# Tells the build system to build these object files and link them as -# yourmodule.o, before building yourmodule.ko. This line can be left -# out if all the code for your module is in one file, yourmodule.c. If -# you are using multiple files, none of these files can be named -# yourmodule.c. -yourmodule-objs := file1.o file2.o file3.o - -# Invokes the kernel build system to come back to the current -# directory and build yourmodule.ko. -default: - make -C ${KERNEL_SOURCE} M=`pwd` modules + +In this document you will find information about: +- how to build external modules +- how to make your module use kbuild infrastructure +- how kbuild will install a kernel +- how to install modules in a non-standard location + +=== Table of Contents + + === 1 Introduction + === 2 How to build external modules + --- 2.1 Building external modules + --- 2.2 Available targets + --- 2.3 Available options + --- 2.4 Preparing the kernel tree for module build + === 3. Example commands + === 4. Creating a kbuild file for an external module + === 5. Include files + --- 5.1 How to include files from the kernel include dir + --- 5.2 External modules using an include/ dir + === 6. Module installation + --- 6.1 INSTALL_MOD_PATH + --- 6.2 INSTALL_MOD_DIR + === 7. Module versioning + === 8. Tips & Tricks + --- 8.1 Testing for CONFIG_FOO_BAR + + + +=== 1. Introduction + +kbuild includes functionality for building modules both +within the kernel source tree and outside the kernel source tree. +The latter is usually referred to as external modules and is used +both during development and for modules that are not planned to be +included in the kernel tree. + +What is covered within this file is mainly information to authors +of modules. The author of an external modules should supply +a makefile that hides most of the complexity so one only has to type +'make' to buld the module. A complete example will be present in +chapter ¤. Creating a kbuild file for an external module". + + +=== 2. How to build external modules + +kbuild offers functionality to build external modules, with the +prerequisite that there is a pre-built kernel available with full source. +A subset of the targets available when building the kernel is available +when building an external module. + +--- 2.1 Building external modules + + Use the following command to build an external module: + + make -C <path-to-kernel> M=`pwd` + + For the running kernel use: + make -C /lib/modules/`uname -r`/build M=`pwd` + + For the above command to succeed the kernel must have been built with + modules enabled. + + To install the modules that were just built: + + make -C <path-to-kernel> M=`pwd` modules_install + + More complex examples later, the above should get you going. + +--- 2.2 Available targets + + $KDIR refers to path to kernel source top-level directory + + make -C $KDIR M=`pwd` + Will build the module(s) located in current directory. + All output files will be located in the same directory + as the module source. + No attempts are made to update the kernel source, and it is + a precondition that a successful make has been executed + for the kernel. + + make -C $KDIR M=`pwd` modules + The modules target is implied when no target is given. + Same functionality as if no target was specified. + See description above. + + make -C $KDIR M=$PWD modules_install + Install the external module(s). + Installation default is in /lib/modules/<kernel-version>/extra, + but may be prefixed with INSTALL_MOD_PATH - see separate chater. + + make -C $KDIR M=$PWD clean + Remove all generated files for the module - the kernel + source directory is not moddified. + + make -C $KDIR M=`pwd` help + help will list the available target when building external + modules. + +--- 2.3 Available options: + + $KDIR refer to path to kernel src + + make -C $KDIR + Used to specify where to find the kernel source. + '$KDIR' represent the directory where the kernel source is. + Make will actually change directory to the specified directory + when executed but change back when finished. + + make -C $KDIR M=`pwd` + M= is used to tell kbuild that an external module is + being built. + The option given to M= is the directory where the external + module (kbuild file) is located. + When an external module is being built only a subset of the + usual targets are available. + + make -C $KDIR SUBDIRS=`pwd` + Same as M=. The SUBDIRS= syntax is kept for backwards + compatibility. + +--- 2.4 Preparing the kernel tree for module build + + To make sure the kernel contains the information required to + build external modules the target 'modules_prepare' must be used. + 'module_prepare' solely exists as a simple way to prepare + a kernel for building external modules. + Note: modules_prepare will not build Module.symvers even if + CONFIG_MODULEVERSIONING is set. + Therefore a full kernel build needs to be executed to make + module versioning work. + + +=== 3. Example commands + +This example shows the actual commands to be executed when building +an external module for the currently running kernel. +In the example below the distribution is supposed to use the +facility to locate output files for a kernel compile in a different +directory than the kernel source - but the examples will also work +when the source and the output files are mixed in the same directory. + +# Kernel source +/lib/modules/<kernel-version>/source -> /usr/src/linux-<version> + +# Output from kernel compile +/lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up + +Change to the directory where the kbuild file is located and execute +the following commands to build the module: + + cd /home/user/src/module + make -C /usr/src/`uname -r`/source \ + O=/lib/modules/`uname-r`/build \ + M=`pwd` + +Then to install the module use the following command: + + make -C /usr/src/`uname -r`/source \ + O=/lib/modules/`uname-r`/build \ + M=`pwd` \ + modules_install + +If one looks closely you will see that this is the same commands as +listed before - with the directories spelled out. + +The above are rather long commands, and the following chapter +lists a few tricks to make it all easier. + + +=== 4. Creating a kbuild file for an external module + +kbuild is the build system for the kernel, and external modules +must use kbuild to stay compatible with changes in the build system +and to pick up the right flags to gcc etc. + +The kbuild file used as input shall follow the syntax described +in Documentation/kbuild/makefiles.txt. This chapter will introduce a few +more tricks to be used when dealing with external modules. + +In the following a Makefile will be created for a module with the +following files: + 8123_if.c + 8123_if.h + 8123_pci.c + 8123_bin.o_shipped <= Binary blob + +--- 4.1 Shared Makefile for module and kernel + + An external module always includes a wrapper Makefile supporting + building the module using 'make' with no arguments. + The Makefile provided will most likely include additional + functionality such as test targets etc. and this part shall + be filtered away from kbuild since it may impact kbuild if + name clashes occurs. + + Example 1: + --> filename: Makefile + ifneq ($(KERNELRELEASE),) + # kbuild part of makefile + obj-m := 8123.o + 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + + else + # Normal Makefile + + KERNELDIR := /lib/modules/`uname -r`/build + all:: + $(MAKE) -C $KERNELDIR M=`pwd` $@ + + # Module specific targets + genbin: + echo "X" > 8123_bini.o_shipped + + endif + + In example 1 the check for KERNELRELEASE is used to separate + the two parts of the Makefile. kbuild will only see the two + assignments whereas make will see everything except the two + kbuild assignments. + + In recent versions of the kernel, kbuild will look for a file named + Kbuild and as second option look for a file named Makefile. + Utilising the Kbuild file makes us split up the Makefile in example 1 + into two files as shown in example 2: + + Example 2: + --> filename: Kbuild + obj-m := 8123.o + 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + + --> filename: Makefile + KERNELDIR := /lib/modules/`uname -r`/build + all:: + $(MAKE) -C $KERNELDIR M=`pwd` $@ + + # Module specific targets + genbin: + echo "X" > 8123_bin_shipped + + + In example 2 we are down to two fairly simple files and for simple + files as used in this example the split is questionable. But some + external modules use Makefiles of several hundred lines and here it + really pays off to separate the kbuild part from the rest. + Example 3 shows a backward compatible version. + + Example 3: + --> filename: Kbuild + obj-m := 8123.o + 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + + --> filename: Makefile + ifneq ($(KERNELRELEASE),) + include Kbuild + else + # Normal Makefile + + KERNELDIR := /lib/modules/`uname -r`/build + all:: + $(MAKE) -C $KERNELDIR M=`pwd` $@ + + # Module specific targets + genbin: + echo "X" > 8123_bin_shipped + + endif + + The trick here is to include the Kbuild file from Makefile so + if an older version of kbuild picks up the Makefile the Kbuild + file will be included. + +--- 4.2 Binary blobs included in a module + + Some external modules needs to include a .o as a blob. kbuild + has support for this, but requires the blob file to be named + <filename>_shipped. In our example the blob is named + 8123_bin.o_shipped and when the kbuild rules kick in the file + 8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file + with the _shipped part stripped of the filename. + This allows the 8123_bin.o filename to be used in the assignment to + the module. + + Example 4: + obj-m := 8123.o + 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + + In example 4 there is no distinction between the ordinary .c/.h files + and the binary file. But kbuild will pick up different rules to create + the .o file. + + +=== 5. Include files + +Include files are a necessity when a .c file uses something from another .c +files (not strictly in the sense of .c but if good programming practice is +used). Any module that consist of more than one .c file will have a .h file +for one of the .c files. +- If the .h file only describes a module internal interface then the .h file + shall be placed in the same directory as the .c files. +- If the .h files describe an interface used by other parts of the kernel + located in different directories, the .h files shall be located in + include/linux/ or other include/ directories as appropriate. + +One exception for this rule is larger subsystems that have their own directory +under include/ such as include/scsi. Another exception is arch-specific +.h files which are located under include/asm-$(ARCH)/*. + +External modules have a tendency to locate include files in a separate include/ +directory and therefore needs to deal with this in their kbuild file. + +--- 5.1 How to include files from the kernel include dir + + When a module needs to include a file from include/linux/ then one + just uses: + + #include <linux/modules.h> + + kbuild will make sure to add options to gcc so the relevant + directories are searched. + Likewise for .h files placed in the same directory as the .c file. + + #include "8123_if.h" + + will do the job. + +--- 5.2 External modules using an include/ dir + + External modules often locate their .h files in a separate include/ + directory although this is not usual kernel style. When an external + module uses an include/ dir then kbuild needs to be told so. + The trick here is to use either EXTRA_CFLAGS (take effect for all .c + files) or CFLAGS_$F.o (take effect only for a single file). + + In our example if we move 8123_if.h to a subdirectory named include/ + the resulting Kbuild file would look like: + + --> filename: Kbuild + obj-m := 8123.o + + EXTRA_CFLAGS := -Iinclude + 8123-y := 8123_if.o 8123_pci.o 8123_bin.o + + Note that in the assingment there is no space between -I and the path. + This is a kbuild limitation and no space must be present. + + +=== 6. Module installation + +Modules which are included in the kernel is installed in the directory: + + /lib/modules/$(KERNELRELEASE)/kernel + +External modules are installed in the directory: + + /lib/modules/$(KERNELRELEASE)/extra + +--- 6.1 INSTALL_MOD_PATH + + Above are the default directories, but as always some level of + customization is possible. One can prefix the path using the variable + INSTALL_MOD_PATH: + + $ make INSTALL_MOD_PATH=/frodo modules_install + => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel + + INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the + example above be specified on the commandline when calling make. + INSTALL_MOD_PATH has effect both when installing modules included in + the kernel as well as when installing external modules. + +--- 6.2 INSTALL_MOD_DIR + + When installing external modules they are default installed in a + directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish + to locate modules for a specific functionality in a separate + directory. For this purpose one can use INSTALL_MOD_DIR to specify an + alternative name than 'extra'. + + $ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \ + M=`pwd` modules_install + => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf + + +=== 7. Module versioning + +Module versioning are enabled by the CONFIG_MODVERSIONS tag. + +Module versioning is used as a simple ABI consistency check. The Module +versioning creates a CRC value of the full prototype for an exported symbol and +when a module is loaded/used then the CRC values contained in the kernel are +compared with similar values in the module. If they are not equal then the +kernel refuses to load the module. + +During a kernel build a file named Module.symvers will be generated. This +file includes the symbol version of all symbols within the kernel. If the +Module.symvers file is saved from the last full kernel compile one does not +have to do a full kernel compile to build a module version's compatible module. + +=== 8. Tips & Tricks + +--- 8.1 Testing for CONFIG_FOO_BAR + + Modules often needs to check for certain CONFIG_ options to decide if + a specific feature shall be included in the module. When kbuild is used + this is done by referencing the CONFIG_ variable directly. + + #fs/ext2/Makefile + obj-$(CONFIG_EXT2_FS) += ext2.o + + ext2-y := balloc.o bitmap.o dir.o + ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o + + External modules have traditionally used grep to check for specific + CONFIG_ settings directly in .config. This usage is broken. + As introduced before external modules shall use kbuild when building + and therefore can use the same methods as in-kernel modules when testing + for CONFIG_ definitions. + diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2807201154522d..2e34b1c6a7da7a 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -312,8 +312,24 @@ running once the system is up. condev= [HW,S390] console device conmode= - console= [KNL] Output console - Console device and comm spec (speed, control, parity). + console= [KNL] Output console device and options. + + tty<n> Use the virtual console device <n>. + + ttyS<n>[,options] + Use the specified serial port. The options are of + the form "bbbbpn", where "bbbb" is the baud rate, + "p" is parity ("n", "o", or "e"), and "n" is bits. + Default is "9600n8". + + See also Documentation/serial-console.txt. + + uart,io,<addr>[,options] + uart,mmio,<addr>[,options] + Start an early, polled-mode console on the 8250/16550 + UART at the specified I/O port or MMIO address, + switching to the matching ttyS device later. The + options are the same as for ttyS, above. cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver Format: <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] @@ -404,7 +420,8 @@ running once the system is up. elevator= [IOSCHED] Format: {"as"|"cfq"|"deadline"|"noop"} - See Documentation/as-iosched.txt for details + See Documentation/block/as-iosched.txt + and Documentation/block/deadline-iosched.txt for details. es1370= [HW,OSS] Format: <lineout>[,<micbias>] @@ -503,10 +520,12 @@ running once the system is up. icn= [HW,ISDN] Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] + ide= [HW] (E)IDE subsystem + Format: ide=nodma or ide=doubler or ide=reverse + See Documentation/ide.txt. + ide?= [HW] (E)IDE subsystem - Config (iomem/irq), tuning or debugging - (serialize,reset,no{dma,tune,probe}) or chipset - specific parameters. + Format: ide?=noprobe or chipset specific parameters. See Documentation/ide.txt. idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed @@ -652,9 +671,10 @@ running once the system is up. maxcpus= [SMP] Maximum number of processors that an SMP kernel should make use of - max_scsi_luns= [SCSI] + max_luns= [SCSI] Maximum number of LUNs to probe + Should be between 1 and 2^32-1. - max_scsi_report_luns= + max_report_luns= [SCSI] Maximum number of LUNs received Should be between 1 and 16384. @@ -784,8 +804,6 @@ running once the system is up. nofxsr [BUGS=IA-32] - nohighio [BUGS=IA-32] Disable highmem block I/O. - nohlt [BUGS=ARM] no-hlt [BUGS=IA-32] Tells the kernel that the hlt @@ -931,6 +949,10 @@ running once the system is up. enabled. noacpi [IA-32] Do not use ACPI for IRQ routing or for PCI scanning. + routeirq Do IRQ routing for all PCI devices. + This is normally done in pci_enable_device(), + so this option is a temporary workaround + for broken drivers that don't call it. firmware [ARM] Do not re-enumerate the bus but instead just use the configuration diff --git a/Documentation/md.txt b/Documentation/md.txt index 3fb3b1ef18fb9c..e2b536992a2798 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -45,7 +45,8 @@ Boot time autodetection of RAID arrays When md is compiled into the kernel (not as module), partitions of type 0xfd are scanned and automatically assembled into RAID arrays. This autodetection may be suppressed with the kernel parameter -"raid=noautodetect". +"raid=noautodetect". As of kernel 2.6.9, only drives with a type 0 +superblock can be autodetected and run at boot time. The kernel parameter "raid=partitionable" (or "raid=part") means that all auto-detected arrays are assembled as partitionable. @@ -55,13 +56,13 @@ Superblock formats ------------------ The md driver can support a variety of different superblock formats. -(It doesn't yet, but it can) +Currently, it supports superblock formats "0.90.0" and the "md-1" format +introduced in the 2.5 development series. -The kernel does *NOT* autodetect which format superblock is being -used. It must be told. +The kernel will autodetect which format superblock is being used. Superblock format '0' is treated differently to others for legacy -reasons. +reasons - it is the original superblock format. General Rules - apply for all superblock formats @@ -69,6 +70,7 @@ General Rules - apply for all superblock formats An array is 'created' by writing appropriate superblocks to all devices. + It is 'assembled' by associating each of these devices with an particular md virtual device. Once it is completely assembled, it can be accessed. @@ -76,10 +78,10 @@ be accessed. An array should be created by a user-space tool. This will write superblocks to all devices. It will usually mark the array as 'unclean', or with some devices missing so that the kernel md driver -can create approrpriate redundancy (copying in raid1, parity +can create appropriate redundancy (copying in raid1, parity calculation in raid4/5). -When an array is assembled, it is first initialised with the +When an array is assembled, it is first initialized with the SET_ARRAY_INFO ioctl. This contains, in particular, a major and minor version number. The major version number selects which superblock format is to be used. The minor number might be used to tune handling @@ -101,15 +103,16 @@ array using HOT_REMOVE_DISK. Specific Rules that apply to format-0 super block arrays, and - arrays with no superblock (non-persistant). + arrays with no superblock (non-persistent). ------------------------------------------------------------- An array can be 'created' by describing the array (level, chunksize etc) in a SET_ARRAY_INFO ioctl. This must has major_version==0 and raid_disks != 0. -Then uninitialised devices can be added with ADD_NEW_DISK. The + +Then uninitialized devices can be added with ADD_NEW_DISK. The structure passed to ADD_NEW_DISK must specify the state of the device and it's role in the array. -One started with RUN_ARRAY, uninitialised spares can be added with +Once started with RUN_ARRAY, uninitialized spares can be added with HOT_ADD_DISK. diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt index 6cad46e8ac2d40..c025a4561c1033 100644 --- a/Documentation/nmi_watchdog.txt +++ b/Documentation/nmi_watchdog.txt @@ -54,6 +54,20 @@ then the system has crashed so hard (eg. hardware-wise) that either it cannot even accept NMI interrupts, or the crash has made the kernel unable to print messages. +Be aware that when using local APIC, the frequency of NMI interrupts +it generates, depends on the system load. The local APIC NMI watchdog, +lacking a better source, uses the "cycles unhalted" event. As you may +guess it doesn't tick when the CPU is in the halted state (which happens +when the system is idle), but if your system locks up on anything but the +"hlt" processor instruction, the watchdog will trigger very soon as the +"cycles unhalted" event will happen every clock tick. If it locks up on +"hlt", then you are out of luck -- the event will not happen at all and the +watchdog won't trigger. This is a shortcoming of the local APIC watchdog +-- unfortunately there is no "clock ticks" event that would work all the +time. The I/O APIC watchdog is driven externally and has no such shortcoming. +But its NMI frequency is much higher, resulting in a more significant hit +to the overall system performance. + NOTE: starting with 2.4.2-ac18 the NMI-oopser is disabled by default, you have to enable it with a boot time parameter. Prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally on x86 SMP boxes. diff --git a/Documentation/pci.txt b/Documentation/pci.txt index 04f1ba9c1a20e5..b0676d1145ca8f 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -156,11 +156,9 @@ Searching by both vendor/device and subsystem vendor/device ID: VENDOR_ID or DEVICE_ID. This allows searching for any device from a specific vendor, for example. -Note that these functions are not hotplug-safe. Their hotplug-safe -replacements are pci_get_device(), pci_get_class() and pci_get_subsys(). -They increment the reference count on the pci_dev that they return. -You must eventually (possibly at module unload) decrement the reference -count on these devices by calling pci_dev_put(). + These functions are hotplug-safe. They increment the reference count on +the pci_dev that they return. You must eventually (possibly at module unload) +decrement the reference count on these devices by calling pci_dev_put(). 3. Enabling and disabling devices diff --git a/Documentation/s390/monreader.txt b/Documentation/s390/monreader.txt new file mode 100644 index 00000000000000..2150e5fc39738e --- /dev/null +++ b/Documentation/s390/monreader.txt @@ -0,0 +1,175 @@ + +Date : 2004-Nov-04 +Author: Gerald Schaefer (geraldsc@de.ibm.com) + + + Linux API for read access to z/VM Monitor Records + ================================================= + + +Description +=========== +This item delivers a new Linux API in the form of a misc char device that is +useable from user space and allows read access to the z/VM Monitor Records +collected by the *MONITOR System Service of z/VM. + + +User Requirements +================= +The z/VM guest on which you want to access this API needs to be configured in +order to allow IUCV connections to the *MONITOR service, i.e. it needs the +IUCV *MONITOR statement in its user entry. If the monitor DCSS to be used is +restricted (likely), you also need the NAMESAVE <DCSS NAME> statement. +This item will use the IUCV device driver to access the z/VM services, so you +need a kernel with IUCV support. You also need z/VM version 4.4 or 5.1. + +There are two options for being able to load the monitor DCSS (examples assume +that the monitor DCSS begins at 144 MB and ends at 152 MB). You can query the +location of the monitor DCSS with the Class E privileged CP command Q NSS MAP +(the values BEGPAG and ENDPAG are given in units of 4K pages). + +See also "CP Command and Utility Reference" (SC24-6081-00) for more information +on the DEF STOR and Q NSS MAP commands, as well as "Saved Segments Planning +and Administration" (SC24-6116-00) for more information on DCSSes. + +1st option: +----------- +You can use the CP command DEF STOR CONFIG to define a "memory hole" in your +guest virtual storage around the address range of the DCSS. + +Example: DEF STOR CONFIG 0.140M 200M.200M + +This defines two blocks of storage, the first is 140MB in size an begins at +address 0MB, the second is 200MB in size and begins at address 200MB, +resulting in a total storage of 340MB. Note that the first block should +always start at 0 and be at least 64MB in size. + +2nd option: +----------- +Your guest virtual storage has to end below the starting address of the DCSS +and you have to specify the "mem=" kernel parameter in your parmfile with a +value greater than the ending address of the DCSS. + +Example: DEF STOR 140M + +This defines 140MB storage size for your guest, the parameter "mem=160M" is +added to the parmfile. + + +User Interface +============== +The char device is implemented as a kernel module named "monreader", +which can be loaded via the modprobe command, or it can be compiled into the +kernel instead. There is one optional module (or kernel) parameter, "mondcss", +to specify the name of the monitor DCSS. If the module is compiled into the +kernel, the kernel parameter "monreader.mondcss=<DCSS NAME>" can be specified +in the parmfile. + +The default name for the DCSS is "MONDCSS" if none is specified. In case that +there are other users already connected to the *MONITOR service (e.g. +Performance Toolkit), the monitor DCSS is already defined and you have to use +the same DCSS. The CP command Q MONITOR (Class E privileged) shows the name +of the monitor DCSS, if already defined, and the users connected to the +*MONITOR service. +Refer to the "z/VM Performance" book (SC24-6109-00) on how to create a monitor +DCSS, you need Class E privileges to define and save a DCSS. + +Example: +-------- +modprobe monreader mondcss=MYDCSS + +This loads the module and sets the DCSS name to "MYDCSS". + +NOTE: +----- +This API provides no interface to control the *MONITOR service, e.g. specifiy +which data should be collected. This can be done by the CP command MONITOR +(Class E privileged), see "CP Command and Utility Reference". + +Device nodes with udev: +----------------------- +After loading the module, a char device will be created along with the device +node /<udev directory>/monreader. + +Device nodes without udev: +-------------------------- +If your distribution does not support udev, a device node will not be created +automatically and you have to create it manually after loading the module. +Therefore you need to know the major and minor numbers of the device. These +numbers can be found in /sys/class/misc/monreader/dev. +Typing cat /sys/class/misc/monreader/dev will give an output of the form +<major>:<minor>. The device node can be created via the mknod command, enter +mknod <name> c <major> <minor>, where <name> is the name of the device node +to be created. + +Example: +-------- +# modprobe monreader +# cat /sys/class/misc/monreader/dev +10:63 +# mknod /dev/monreader c 10 63 + +This loads the module with the default monitor DCSS (MONDCSS) and creates a +device node. + +File operations: +---------------- +The following file operations are supported: open, release, read, poll. +There are two alternative methods for reading: either non-blocking read in +conjunction with polling, or blocking read without polling. IOCTLs are not +supported. + +Read: +----- +Reading from the device provides a set of one or more contiguous monitor +records, there is no control data (unlike the CMS MONWRITE utility output). +The monitor record layout can be found here (z/VM 5.1): +http://www.vm.ibm.com/pubs/mon510/index.html + +Each set of records is exclusively composed of either event records or sample +records. The end of such a set of records is indicated by a successful read +with a return value of 0 (0-Byte read). +Any received data must be considered invalid until a complete record set was +read successfully, including the closing 0-Byte read. Therefore you should +always read the complete set into a buffer before processing the data. + +The maximum size of a set of records can be as large as the size of the +monitor DCSS, so design the buffer adequately or use dynamic memory allocation +The size of the monitor DCSS will be printed into syslog after loading the +module. You can also use the (Class E privileged) CP command Q NSS MAP to +list all available segments and information about them. + +As with most char devices, error conditions are indicated by returning a +negative value for the number of bytes read. In this case, the errno variable +indicates the error condition: + +EIO: reply failed, read data is invalid and the application + should discard the data read since the last successful read with 0 size. +EFAULT: copy_to_user failed, read data is invalid and the application should + discard the data read since the last successful read with 0 size. +EAGAIN: occurs on a non-blocking read if there is no data available at the + moment. There is no data missing or corrupted, just try again or rather + use polling for non-blocking reads. +EOVERFLOW: message limit reached, the data read since the last successful + read with 0 size is valid but subsequent records may be missing. + +In the last case (EOVERFLOW) there may be missing data, in the first two cases +(EIO, EFAULT) there will be missing data. It's up to the application if it will +continue reading subsequent records or rather exit. + +Open: +----- +Only one user is allowed to open the char device. If it is already in use, the +open function will fail (return a negative value) and set errno to EBUSY. +The open function may also fail if an IUCV connection to the *MONITOR service +cannot be established. In this case errno will be set to EIO and an error +message with an IPUSER SEVER code will be printed into syslog. +The IPUSER SEVER codes are described in the "z/VM Performance" book. + +NOTE: +----- +As soon as the device is opened, incoming messages will be accepted and they +will account for the message limit, i.e. opening the device without reading +from it will provoke the "message limit reached" error (EOVERFLOW error code) +eventually. + diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index ad266137fa8865..b239d4c778d4b6 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid @@ -1,3 +1,14 @@ +Release Date : Thu Nov 4 18:24:56 EST 2004 - Sreenivas Bagalkote <sreenib@lsil.com> + +Current Version : 2.20.4.1 (scsi module), 2.20.2.2 (cmm module) +Older Version : 2.20.4.0 (scsi module), 2.20.2.1 (cmm module) + +i. Handle IOCTL cmd timeouts more properly. + +ii. pci_dma_sync_{sg,single}_for_cpu was introduced into megaraid_mbox + incorrectly (instead of _for_device). Changed to appropriate + pci_dma_sync_{sg,single}_for_device. + Release Date : Wed Oct 06 11:15:29 EDT 2004 - Sreenivas Bagalkote <sreenib@lsil.com> Current Version : 2.20.4.0 (scsi module), 2.20.2.1 (cmm module) Older Version : 2.20.4.0 (scsi module), 2.20.2.0 (cmm module) diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt index f13415a3ac3599..af9abe2913c340 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt @@ -4,7 +4,9 @@ Written by Gerard Roudier <groudier@free.fr> 21 Rue Carnot 95170 DEUIL LA BARRE - FRANCE -Decembre 28 2000 +Updated by Matthew Wilcox <matthew@wil.cx> + +2004-10-09 =============================================================================== 1. Introduction @@ -29,26 +31,20 @@ Decembre 28 2000 10. Boot setup commands 10.1 Syntax 10.2 Available arguments - 10.2.1 Master parity checking - 10.2.2 Scsi parity checking - 10.2.3 Default number of tagged commands - 10.2.4 Default synchronous period factor - 10.2.5 Verbosity level - 10.2.6 Debug mode - 10.2.7 Burst max - 10.2.8 LED support - 10.2.9 Max wide - 10.2.10 Differential mode - 10.2.11 IRQ mode - 10.2.12 Reverse probe - 10.2.13 Fix up PCI configuration space - 10.2.14 Serial NVRAM - 10.2.15 Check SCSI BUS - 10.2.16 Exclude a host from being attached - 10.2.17 Suggest a default SCSI id for hosts - 10.3 PCI configuration fix-up boot option - 10.4 Serial NVRAM support boot option - 10.5 SCSI BUS checking boot option + 10.2.1 Default number of tagged commands + 10.2.2 Burst max + 10.2.3 LED support + 10.2.4 Differential mode + 10.2.5 IRQ mode + 10.2.6 Check SCSI BUS + 10.2.7 Suggest a default SCSI id for hosts + 10.2.8 Verbosity level + 10.2.9 Debug mode + 10.2.10 Settle delay + 10.2.11 Serial NVRAM + 10.2.12 Exclude a host from being attached + 10.3 Converting from old options + 10.4 SCSI BUS checking boot option 11. SCSI problem troubleshooting 15.1 Problem tracking 15.2 Understanding hardware error reports @@ -94,6 +90,9 @@ The history of this driver can be summerized as follows: Write a glue code for Linux. Gerard Roudier +2004: Remove FreeBSD compatibility code. Remove support for versions of + Linux before 2.6. Start using Linux facilities. + This README file addresses the Linux version of the driver. Under FreeBSD, the driver documentation is the sym.8 man page. @@ -279,11 +278,10 @@ setting verbose level to zero, as follow: 6. Parity checking The driver supports SCSI parity checking and PCI bus master parity -checking. These features must be enabled in order to ensure safe data -transfers. However, some flawed devices or mother boards will have -problems with parity. You can disable either PCI parity or SCSI parity -checking by entering appropriate options from the boot command line. -(See 10: Boot setup commands). +checking. These features must be enabled in order to ensure safe +data transfers. Some flawed devices or mother boards may have problems +with parity. The options to defeat parity checking have been removed +from the driver. 7. Profiling information @@ -428,77 +426,90 @@ Synchronous transfers frequency (default answer: 80) 10.1 Syntax -Setup commands can be passed to the driver either at boot time or as a -string variable using 'insmod'. - -A boot setup command for this driver begins with the driver name "sym53c8xx=". -The kernel syntax parser then expects an optionnal list of integers separated -with comma followed by an optional list of comma-separated strings. +Setup commands can be passed to the driver either at boot time or as +parameters to modprobe, as described in Documentation/kernel-parameters.txt Example of boot setup command under lilo prompt: -lilo: linux root=/dev/sda2 sym53c8xx=tags:4,sync:10,debug:0x200 +lilo: linux root=/dev/sda2 sym53c8xx.cmd_per_lun=4 sym53c8xx.sync=10 sym53c8xx.debug=0x200 - enable tagged commands, up to 4 tagged commands queued. - set synchronous negotiation speed to 10 Mega-transfers / second. - set DEBUG_NEGO flag. -Since comma seems not to be allowed when defining a string variable using -'insmod', the driver also accepts <space> as option separator. -The following command will install driver module with the same options as -above. - - insmod sym53c8xx.o sym53c8xx="tags:4 sync:10 debug:0x200" +The following command will install the driver module with the same +options as above. -The integer list of arguments is discarded by the driver. - -Each string argument must be specified as "keyword:value". Only lower-case -characters and digits are allowed. + modprobe sym53c8xx cmd_per_lun=4 sync=10 debug=0x200" 10.2 Available arguments -10.2.1 Master parity checking - mpar:y enabled - mpar:n disabled - -10.2.2 Scsi parity checking - spar:y enabled - spar:n disabled - -10.2.3 Default number of tagged commands - tags:0 (or tags:1 ) tagged command queuing disabled - tags:#tags (#tags > 1) tagged command queuing enabled +10.2.1 Default number of tagged commands + cmd_per_lun=0 (or cmd_per_lun=1) tagged command queuing disabled + cmd_per_lun=#tags (#tags > 1) tagged command queuing enabled #tags will be truncated to the max queued commands configuration parameter. - This option also allows to specify a command queue depth for each device - that support tagged command queueing. + +10.2.2 Detailed control of tagged commands + This option allows you to specify a command queue depth for each device + that supports tagged command queueing. Example: - sym53c8xx=tags:10/t2t3q16-t5q24/t1u2q32 - will set devices queue depth as follow: + tag_ctrl=10/t2t3q16-t5q24/t1u2q32 + will set devices queue depth as follow: - controller #0 target #2 and target #3 -> 16 commands, - controller #0 target #5 -> 24 commands, - controller #1 target #1 logical unit #2 -> 32 commands, - all other logical units (all targets, all controllers) -> 10 commands. -10.2.4 Default synchronous period factor - sync:255 disabled (asynchronous transfer mode) - sync:#factor - #factor = 9 Ultra-3 SCSI 80 Mega-transfers / second (Wide only) - #factor = 10 Ultra-2 SCSI 40 Mega-transfers / second - #factor = 11 Ultra-2 SCSI 33 Mega-transfers / second - #factor < 25 Ultra SCSI 20 Mega-transfers / second - #factor < 50 Fast SCSI-2 - - In all cases, the driver will use the minimum transfer period supported by - controllers according to SYM53C8XX chip type. - -10.2.5 Verbosity level - verb:0 minimal - verb:1 normal - verb:2 too much - -10.2.6 Debug mode - debug:0 clear debug flags - debug:#x set debug flags +10.2.3 Burst max + burst=0 burst disabled + burst=255 get burst length from initial IO register settings. + burst=#x burst enabled (1<<#x burst transfers max) + #x is an integer value which is log base 2 of the burst transfers max. + By default the driver uses the maximum value supported by the chip. + +10.2.4 LED support + led=1 enable LED support + led=0 disable LED support + Do not enable LED support if your scsi board does not use SDMS BIOS. + (See 'Configuration parameters') + +10.2.4 Differential mode + diff=0 never set up diff mode + diff=1 set up diff mode if BIOS set it + diff=2 always set up diff mode + diff=3 set diff mode if GPIO3 is not set + +10.2.5 IRQ mode + irqm=0 always open drain + irqm=1 same as initial settings (assumed BIOS settings) + irqm=2 always totem pole + +10.2.6 Check SCSI BUS + buschk=<option bits> + + Available option bits: + 0x0: No check. + 0x1: Check and do not attach the controller on error. + 0x2: Check and just warn on error. + +10.2.7 Suggest a default SCSI id for hosts + hostid=255 no id suggested. + hostid=#x (0 < x < 7) x suggested for hosts SCSI id. + + If a host SCSI id is available from the NVRAM, the driver will ignore + any value suggested as boot option. Otherwise, if a suggested value + different from 255 has been supplied, it will use it. Otherwise, it will + try to deduce the value previously set in the hardware and use value + 7 if the hardware value is zero. + +10.2.8 Verbosity level + verb=0 minimal + verb=1 normal + verb=2 too much + +10.2.9 Debug mode + debug=0 clear debug flags + debug=#x set debug flags #x is an integer value combining the following power-of-2 values: DEBUG_ALLOC 0x1 DEBUG_PHASE 0x2 @@ -517,55 +528,17 @@ characters and digits are allowed. You can play safely with DEBUG_NEGO. However, some of these flags may generate bunches of syslog messages. -10.2.7 Burst max - burst:0 burst disabled - burst:255 get burst length from initial IO register settings. - burst:#x burst enabled (1<<#x burst transfers max) - #x is an integer value which is log base 2 of the burst transfers max. - By default the driver uses the maximum value supported by the chip. +10.2.10 Settle delay + settle=n delay for n seconds -10.2.8 LED support - led:1 enable LED support - led:0 disable LED support - Donnot enable LED support if your scsi board does not use SDMS BIOS. - (See 'Configuration parameters') + After a bus reset, the driver will delay for n seconds before talking + to any device on the bus. The default is 3 seconds and safe mode will + default it to 10. -10.2.9 Max wide - wide:1 wide scsi enabled - wide:0 wide scsi disabled - Some scsi boards use a 875 (ultra wide) and only supply narrow connectors. - If you have connected a wide device with a 50 pins to 68 pins cable - converter, any accepted wide negotiation will break further data transfers. - In such a case, using "wide:0" in the bootup command will be helpfull. - -10.2.10 Differential mode - diff:0 never set up diff mode - diff:1 set up diff mode if BIOS set it - diff:2 always set up diff mode - diff:3 set diff mode if GPIO3 is not set - -10.2.11 IRQ mode - irqm:0 always open drain - irqm:1 same as initial settings (assumed BIOS settings) - irqm:2 always totem pole - -10.2.12 Reverse probe - revprob:n probe chip ids from the PCI configuration in this order: - 810, 815, 825, 860, 875, 885, 875A, 895, 896, 895A, - 1510D, 1010-33, 1010-66. - revprob:y probe chip ids in the reverse order. - -10.2.13 Fix up PCI configuration space - pcifix:<option bits> - - Available option bits: - 0x0: No attempt to fix PCI configuration space registers values. - 0x1: Set PCI cache-line size register if not set. - 0x2: Set write and invalidate bit in PCI command register. - -10.2.14 Serial NVRAM - nvram:n do not look for serial NVRAM - nvram:y test controllers for onboard serial NVRAM +10.2.11 Serial NVRAM + NB: option not currently implemented. + nvram=n do not look for serial NVRAM + nvram=y test controllers for onboard serial NVRAM (alternate binary form) nvram=<bits options> 0x01 look for NVRAM (equivalent to nvram=y) @@ -574,105 +547,28 @@ characters and digits are allowed. 0x08 ignore NVRAM "Scan at boot time" parameter for all devices 0x80 also attach controllers set to OFF in the NVRAM (sym53c8xx only) -10.2.15 Check SCSI BUS - buschk:<option bits> - - Available option bits: - 0x0: No check. - 0x1: Check and do not attach the controller on error. - 0x2: Check and just warn on error. - -10.2.16 Exclude a host from being attached - excl=<io_address> +10.2.12 Exclude a host from being attached + excl=<io_address>,... Prevent host at a given io address from being attached. - For example 'sym53c8xx=excl:0xb400,excl:0xc000' indicate to the + For example 'excl=0xb400,0xc000' indicate to the driver not to attach hosts at address 0xb400 and 0xc000. -10.2.17 Suggest a default SCSI id for hosts - hostid:255 no id suggested. - hostid:#x (0 < x < 7) x suggested for hosts SCSI id. - - If a host SCSI id is available from the NVRAM, the driver will ignore - any value suggested as boot option. Otherwise, if a suggested value - different from 255 has been supplied, it will use it. Otherwise, it will - try to deduce the value previously set in the hardware and use value - 7 if the hardware value is zero. - -10.3 PCI configuration fix-up boot option - -pcifix:<option bits> - -Available option bits: - 0x1: Set PCI cache-line size register if not set. - 0x2: Set write and invalidate bit in PCI command register. +10.3 Converting from old style options -Use 'pcifix:3' in order to allow the driver to fix both PCI features. +Previously, the sym2 driver accepted arguments of the form + sym53c8xx=tags:4,sync:10,debug:0x200 -Recent SYMBIOS 53C8XX scsi processors are able to use PCI read multiple -and PCI write and invalidate commands. These features require the -cache line size register to be properly set in the PCI configuration -space of the chips. On the other hand, chips will use PCI write and -invalidate commands only if the corresponding bit is set to 1 in the -PCI command register. +As a result of the new module parameters, this is no longer available. +Most of the options have remained the same, but tags has split into +cmd_per_lun and tag_ctrl for its two different purposes. The sample above +would be specified as: + modprobe sym53c8xx cmd_per_lun=4 sync=10 debug=0x200 -Not all PCI bioses set the PCI cache line register and the PCI write and -invalidate bit in the PCI configuration space of 53C8XX chips. -Optimized PCI accesses may be broken for some PCI/memory controllers or -make problems with some PCI boards. +or on the kernel boot line as: + sym53c8xx.cmd_per_lun=4 sym53c8xx.sync=10 sym53c8xx.debug=0x200 -10.4 Serial NVRAM support boot option - -nvram:n do not look for serial NVRAM -nvram:y test controllers for onboard serial NVRAM - -This option can also been entered as an hexadecimal value that allows -to control what information the driver will get from the NVRAM and what -information it will ignore. -For details see '17. Serial NVRAM support'. - -When this option is enabled, the driver tries to detect all boards using -a Serial NVRAM. This memory is used to hold user set up parameters. - -The parameters the driver is able to get from the NVRAM depend on the -data format used, as follow: - - Tekram format Symbios format -General and host parameters - Boot order N Y - Host SCSI ID Y Y - SCSI parity checking Y Y - Verbose boot messages N Y -SCSI devices parameters - Synchronous transfer speed Y Y - Wide 16 / Narrow Y Y - Tagged Command Queuing enabled Y Y - Disconnections enabled Y Y - Scan at boot time N Y - -In order to speed up the system boot, for each device configured without -the "scan at boot time" option, the driver forces an error on the -first TEST UNIT READY command received for this device. - -Some SDMS BIOS revisions seem to be unable to boot cleanly with very fast -hard disks. In such a situation you cannot configure the NVRAM with -optimized parameters value. - -The 'nvram' boot option can be entered in hexadecimal form in order -to ignore some options configured in the NVRAM, as follow: - -nvram=<bits options> - 0x01 look for NVRAM (equivalent to nvram=y) - 0x02 ignore NVRAM "Synchronous negotiation" parameters for all devices - 0x04 ignore NVRAM "Wide negotiation" parameter for all devices - 0x08 ignore NVRAM "Scan at boot time" parameter for all devices - 0x80 also attach controllers set to OFF in the NVRAM (sym53c8xx only) - -Option 0x80 is disabled by default. -Result is that, by default (option not set), the sym53c8xx driver will not -attach controllers set to OFF in the NVRAM. - -10.5 SCSI BUS checking boot option. +10.4 SCSI BUS checking boot option. When this option is set to a non-zero value, the driver checks SCSI lines logic state, 100 micro-seconds after having asserted the SCSI RESET line. @@ -805,14 +701,8 @@ serial NVRAM is used by Symbios and Tekram to hold set up parameters for the host adaptor and it's attached drives. The Symbios NVRAM also holds data on the boot order of host adaptors in a -system with more than one host adaptor. This enables the order of scanning -the cards for drives to be changed from the default used during host adaptor -detection. - -This can be done to a limited extent at the moment using "reverse probe" but -this only changes the order of detection of different types of cards. The -NVRAM boot order settings can do this as well as change the order the same -types of cards are scanned in, something "reverse probe" cannot do. +system with more than one host adaptor. This information is no longer used +as it's fundamentally incompatible with the hotplug PCI model. Tekram boards using Symbios chips, DC390W/F/U, which have NVRAM are detected and this is used to distinguish between Symbios compatible and Tekram host @@ -824,6 +714,26 @@ used together with the Symbios cards using all their features, including enabled when using Tekram cards. It does nothing useful for Tekram host adaptors but does not cause problems either.) +The parameters the driver is able to get from the NVRAM depend on the +data format used, as follow: + + Tekram format Symbios format +General and host parameters + Boot order N Y + Host SCSI ID Y Y + SCSI parity checking Y Y + Verbose boot messages N Y +SCSI devices parameters + Synchronous transfer speed Y Y + Wide 16 / Narrow Y Y + Tagged Command Queuing enabled Y Y + Disconnections enabled Y Y + Scan at boot time N Y + +In order to speed up the system boot, for each device configured without +the "scan at boot time" option, the driver forces an error on the +first TEST UNIT READY command received for this device. + 17.2 Symbios NVRAM layout diff --git a/Documentation/sound/oss/ChangeLog.awe b/Documentation/sound/oss/ChangeLog.awe deleted file mode 100644 index 330cc0e5f10278..00000000000000 --- a/Documentation/sound/oss/ChangeLog.awe +++ /dev/null @@ -1,230 +0,0 @@ -ver.0.4.3p4 - - Bug fix for invalid memory detection when initialized twice - - Add sample sharing function - works together with awesfx-0.4.3p3 - - Add AWE_PROBE_DATA for probing sample id - -ver.0.4.3p3 - - Replace memset to MEMSET (for FreeBSD) - - Add PAN_EXCHANGE switch - -ver.0.4.3p2 - - MIDI emulation device is added - - Controls volume and filter targets - - Include chorus/reverb/equalizer values in MISC_MODE - -ver.0.4.3p1 - - Change the volume calculation method - - Support for Tom Lees' PnP driver (v0.3) - -ver.0.4.2d - - Support for OSS/Free 3.8 on 2.0 kernels. - - Support for Linux PnP driver - - Support for module (for recent 2.1 kernels and RH5.0) - - Support for FreeBSD-3.0 system - -ver.0.4.2c - - Add a mode to enable drum channel toggle via bank number - change. - -ver.0.4.2b - - Clear voice position after note on - - Change nrvoices according to the current playing mode - -ver.0.4.2a - - Fix a bug in pitch calculation with scale parameter - - Change default chorus & reverb modes - -ver.0.4.2 - - Use indirect voice allocation mode; used as default mode - - Add preset mapping - - Free buffers when resetting samples - - Set default preset/bank/drumset as variable - - Fix a bug in exclusive note-off - - Add channel reset control macro - - Change modwheel sensitivity as variable - - Add lock option in open_patch - - Add channel priority mode macro, and disable it as default - - Add unset effect macro - - Add user defined chorus/reverb modes - - Do not initialize effect parameters when allocating voices - - Accept realtime filter-Q parameter change - - Check value range of set/add effects - - Change drum flags automatically when receiving bank #128 - -ver.0.4.1 development versions - -ver.0.4.0c - - Fix kernel oops when setting AWE_FX_ATTEN - -ver.0.4.0b - - Do not kill_note in start_note when velocity is zero - -ver.0.4.0a - - Fix a bug in channel pressure effects - -ver.0.4.0 - - Support dynamic buffer allocation - - Add functions to open/close/unload a patch - - Change from pointer to integer index in voice/sample lists - - Support for Linux/Alpha-AXP - - Fix for FreeBSD - - Add sostenuto control - - Add midi channel priority - - Fix a bug in all notes off control - - Use AWE_DEFAULT_MEMSIZE always if defined - - Fix a bug in awe_reset causes seg fault when no DRAM onboard - - Use awe_mem_start variable instead of constant - -ver.0.3.3c - - Fix IOCTL_TO_USER for OSS-3.8 (on Linux-2.1.25) - - Fix i/o macros for mixer controls - -ver.0.3.3b - - Fix version number in awe_version.h - - Fix a small bug in noteoff/release all - -ver.0.3.3a - - Fix all notes/sounds off - - Add layer effect control - - Add misc mode controls; realtime pan, version number, etc. - - Move gus bank control in misc mode control - - Modify awe_operations for OSS3.8b5 - - Fix installation script - -ver.0.3.3 - - Add bass/treble control in Emu8000 chip - - Add mixer device - - Fix sustain on to value 127 - -ver.0.3.2 - - Refuse linux-2.0.0 at installation - - Move awe_voice.h to /usr/include/linux - -ver.0.3.1b (not released) - - Rewrite chorus/reverb mode change functions - - Rewrite awe_detect & awe_check_dram routines - -ver.0.3.1a - - Fix a bug to reset voice counter in awe_reset - - Fix voice balance on GUS mode - - Make symlink on /usr/include/asm in install script - -ver.0.3.1 - - Remove zero size arrays from awe_voice.h - - Fix init_fm routine - - Remove all samples except primary samples in REMOVE_LAST_SAMPLES - -ver.0.3.0a - - Add AWE_NOTEOFF_ALL control - - Remove AWE_INIT_ATTEN control - -ver.0.3.0 - - Fix decay time table - - Add exclusive sounds mode - - Add capability to get current status - -ver.0.2.99e - - Add #ifdef for all sounds/notes off controls. - - Fix bugs on searching the default drumset/preset. - - Fix usslite patch to modify the default Config.in. - -ver.0.2.99d - - Fix bugs of attack/hold parameters - - Fix attack & decay time table - -ver.0.2.99c - - Change volume control messages (main & expression volume) - to accesspt normal MIDI parameters in channel mode. - - Use channel mode in SEQ2 controls. - -ver.0.2.99b - - #ifdef patch manager functions (for OSS-3.7) - -ver.0.2.99a - - Fix sustain bug - -ver.0.2.99 (0.3 beta) - - Support multiple instruments - -ver.0.2.0c - - Add copyright notice - - FreeBSD 2.2-ALPHA integration - -ver.0.2.0b - - Remove buffered reading appended in v0.2.0a - - Remove SMAxW register check on writing - - Support Linux 2.1.x kernel - - Rewrite installation script - -ver.0.2.0a - - Define SEQUENCER_C for tuning.h for FreeBSD system - - Improvement of sample loading speed - - Fix installation script - - Add PnP driver functions for ISA PnP driver support - -ver.0.2.0 - - Includes FreeBSD port - - Can load GUS compatible patches - - Change values of hardware control parameters for compatibility - with GUS driver - - Accept 8bit or unsigned wave data - - Accept no blank loop data - - Add sample mode flags in sample_info - -ver.0.1.6 - - Add voice effects control - - Fix awe_voice.h for word alignment - -ver.0.1.5c - - Fix FM(OPL) playback problem - -ver.0.1.5b - - Fix pitch calculation for fixed midi key - -ver.0.1.5a - - Fix bugs in removing samples from linked list. - -ver.0.1.5 - - Add checksum verification for sample uploading - (not compatible from older sample_info structure) - - Fix sample offset pointers to (actual value - 1) - - Add sequencer command to initialize awe32 - -ver.0.1.4c - - Fix card detection and memory check function to avoid system crash - at booting - -ver.0.1.4b - - Add release sustain mode - - Initialize FM each time after loading samples - -ver.0.1.4a - - Fix AWE card detection code - - Correct FM initialize position - - Add non-releasing mode on voice info - -ver.0.1.4 - - Add AWE card and DRAM detection codes - - Add FM initialization code - - Modify volume control - - Remove linear volume mode - - Change memory management; not using malloc dynamically - - Add remove-samples command - - Use internal id implicitly at loading samples - -ver.0.1.3 - - Fix a bug on patch uploading to RAM - -ver.0.1.2 - - Divide to separated packages - - Fix disagreed macro conditions - - Fix unresolved function bugs - - Integrate VoxWare and USS-Lite driver source (awe_voice.c) - and remove awe_card.c - -ver.0.1.1 - - Fix wrong sample numbers in sbktext - - Fix txt2sfx bug - - Fix pan parameter calculation - - Append USS-Lite/Linux2.0 driver - diff --git a/Documentation/sound/oss/ChangeLog.multisound b/Documentation/sound/oss/ChangeLog.multisound deleted file mode 100644 index a05a74365dd354..00000000000000 --- a/Documentation/sound/oss/ChangeLog.multisound +++ /dev/null @@ -1,213 +0,0 @@ -1998-12-04 Andrew T. Veliath <andrewtv@usa.net> - - * Update version to 0.8.2.2 - - * Add msndreset program to shell archive. - -1998-11-11 Andrew T. Veliath <andrewv@usa.net> - - * msnd_pinnacle.c (mixer_ioctl): Add a mixer ioctl for - SOUND_MIXER_PRIVATE1 which does a full reset on the card. - (mixer_set): Move line in recording source to input monitor, aux - input level added, some mixer fixes. - -1998-09-10 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.8.2 - - * Add SNDCTL_DSP_GETOSPACE and SNDCTL_DSP_GETISPACE ioctls. - -1998-09-09 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.8.1 - - * msnd_pinnacle.c: Fix resetting of default audio parameters. Turn - flush code from dsp_halt into dsp_write_flush, and use that for - SNDCTL_DSP_SYNC. - -1998-09-07 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.8.0 - - * Provide separate signal parameters for play and record. - - * Cleanups to locking and interrupt handling, change default - fifosize to 128kB. - - * Update version to 0.7.15 - - * Interprocess full-duplex support (ie `cat /dev/dsp > /dev/dsp'). - - * More mutex sections for read and write fifos (read + write locks - added). - -1998-09-05 Andrew Veliath <andrewtv@usa.net> - - * msnd_pinnacle.c: (chk_send_dsp_cmd) Do full DSP reset upon DSP - timeout (when not in interrupt; maintains mixer settings). Fixes - to flushing and IRQ ref counting. Rewrote queuing for smoother - playback and fixed initial playback cutoff problem. - -1998-09-03 Andrew Veliath <andrewtv@usa.net> - - * Replaced packed structure accesses with standard C equivalents. - -1998-09-01 Andrew Veliath <andrewtv@usa.net> - - * msnd_pinnacle.c: Add non-PnP configuration to driver code, which - will facilitate compiled-in operation. - -1998-08-29 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.7.6 - - * msnd_pinnacle.c (dsp_ioctl): Add DSP_GETFMTS, change SAMPLESIZE - to DSP_SETFMT. - - * Update version to 0.7.5 - - * Create pinnaclecfg.c and turn MultiSound doc into a shell - archive with pinnaclecfg.c included. pinnaclecfg.c can - now fully configure the card in non-PnP mode, including the - joystick and IDE controller. Also add an isapnp conf - example. - - * Reduce DSP reset timeout from 20000 to 100 - -1998-08-06 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.7.2 - - * After A/D calibration, do an explicit set to the line input, - rather than using set_recsrc - -1998-07-20 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.7.1 - - * Add more OSS ioctls - -1998-07-19 Andrew Veliath <andrewtv@usa.net> - - * Update doc file - - * Bring back DIGITAL1 with digital parameter to msnd_pinnacle.c - and CONFIG_MSNDPIN_DIGITAL. I'm not sure this actually works, - since I find audio playback goes into a very speeded mode of - operation, however it might be due to a lack of a digital - source, which I don't have to test. - -1998-07-18 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.7.0 - - * Can now compile with Alan Cox' 2.0.34-modular-sound patch (so - now it requires >= 2.1.106 or 2.0.34-ms) (note for 2.0.34-ms it - is in the Experimental section) - - * More modularization, consolidation, also some MIDI hooks - installed for future MIDI modules - - * Write flush - - * Change default speed, channels, bit size to OSS/Free defaults - -1998-06-02 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.5b - - * Fix version detection - - * Remove underflow and overflow resets (delay was too long) - - * Replace spinlocked bitops with atomic bit ops - -1998-05-27 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.5a - - * Better recovery from underflow or overflow conditions - - * Fix a deadlock condition with one thread reading and the other - writing - -1998-05-26 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.5 - - * Separate reset queue functions for play and record - - * Add delays in dsp_halt - -1998-05-24 Andrew Veliath <andrewtv@usa.net> - - * Add a check for Linux >= 2.1.95 - - * Remove DIGITAL1 input until I figure out how to make it work - - * Add HAVE_DSPCODEH which when not defined will load firmware from - files using mod_firmware_load, then release memory after they - are uploaded (requires reorganized OSS). - -1998-05-22 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.4c - - * Hopefully fix the mixer volume problem - -1998-05-19 Andrew Veliath <andrewtv@usa.net> - - * Add __initfuncs and __initdatas to reduce resident code size - - * Move bunch of code around, remove some protos - - * Integrate preliminary changes for Alan Cox's OSS reorganization - for non-OSS drivers to coexist with OSS devices on the same - major. To compile standalone, must now define STANDALONE. - -1998-05-16 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.4b - - * Integrated older card support into a unified driver, tested on a - MultiSound Classic c/o Kendrick Vargas. - -1998-05-15 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.4 - - * Fix read/write return values - -1998-05-13 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.3 - - * Stop play gracefully - - * Add busy flag - - * Add major and calibrate_signal module parameters - - * Add ADC calibration - - * Add some OSS compatibility ioctls - - * Add mixer record selection - - * Add O_NONBLOCK support, separate read/write wait queues - - * Add sample bit size ioctl, expanded sample rate ioctl - - * Playback suspension now resumes - - * Use signal_pending after interruptible_sleep_on - - * Add recording, change ints to bit flags - -1998-05-11 Andrew Veliath <andrewtv@usa.net> - - * Update version to 0.2 - - * Add preliminary playback support - - * Use new Turtle Beach DSP code
\ No newline at end of file diff --git a/Documentation/usb/sn9c102.txt b/Documentation/usb/sn9c102.txt index 40c2f73a707fd6..18ceabdb36e41a 100644 --- a/Documentation/usb/sn9c102.txt +++ b/Documentation/usb/sn9c102.txt @@ -9,28 +9,32 @@ Index ===== 1. Copyright -2. License -3. Overview -4. Module dependencies -5. Module loading -6. Module parameters -7. Optional device control through "sysfs" -8. Supported devices -9. How to add support for new image sensors -10. Notes for V4L2 application developers -11. Contact information -12. Credits +2. Disclaimer +3. License +4. Overview +5. Driver installation +6. Module loading +7. Module parameters +8. Optional device control through "sysfs" +9. Supported devices +10. How to add support for new image sensors +11. Notes for V4L2 application developers +12. Contact information +13. Credits 1. Copyright ============ Copyright (C) 2004 by Luca Risolia <luca.risolia@studio.unibo.it> + +2. Disclaimer +============= SONiX is a trademark of SONiX Technology Company Limited, inc. -This driver is not sponsored or developed by SONiX. +This software is not sponsored or developed by SONiX. -2. License +3. License ========== This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -47,29 +51,52 @@ along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -3. Overview +4. Overview =========== This driver attempts to support the video and audio streaming capabilities of the devices mounting the SONiX SN9C101, SN9C102 and SN9C103 (or SUI-102) PC Camera Controllers. -- It's worth to note that SONiX has never collaborated with me during the +It's worth to note that SONiX has never collaborated with the author during the development of this project, despite several requests for enough detailed specifications of the register tables, compression engine and video data format -of the above chips - - -Up to 64 cameras can be handled at the same time. They can be connected and -disconnected from the host many times without turning off the computer, if -your system supports hotplugging. +of the above chips. The driver relies on the Video4Linux2 and USB core modules. It has been designed to run properly on SMP systems as well. The latest version of the SN9C10x driver can be found at the following URL: -http://go.lamarinapunto.com/ - - -4. Module dependencies +http://www.linux-projects.org/ + +Some of the features of the driver are: + +- full compliance with the Video4Linux2 API (see also "Notes for V4L2 + application developers" paragraph); +- available mmap or read/poll methods for video streaming through isochronous + data transfers; +- automatic detection of image sensor; +- support for any window resolutions and optional panning within the maximum + pixel area of image sensor; +- image downscaling with arbitrary scaling factors from 1, 2 and 4 in both + directions (see "Notes for V4L2 application developers" paragraph); +- two different video formats for uncompressed or compressed data (see also + "Notes for V4L2 application developers" paragraph); +- full support for the capabilities of many of the possible image sensors that + can be connected to the SN9C10x bridges, including, for istance, red, green, + blue and global gain adjustments and exposure (see "Supported devices" + paragraph for details); +- use of default color settings for sunlight conditions; +- dynamic I/O interface for both SN9C10x and image sensor control (see + "Optional device control through 'sysfs'" paragraph); +- dynamic driver control thanks to various module parameters (see "Module + parameters" paragraph); +- up to 64 cameras can be handled at the same time; they can be connected and + disconnected from the host many times without turning off the computer, if + your system supports hotplugging; +- no known bugs. + + +5. Module dependencies ====================== For it to work properly, the driver needs kernel support for Video4Linux and USB. @@ -101,7 +128,7 @@ And finally: CONFIG_USB_SN9C102=m -5. Module loading +6. Module loading ================= To use the driver, it is necessary to load the "sn9c102" module into memory after every other module required: "videodev", "usbcore" and, depending on @@ -109,7 +136,6 @@ the USB host controller you have, "ehci-hcd", "uhci-hcd" or "ohci-hcd". Loading can be done as shown below: - [root@localhost home]# modprobe usbcore [root@localhost home]# modprobe sn9c102 At this point the devices should be recognized. You can invoke "dmesg" to @@ -118,7 +144,7 @@ analyze kernel messages and verify that the loading process has gone well: [user@localhost home]$ dmesg -6. Module parameters +7. Module parameters ==================== Module parameters are listed below: ------------------------------------------------------------------------------- @@ -144,12 +170,14 @@ Description: Debugging information level, from 0 to 3: 2 = significant informations 3 = more verbose messages Level 3 is useful for testing only, when only one device - is used. + is used. It also shows some more informations about the + hardware being detected. This parameter can be changed at + runtime thanks to the /sys filesystem. Default: 2 ------------------------------------------------------------------------------- -7. Optional device control through "sysfs" +8. Optional device control through "sysfs" ========================================== It is possible to read and write both the SN9C10x and the image sensor registers by using the "sysfs" filesystem interface. @@ -191,10 +219,10 @@ Note that the SN9C10x always returns 0 when some of its registers are read. To avoid race conditions, all the I/O accesses to the files are serialized. -8. Supported devices +9. Supported devices ==================== -- I won't mention any of the names of the companies as well as their products -here. They have never collaborated with me, so no advertising - +None of the names of the companies as well as their products will be mentioned +here. They have never collaborated with the author, so no advertising. From the point of view of a driver, what unambiguously identify a device are its vendor and product USB identifiers. Below is a list of known identifiers of @@ -241,7 +269,7 @@ Vendor ID Product ID 0x0c45 0x60bc 0x0c45 0x60be -The list above does NOT imply that all those devices work with this driver: up +The list above does not imply that all those devices work with this driver: up until now only the ones that mount the following image sensors are supported; kernel messages will always tell you whether this is the case: @@ -259,16 +287,16 @@ If you think your camera is based on the above hardware and is not actually listed in the above table, you may try to add the specific USB VendorID and ProductID identifiers to the sn9c102_id_table[] in the file "sn9c102_sensor.h"; then compile, load the module again and look at the kernel output. -If this works, please send an email to me reporting the kernel messages, so -that I can add a new entry in the list of supported devices. +If this works, please send an email to the author reporting the kernel +messages, so that a new entry in the list of supported devices can be added. Donations of new models for further testing and support would be much -appreciated. I won't add official support for hardware that I don't actually -have. +appreciated. Non-available hardware won't be supported by the author of this +driver. -9. How to add support for new image sensors -=========================================== +10. How to add support for new image sensors +============================================ It should be easy to write code for new sensors by using the small API that I have created for this purpose, which is present in "sn9c102_sensor.h" (documentation is included there). As an example, have a look at the code in @@ -278,7 +306,7 @@ At the moment, possible unsupported image sensors are: HV7131x series (VGA), MI03x series (VGA), OV7620 (VGA), OV7630 (VGA), CIS-VF10 (VGA). -10. Notes for V4L2 application developers +11. Notes for V4L2 application developers ========================================= This driver follows the V4L2 API specifications. In particular, it enforces two rules: @@ -301,8 +329,18 @@ factor can be chosen arbitrarily by the "negotiation" of the "source" and that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the scaling factor is restored to 1. +This driver supports two different video formats: the first one is the "8-bit +Sequential Bayer" format and can be used to obtain uncompressed video data +from the device through the current I/O method, while the second one provides +"raw" compressed video data (without the initial and final frame headers). The +compression quality may vary from 0 to 1 and can be selected or queried thanks +to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP V4L2 ioctl's. For maximum +flexibility, the default active video format depends on how the image sensor +being used is initialized (as described in the documentation of the API for the +image sensors supplied by this driver). + -11. Contact information +12. Contact information ======================= I may be contacted by e-mail at <luca.risolia@studio.unibo.it>. @@ -311,7 +349,7 @@ My public 1024-bit key should be available at any keyserver; the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. -12. Credits +13. Credits =========== I would thank the following persons: |