diff options
| author | Ralf Baechle <ralf@linux-mips.org> | 2000-02-05 06:47:02 +0000 |
|---|---|---|
| committer | Ralf Baechle <ralf@linux-mips.org> | 2000-02-05 06:47:02 +0000 |
| commit | 99a7e12f34b3661a0d1354eef83a0eef4df5e34c (patch) | |
| tree | 3560aca9ca86792f9ab7bd87861ea143a1b3c7a3 /Documentation | |
| parent | e73a04659c0b8cdee4dd40e58630e2cf63afb316 (diff) | |
Merge with Linux 2.3.38.
Diffstat (limited to 'Documentation')
62 files changed, 5064 insertions, 769 deletions
diff --git a/Documentation/Changes b/Documentation/Changes index 1fff8e7bd..fd4072bc0 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -188,7 +188,7 @@ to find out the proper way to upgrade it. No, the instruction to "rm You must use binutils 2.9.1.0.7 or later. Latest release is 2.9.1.0.25. Beware that binutils 2.9.1 (note the absence of a suffix) from the FSF does not work. If you are upgrading from earlier versions, you should -consider upgrading to the latest 2.9.5.0.x release. +consider upgrading to the latest 2.9.5.0.x (beta) release. Gnu C ===== @@ -526,10 +526,10 @@ ftp://ftp.varesearch.com/pub/support/hjl/binutils/2.9.1/binutils-2.9.1.0.25.tar. Installation notes: ftp://ftp.varesearch.com/pub/support/hjl/binutils/2.9.1/release.binutils-2.9.1.0.25 -The 2.9.5.0.16 release: -ftp://ftp.varesearch.com/pub/support/hjl/binutils/binutils-2.9.5.0.16.tar.bz2 +The 2.9.5.0.22 release: +ftp://ftp.varesearch.com/pub/support/hjl/binutils/binutils-2.9.5.0.22.tar.bz2 Installation notes: -ftp://ftp.varesearch.com/pub/support/hjl/binutils/release.binutils-2.9.5.0.16 +ftp://ftp.varesearch.com/pub/support/hjl/binutils/release.binutils-2.9.5.0.22 Gnu C ===== @@ -815,15 +815,15 @@ your favorite Red Hat mirror site before installing the non-RPM version. Remember, you might need to use the --force option to get the upgrade to install. ftp://contrib.redhat.com/ , ftp://developer.redhat.com/ , or ftp://updates.redhat.com/ will have -almost everything you need, and Red Hat 5.2 ships with most necessary +almost everything you need, and Red Hat 6.1 ships with most necessary software. Those of you running Debian (or a different distribution that supports .deb packages) can look in the "unstable" and "project/experimental" directories of your favorite Debian mirror. The -Debian 2.0 release ships with most packages you need as well. +Debian 2.2 release will ship with most packages you need as well. -Please send info about any other packages that 2.2 "broke" or about any -new features of 2.2 that require extra or new packages for use to Chris +Please send info about any other packages that 2.3 "broke" or about any +new features of 2.3 that require extra or new packages for use to Chris Ricker (kaboom@gatech.edu or chris.ricker@m.cc.utah.edu). diff --git a/Documentation/Configure.help b/Documentation/Configure.help index 239cd39f9..bb54b9b48 100644 --- a/Documentation/Configure.help +++ b/Documentation/Configure.help @@ -449,6 +449,8 @@ CONFIG_BLK_DEV_IDETAPE to the SCSI protocol. If you have an SCSI tape drive however, you can say N here. + This now includes the OnStream DI-30 tape drive support. + If you say Y here, the tape drive will be identified at boot time along with other IDE devices, as "hdb" or "hdc", or something similar, and will be mapped to a character device such as "ht0" @@ -2629,7 +2631,7 @@ CONFIG_PARPORT drive, PLIP link (Parallel Line Internet Protocol is mainly used to create a mini network by connecting the parallel ports of two local machines) etc., then you need to say Y here; please read - Documentation/parport.txt and drivers/misc/BUGS-parport. + Documentation/parport.txt and drivers/parport/BUGS-parport. For extensive information about drivers for many devices attaching to the parallel port see http://www.torque.net/linux-pp.html on the @@ -5643,6 +5645,9 @@ CONFIG_AIRONET4500 channel=1..? meaningful in adhoc mode all other parameters can be set via proc interface These parameters belong to .._card module, but alas, they are here + if you have problems with screwin up card, both_bap_lock=1 is conservative + value (performance hit 15%) + for any other configuration options look at ..._proc module Aironet 4500/4800 ISA/PCI/PNP/365 support CONFIG_AIRONET4500_NONCS @@ -5698,7 +5703,8 @@ CONFIG_AIRONET4500_PROC NOTE: it takes lot of memory. Compile it as module and remove after configuration module: aironet4500_proc - + additional info: look into drivers/net/aironet4500_rids.c + this is quite human-readable(no need to know C) @@ -7575,9 +7581,18 @@ CONFIG_TMS380TR read the Token-Ring mini-HOWTO, available from http://metalab.unc.edu/mdw/linux.html#howto . - Also read the file linux/Documentation/networking/sktr.txt or check + Also read the file linux/Documentation/networking/tms380tr.txt or check http://www.auk.cx/tms380tr/ +SMC ISA TokenRing adapter support +CONFIG_SMCTR + This is support for the ISA SMC Token Ring cards, specifically + SMC TokenCard Elite (8115T) and SMC TokenCard Elite/A (8115T/A) adapters. + + If you have such an adapter and would like to use it, say Y or M and + read the Token-Ring mini-HOWTO, available from + http://metalab.unc.edu/mdw/linux.html#howto . + Traffic Shaper (EXPERIMENTAL) CONFIG_SHAPER The traffic shaper is a virtual network device that allows you to @@ -7940,18 +7955,18 @@ CONFIG_QUOTA Support for USB (EXPERIMENTAL) CONFIG_USB Universal Serial Bus (USB) is a specification for a serial bus - system which offers higher speeds and more features than the + subsystem which offers higher speeds and more features than the traditional PC serial port. The bus supplies power to peripherals and allows for hot swapping. Up to 127 USB peripherals can be - connected to a single USB port in a tree structure; the USB port is - the root of the tree, the peripherals are the leafs and the inner - nodes are special USB devices called hubs. Many newer PC's have USB + connected to a single USB port in a tree structure. The USB port is + the root of the tree, the peripherals are the leaves, and the inner + nodes are special USB devices called hubs. Many newer PCs have USB ports and newer peripherals such as scanners, keyboards, mice, - modems and printers support the USB protocol and can be connected to - the PC via those ports. + modems, and printers support the USB protocol and can be connected + to the PC via those ports. Say Y here if your computer has a USB port and you want to - experiment with USB devices. You then need to say Y to at least one + use USB devices. You then need to say Y to at least one of "UHCI support" or "OHCI support" below (the type of interface that the USB hardware in your computer provides) and then choose from among the drivers for USB peripherals. @@ -7961,116 +7976,110 @@ CONFIG_USB The module will be called usbcore.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -UHCI (intel PIIX4 and others) support? +UHCI (intel PIIX4, VIA, and others) support? CONFIG_USB_UHCI The Universal Host Controller Interface is a standard by Intel for accessing the USB hardware in the PC (which is also called the USB host controller). If your USB host controller conforms to this - standard, say Y. All recent boards with Intel PCI chipsets conform - to this standard. If unsure, say Y. + standard, say Y. All recent boards with Intel PCI chipsets (like + intel 430TX, 440FX, 440LX, 440BX, i810, i820) conform to this standard. + Also all VIA PCI chipsets (like VIA VP2, VP3, MVP3, Apollo Pro, Apollo + Pro II or Apollo Pro 133). + If unsure, say Y. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module will be called usb-uhci.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -OHCI (compaq and some others) support? -CONFIG_USB_OHCI - The Open Host Controller Interface is a standard by Compaq for - accessing the USB PC hardware (also called USB host controller). If - your USB host controller conforms to this standard, say Y. The USB - host controllers on most non-Intel architectures and on several x86 - compatibles with non-Intel chipsets conform to this standard. - - There are currently two OHCI drivers in development. You should - compile at most one. The other one is "OHCI-HCD (other OHCI opt. - Virt. Root Hub) support?", below. - - You may want to read the file drivers/usb/README.ohci. - - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called usb-ohci.o. If you want to compile it as a - module, say M here and read Documentation/modules.txt. - -Enable tons of OHCI debugging output -CONFIG_USB_OHCI_DEBUG - Say Y here in order to have the OHCI code generate verbose debugging - output. - -OHCI-HCD (other OHCI opt. Virt. Root Hub) support? +OHCI-HCD (Compaq, iMacs, OPTi, SiS, ALi, and others) support? CONFIG_USB_OHCI_HCD - This is an alternative driver for USB PC hardware (also called USB - host controller) which complies with Compaq's Open Host Controller - Interface. You may want to read the file - drivers/usb/README.ohci_hcd. + The Open Host Controller Interface is a standard by + Compaq/Microsoft/National for accessing the USB PC hardware (also + called USB host controller). If your USB host controller conforms + to this standard, say Y. The USB host controllers on most + non-Intel architectures and on several x86 compatibles with non-Intel + chipsets - like SiS (aktual 610, 610 and so on) or ALi (ALi IV, ALi V, + Aladin Pro..) - conform to this standard. - There are currently two OHCI drivers in development. You should - compile at most one. The other one is "OHCI (compaq and some others) - support?", above. + You may want to read the file drivers/usb/README.ohci_hcd. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module will be called usb-ohci-hcd.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -OHCI-HCD Virtual Root Hub -CONFIG_USB_OHCI_VROOTHUB - The virtual root hub support is currently unstable, so you probably - want to say N unless you are a hacker. But you aren't a hacker since - you are reading help texts. - -Enable lots of ISOC debugging output -CONFIG_USB_DEBUG_ISOC - Say Y here if you want to get lots of debugging output related to - the USB code. - -USB hub support -CONFIG_USB_HUB - Say Y here if you want to connect several USB devices to a single - USB port. You will need an USB hub to do this. - - If unsure, say Y. +USB Human Interface Device (HID) support +CONFIG_USB_HID + Say Y here if you want to connect a keyboard, mouse, joystick, + graphic tablet, UPS or any other HID based devices to your computer + via USB. - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called hub.o. If you want to compile it as a - module, say M here and read Documentation/modules.txt. +USB HIDBP Keyboard support +CONFIG_USB_KBD + Say Y here if you don't want to use the generic HID driver for your + USB keyboard and prefer to use the keyboard in its limited Boot + Protocol mode. This driver is much smaller than the HID one. -USB mouse support +USB HIDBP Mouse support CONFIG_USB_MOUSE - Say Y here if you want to connect a USB mouse to your computer's USB - port. + Say Y here if you don't want to use the generic HID driver for your + USB mouse and prefer to use the mouse in its limited Boot Protocol + mode. This driver is much smaller than the HID one. + +Keyboard support +CONFIG_INPUT_KEYBDEV + Say Y here if you want your USB HID keyboard to be able to serve as + a system keyboard. + +Mouse support +CONFIG_INPUT_MOUSEDEV + Say Y here if you want your USB HID mouse to be accessible as + misc devices 32+ under /dev/, as an emulated PS/2 mouse. + +Mix all mice into one device +CONFIG_INPUT_MOUSEDEV_MIX + Say Y here if you want input from all your USB HID mice to be mixed + into one misc device. If you say N, you'll have a separate + device for each your USB mouse. - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called mouse.o. If you want to compile it as a - module, say M here and read Documentation/modules.txt. - -USB HP scanner support -CONFIG_USB_HP_SCANNER - Say Y here if you want to connect a USB HP scanner to your - computer's USB port. Please read drivers/usb/README.hp_scanner - for more information. +Joystick support +CONFIG_INPUT_JOYDEV + Say Y here if you want your USB HID joystick or gamepad to be + accessible as /dev/js device. You can't use a normal joystick + if you select this. + +Event interface support +CONFIG_INPUT_EVDEV + Say Y here if you want your USB HID device events be accessible + under /dev/inputX (misc 64+) in a generic way. + This is the future ... + +USB HID debug output +CONFIG_USB_HID_DEBUG + Say Y here if you want to see what the HID driver is doing, + perhaps it's doing something wrong with your device. + +USB HID lots of debug output +CONFIG_USB_HID_DEBUG_LOTS + Say Y here if you don't fear to read all the HID dumps the + HID driver will generate when you switch this on. Really LOTS + of debug output. + +USB scanner support +CONFIG_USB_SCANNER + Say Y here if you want to connect a USB scanner to your + computer's USB port. Please read drivers/usb/README.scanner + and drivers/usb/README.scanner_hp_sane for more information. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module will be called hp_scanner.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -USB keyboard support -CONFIG_USB_KBD - Say Y here if you want to connect a USB keyboard to your computer's - USB port. - - This code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module will be called usb-keyboard.o. If you want to compile it - as a module, say M here and read Documentation/modules.txt. - USB audio parsing support CONFIG_USB_AUDIO - Say Y here if you want to connect audio equipment such as USB + Say Y here if you want to connect USB audio equipment such as speakers to your computer's USB port. This code is also available as a module ( = code which can be @@ -8089,11 +8098,12 @@ CONFIG_USB_ACM The module will be called acm.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -USB Belkin and Peracom serial support +USB serial converter support CONFIG_USB_SERIAL - Say Y here if you want to connect a Belkin, Peracom, or eTek - single port USB to serial converter. - + Say Y here if you want to connect a Connect Tech WhiteHEAT + multi-port USB to serial converter; a Belkin, Peracom, or eTek + single port USB to serial converter; or a Handspring Visor. + This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module will be called usb-serial.o. If you want to compile it @@ -8101,7 +8111,7 @@ CONFIG_USB_SERIAL USB Printer support CONFIG_USB_PRINTER - Say Y here if you want to connect a printer to your computer's USB + Say Y here if you want to connect a USB printer to your computer's USB port. This code is also available as a module ( = code which can be @@ -8119,6 +8129,20 @@ CONFIG_USB_CPIA The module will be called cpia.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. +USB OV511 Camera support +CONFIG_USB_OV511 + Say Y here if you want to connect this type of camera to your + computer's USB port. See drivers/usb/README.ov511 for more + information and for a list of supported cameras. + + NOTE: This code is experimental and you will not get video with it + yet. + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called ov511.o. If you want to compile it as a + module, say M here and read Documentation/modules.txt. + USB Kodak DC-2xx Camera support CONFIG_USB_DC2XX Say Y here if you want to connect this type of still camera to @@ -8133,8 +8157,13 @@ CONFIG_USB_DC2XX USB SCSI Support CONFIG_USB_SCSI - Say Y here if you want to connect SCSI devices to your computer's - USB port. + Say Y here if you want to connect USB mass storage devices to your + computer's USB port. + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called usb-scsi.o. If you want to compile it as a + module, say M here and read Documentation/modules.txt. USB SCSI verbose debug CONFIG_USB_SCSI_DEBUG @@ -8159,7 +8188,7 @@ CONFIG_USB_USS720 Manual mode is not limited to printers, any parallel port device should work. This driver utilizes manual mode. - Note however that some operations are three orders of a magnitude + Note however that some operations are three orders of magnitude slower than on a PCI/ISA Parallel Port, so timing critical applications might not work. @@ -8171,15 +8200,27 @@ CONFIG_USB_USS720 The module will be called uss720.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. -USB /proc filesystem entry support (Preliminary) +USB /proc filesystem support CONFIG_USB_PROC This reports USB drivers and devices in the /proc filesystem. Entries are located in /proc/bus/usb. The entries are described in the file Documentation/proc_usb_info.txt. - Note that you must say Y to "/proc filesystem support" below for - this to work. + Note that you must say Y to global "/proc filesystem support" under + Filesystems for this to work. +DABUSB driver +CONFIG_USB_DABUSB + A Digital Audio Broadcasting (DAB) Receiver for USB and Linux brought + to you by the DAB-Team (http://dab.in.tum.de). + This driver can be taken as an example for URB-based bulk, control, and + isochronous transactions. + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called dabusb.o. If you want to compile it as a + module, say M here and read Documentation/modules.txt. + ACPI support CONFIG_ACPI Advanced Configuration and Power Interface (ACPI) is an interface @@ -8959,10 +9000,9 @@ CONFIG_NCPFS_OS2_NS Lowercase DOS filenames on LONG namespace volume CONFIG_NCPFS_SMALLDOS If you say Y here, every filename on a NetWare server volume using - the OS2/LONG namespace will be converted to lowercase characters. - (For regular NetWare file server volumes with DOS namespace, this is - done automatically, even if you say N here.) Saying N here will give - you these filenames in uppercase. + the OS2/LONG namespace and created under DOS or on a volume using + DOS namespace will be converted to lowercase characters. + Saying N here will give you these filenames in uppercase. This is only a cosmetic option since the OS2/LONG namespace is case insensitive. The only major reason for this option is backward @@ -10303,11 +10343,6 @@ CONFIG_APM 11) exchange RAM chips 12) exchange the motherboard. - This driver is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - If you want to compile it as a module, say M here and read - Documentation/modules.txt. The module will be called apm.o. - Ignore USER SUSPEND CONFIG_APM_IGNORE_USER_SUSPEND This option will ignore USER SUSPEND requests. On machines with a @@ -10352,17 +10387,6 @@ CONFIG_APM_DISPLAY_BLANK backlight at all, or it might print a lot of errors to the console, especially if you are using gpm. -Power off on shutdown -CONFIG_APM_POWER_OFF - Enable the ability to power off the computer after the Linux kernel - is halted. You will need software (e.g., a suitable version of the - halt(8) command ("man 8 halt")) to cause the computer to power down. - Recent versions of the sysvinit package available from - ftp://metalab.unc.edu/pub/Linux/system/daemons/init/ contain support - for this ("halt -p" shuts down Linux and powers off the computer, if - executed from runlevel 0). As with the other APM options, this - option may not work reliably with some APM BIOS implementations. - Ignore multiple suspend/standby events CONFIG_APM_IGNORE_MULTIPLE_SUSPEND This option is necessary on the IBM Thinkpad 560, but should work on @@ -10400,6 +10424,20 @@ CONFIG_APM_ALLOW_INTS many of the newer IBM Thinkpads. If you experience hangs when you suspend, try setting this to Y. Otherwise, say N. +Entry point offset fix (some Acer laptops) +CONFIG_APM_BAD_ENTRY_OFFSET + Some implementations of the APM BIOS provide the driver with a bad + entry point offset. If you set this option to Y, then the upper + sixteen bits of the offset will be set to zero. This is usually + unnecessary but harmless. This is required for the Acer Travelmate + 510DX, Travelmate 510T and Extensa 503T. For others, say N. + +Use real mode APM BIOS call to power off +CONFIG_APM_REAL_MODE_POWER_OFF + Use real mode APM BIOS calls to switch off the computer. This is + a work-around for a number of buggy BIOSes. Switch this option on if + your computer crashes instead of powering off properly. + Watchdog Timer Support CONFIG_WATCHDOG If you say Y here (and to one of the following options) and create a @@ -11299,6 +11337,12 @@ CONFIG_SOUND_NM256 See Documentation/sound/NM256 for further information. +ESS Maestro sound chipsets +CONFIG_SOUND_MAESTRO + Say Y or M if you have a sound system driven by ESS's Maestro line + of PCI sound chips. These include the Maestro 1, Maestro 2, and + Maestro 2E. See Documentation/sound/Maestro for more details. + Are you using a crosscompiler CONFIG_CROSSCOMPILE Say Y here if you are compiling the kernel on a different @@ -12745,6 +12789,25 @@ CONFIG_BLK_CPQ_DA boards supported by this driver, and for further information on the use of this driver. +QuickNet Internet LineJack/PhoneJack support +CONFIG_PHONE_IXJ + Say M if you have a telephony card manufactured by Quicknet + Technologies, Inc. These include the Internet PhoneJACK and + Internet LineJACK Telephony Cards. + + For the ISA versions of these products, you can configure the + cards using the isapnp tools (pnpdump/isapnp) or you can use the + isapnp support. Please read: + + /usr/src/linux/Documentation/telephony/ixj.txt. + + For more information on these cards, see Quicknet's website at: + http://www.quicknet.net/ + + If you do not have any Quicknet telephony cards, you can safely + ignore this option. + + # # ARM options # @@ -13284,6 +13347,58 @@ CONFIG_KHTTPD The kHTTPd is experimental. Be careful when using it on a production machine. Also note that kHTTPd doesn't support virtual servers yet. +I2C support +CONFIG_I2C + I2C (pronounce: I-square-C) is a slow bus protocol developed by + Philips. SMBus, or System Management Bus is a sub-protocol of I2C. + + Both I2C and SMBus are supported here. You will need this for + hardware sensors support, and in the future for Video for Linux + support. + + Beside this option, you will also need to select specific drivers + for your bus adapter(s). + +I2C bit-banging interfaces +CONFIG_I2C_ALGOBIT + This allows you to use a range of I2C adapters called bit-banging + adapters. Why they are called so is rather technical and uninteresting; + but you need to select this if you own one of the adapters listed + under it. + +Philips style parallel port adapter +CONFIG_I2C_PHILIPSPAR + This supports parallel-port I2C adapters made by Philips. Unless you + own such an adapter, you do not need to select this. + +ELV adapter +CONFIG_I2C_ELV + This supports parallel-port I2C adapters called ELV. Unless you + own such an adapter, you do not need to select this. + +Velleman K9000 adapter +CONFIG_I2C_VELLEMAN + This supports the Velleman K9000 parallel-port I2C adapter. Unless + you own such an adapter, you do not need to select this. + +I2C PCF 8584 interfaces +CONFIG_I2C_ALGOPCF + This allows you to use a range of I2C adapters called PCF + adapters. Why they are called so is rather technical and uninteresting; + but you need to select this if you own one of the adapters listed + under it. + +Elektor ISA card +CONFIG_I2C_ELEKTOR + This supports the PCF8584 ISA bus I2C adapter. Unless you own such + an adapter, you do not need to select this. + +I2C device interface +CONFIG_I2C_CHARDEV + Here you find the drivers which allow you to use the i2c-* device + files, usually found in the /dev directory on your system. They + make it possible to have user-space programs use the I2C bus. + # # A couple of things I keep forgetting: # capitalize: AppleTalk, Ethernet, DOS, DMA, FAT, FTP, Internet, @@ -13546,4 +13661,4 @@ CONFIG_KHTTPD # LocalWords: adbmouse DRI DRM dlabs GMX PLCs Applicom fieldbus applicom int # LocalWords: VWSND eg ESSSOLO CFU CFNR scribed eiconctrl eicon hylafax KFPU # LocalWords: EXTRAPREC fpu mainboards KHTTPD kHTTPd khttpd Xcelerator -# LocalWords: LOGIBUSMOUSE +# LocalWords: LOGIBUSMOUSE OV511 ov511 diff --git a/Documentation/devices.tex b/Documentation/devices.tex index 03533ac8e..f3767f5ef 100644 --- a/Documentation/devices.tex +++ b/Documentation/devices.tex @@ -926,10 +926,10 @@ disk (same as SCSI.) \begin{devicelist} \major{29}{}{char }{Universal frame buffer} \minor{0}{/dev/fb0}{First frame buffer} - \minor{32}{/dev/fb1}{Second frame buffer} - \minor{64}{/dev/fb2}{Third frame buffer} + \minor{1}{/dev/fb1}{Second frame buffer} + \minor{2}{/dev/fb2}{Third frame buffer} \minordots - \minor{224}{/dev/fb7}{Eighth frame buffer} + \minor{31}{/dev/fb31}{32nd frame buffer} \end{devicelist} \noindent diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 13a48d06c..c17b77188 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -1,21 +1,20 @@ LINUX ALLOCATED DEVICES Maintained by H. Peter Anvin <hpa@zytor.com> - Last revised: August 10, 1998 + Last revised: December 16, 1999 This list is the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating system. The latest version of this list is included with the Linux kernel -sources in LaTeX and ASCII form. It is also available separately from -ftp://ftp.kernel.org/pub/linux/docs/device-list/. In case of -discrepancy between the text and LaTeX versions, the LaTeX version is -authoritative. +sources. It is also available separately from +http://www.kernel.org/pub/linux/docs/device-list/ or +ftp://ftp.kernel.org/pub/linux/docs/device-list/. The LaTeX version +of this document is no longer maintained. -This document is included by reference into the Linux Filesystem -Standard (FSSTND). The FSSTND is available from -ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/. +This document is included by reference into the Filesystem Hierarchy +Standard (FHS). The FHS is available from http://www.pathname.com/fhs/. Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga platform only. Allocations marked (68k/Atari) apply to Linux/68k on @@ -33,6 +32,7 @@ I do not have any information about these devices beyond what appears on this list. Any such information requests will be deleted without reply. + **** PLEASE READ THIS BEFORE SUBMITTING A DEVICE ENTRY **** To have a major number allocated, or a minor number in situations @@ -53,6 +53,13 @@ as this list*. The reason for this is that it is the only way I have found to ensure I have all the requisite information to publish your device and avoid conflicts. +Finally, sometimes I have to play "namespace police." Please don't be +offended. I often get submissions for /dev names that would be bound +to cause conflicts down the road. I am trying to avoid getting in a +situation where we would have to suffer an incompatible forward +change. + + Your cooperation is appreciated. @@ -98,14 +105,14 @@ Your cooperation is appreciated. demand. block Floppy disks - 0 = /dev/fd0 Controller 1, drive 1 autodetect - 1 = /dev/fd1 Controller 1, drive 2 autodetect - 2 = /dev/fd2 Controller 1, drive 3 autodetect - 3 = /dev/fd3 Controller 1, drive 4 autodetect - 128 = /dev/fd4 Controller 2, drive 1 autodetect - 129 = /dev/fd5 Controller 2, drive 2 autodetect - 130 = /dev/fd6 Controller 2, drive 3 autodetect - 131 = /dev/fd7 Controller 2, drive 4 autodetect + 0 = /dev/fd0 Controller 0, drive 0, autodetect + 1 = /dev/fd1 Controller 0, drive 1, autodetect + 2 = /dev/fd2 Controller 0, drive 2, autodetect + 3 = /dev/fd3 Controller 0, drive 3, autodetect + 128 = /dev/fd4 Controller 1, drive 0, autodetect + 129 = /dev/fd5 Controller 1, drive 1, autodetect + 130 = /dev/fd6 Controller 1, drive 2, autodetect + 131 = /dev/fd7 Controller 1, drive 3, autodetect To specify format, add to the autodetect device number: 0 = /dev/fd? Autodetect format @@ -183,17 +190,11 @@ Your cooperation is appreciated. 0 = /dev/tty0 Current virtual console 1 = /dev/tty1 First virtual console - ... + ... 63 = /dev/tty63 63rd virtual console - 64 = /dev/ttyS0 First serial port - ... - 127 = /dev/ttyS63 64th serial port - 128 = /dev/ptyp0 OBSOLETE - ... - 191 = /dev/ptysf OBSOLETE - 192 = /dev/ttyp0 OBSOLETE - ... - 255 = /dev/ttysf OBSOLETE + 64 = /dev/ttyS0 First UART serial port + ... + 255 = /dev/ttyS191 192nd UART serial port Older versions of the Linux kernel used this major number for BSD PTY devices. As of Linux 2.1.115, this @@ -203,31 +204,31 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex - 64 = /dev/cua0 Callout device corresponding to ttyS0 - ... - 127 = /dev/cua63 Callout device corresponding to ttyS63 + 64 = /dev/cua0 Callout device for ttyS0 + ... + 255 = /dev/cua191 Callout device for ttyS191 (5,1) is /dev/console starting with Linux 2.1.71. See the section on terminal devices for more information on /dev/console. 6 char Parallel printer devices - 0 = /dev/lp0 First parallel printer (0x3bc) - 1 = /dev/lp1 Second parallel printer (0x378) - 2 = /dev/lp2 Third parallel printer (0x278) + 0 = /dev/lp0 Parallel printer on parport0 + 1 = /dev/lp1 Parallel printer on parport1 + ... - Not all computers have the 0x3bc parallel port; hence - the "first" printer may be either /dev/lp0 or - /dev/lp1. + Current Linux kernels no longer have a fixed mapping + between parallel ports and I/O addresses. Instead, + they are redirected through the parport multiplex layer. 7 char Virtual console capture devices 0 = /dev/vcs Current vc text contents 1 = /dev/vcs1 tty1 text contents - ... + ... 63 = /dev/vcs63 tty63 text contents 128 = /dev/vcsa Current vc text/attribute contents 129 = /dev/vcsa1 tty1 text/attribute contents - ... + ... 191 = /dev/vcsa63 tty63 text/attribute contents NOTE: These devices permit both read and write access. @@ -235,7 +236,7 @@ Your cooperation is appreciated. block Loopback devices 0 = /dev/loop0 First loopback device 1 = /dev/loop1 Second loopback device - ... + ... The loopback devices are used to mount filesystems not associated with block devices. The binding to the @@ -245,7 +246,7 @@ Your cooperation is appreciated. 0 = /dev/sda First SCSI disk whole disk 16 = /dev/sdb Second SCSI disk whole disk 32 = /dev/sdc Third SCSI disk whole disk - ... + ... 240 = /dev/sdp Sixteenth SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -255,28 +256,28 @@ Your cooperation is appreciated. 9 char SCSI tape devices 0 = /dev/st0 First SCSI tape, mode 0 1 = /dev/st1 Second SCSI tape, mode 0 - ... + ... 32 = /dev/st0l First SCSI tape, mode 1 33 = /dev/st1l Second SCSI tape, mode 1 - ... + ... 64 = /dev/st0m First SCSI tape, mode 2 65 = /dev/st1m Second SCSI tape, mode 2 - ... + ... 96 = /dev/st0a First SCSI tape, mode 3 97 = /dev/st1a Second SCSI tape, mode 3 ... 128 = /dev/nst0 First SCSI tape, mode 0, no rewind 129 = /dev/nst1 Second SCSI tape, mode 0, no rewind - ... + ... 160 = /dev/nst0l First SCSI tape, mode 1, no rewind 161 = /dev/nst1l Second SCSI tape, mode 1, no rewind - ... + ... 192 = /dev/nst0m First SCSI tape, mode 2, no rewind 193 = /dev/nst1m Second SCSI tape, mode 2, no rewind - ... + ... 224 = /dev/nst0a First SCSI tape, mode 3, no rewind 225 = /dev/nst1a Second SCSI tape, mode 3, no rewind - ... + ... "No rewind" refers to the omission of the default automatic rewind on device close. The MTREW or MTOFFL @@ -286,7 +287,7 @@ Your cooperation is appreciated. block Metadisk (RAID) devices 0 = /dev/md0 First metadisk group 1 = /dev/md1 Second metadisk group - ... + ... The metadisk driver is used to span a filesystem across multiple physical disks. @@ -326,6 +327,32 @@ Your cooperation is appreciated. 151 = /dev/led Front panel LEDs 153 = /dev/mergemem Memory merge device 154 = /dev/pmu Macintosh PowerBook power manager + 155 = /dev/isictl MultiTech ISICom serial control + 156 = /dev/lcd Front panel LCD display + 157 = /dev/ac Applicom Intl Profibus card + 158 = /dev/nwbutton Netwinder external button + 159 = /dev/nwdebug Netwinder debug interface + 160 = /dev/nwflash Netwinder flash memory + 161 = /dev/userdma User-space DMA access + 162 = /dev/smbus System Management Bus + 163 = /dev/lik Logitech Internet Keyboard + 164 = /dev/ipmo Intel Intelligent Platform Management + 165 = /dev/vmmon VMWare virtual machine monitor + 166 = /dev/i2o/ctl I2O configuration manager + 167 = /dev/specialix_sxctl Specialix serial control + 168 = /dev/tcldrv Technology Concepts serial control + 169 = /dev/specialix_rioctl Specialix RIO serial control + 170 = /dev/smapi IBM Thinkpad SMAPI + 171 = /dev/srripc QNX4 API IPC manager + 172 = /dev/usemaclone Semaphore clone device + 173 = /dev/ipmikcs Intelligent Platform Management + 174 = /dev/uctrl SPARCbook 3 microcontroller + 175 = /dev/agpgart AGP Graphics Address Remapping Table + 176 = /dev/gtrsc Gorgy Timing radio clock + 177 = /dev/cbm Serial CBM bus + 178 = /dev/jsflash JavaStation OS flash SIMM + 179 = /dev/xsvc High-speed shared-mem/semaphore service + 240-255 Reserved for local use 11 char Raw keyboard device 0 = /dev/kbd Raw keyboard device @@ -335,7 +362,7 @@ Your cooperation is appreciated. block SCSI CD-ROM devices 0 = /dev/sr0 First SCSI CD-ROM 1 = /dev/sr1 Second SCSI CD-ROM - ... + ... The prefix /dev/scd instead of /dev/sr has been used as well, and might make more sense. @@ -356,13 +383,17 @@ Your cooperation is appreciated. block MSCDEX CD-ROM callback support 0 = /dev/dos_cd0 First MSCDEX CD-ROM 1 = /dev/dos_cd1 Second MSCDEX CD-ROM - ... + ... - 13 char PC speaker + 13 char PC speaker (OBSOLETE) 0 = /dev/pcmixer Emulates /dev/mixer 1 = /dev/pcsp Emulates /dev/dsp (8-bit) 4 = /dev/pcaudio Emulates /dev/audio 5 = /dev/pcsp16 Emulates /dev/dsp (16-bit) + + The current PC speaker driver uses the Open Sound + System interface, and these devices are obsolete. + block 8-bit MFM/RLL/IDE controller 0 = /dev/xda First XT disk whole disk 64 = /dev/xdb Second XT disk whole disk @@ -370,13 +401,14 @@ Your cooperation is appreciated. Partitions are handled in the same way as IDE disks (see major number 3). - 14 char Sound card + 14 char Open Sound System (OSS) 0 = /dev/mixer Mixer control 1 = /dev/sequencer Audio sequencer 2 = /dev/midi00 First MIDI port 3 = /dev/dsp Digital audio 4 = /dev/audio Sun-compatible digital audio 6 = /dev/sndstat Sound card status information + 7 = /dev/audioctl SPARC audio control device 8 = /dev/sequencer2 Sequencer -- alternate device 16 = /dev/mixer1 Second soundcard mixer control 17 = /dev/patmgr0 Sequencer patch manager @@ -413,43 +445,43 @@ Your cooperation is appreciated. 17 char Chase serial card 0 = /dev/ttyH0 First Chase port 1 = /dev/ttyH1 Second Chase port - ... + ... block Optics Storage CD-ROM 0 = /dev/optcd Optics Storage CD-ROM 18 char Chase serial card - alternate devices - 0 = /dev/cuh0 Callout device corresponding to ttyH0 - 1 = /dev/cuh1 Callout device corresponding to ttyH1 - ... + 0 = /dev/cuh0 Callout device for ttyH0 + 1 = /dev/cuh1 Callout device for ttyH1 + ... block Sanyo CD-ROM 0 = /dev/sjcd Sanyo CD-ROM 19 char Cyclades serial card 0 = /dev/ttyC0 First Cyclades port - ... + ... 31 = /dev/ttyC31 32nd Cyclades port block "Double" compressed disk 0 = /dev/double0 First compressed disk - ... + ... 7 = /dev/double7 Eighth compressed disk 128 = /dev/cdouble0 Mirror of first compressed disk - ... + ... 135 = /dev/cdouble7 Mirror of eighth compressed disk See the Double documentation for the meaning of the mirror devices. 20 char Cyclades serial card - alternate devices - 0 = /dev/cub0 Callout device corresponding to ttyC0 - ... - 31 = /dev/cub31 Callout device corresponding to ttyC31 + 0 = /dev/cub0 Callout device for ttyC0 + ... + 31 = /dev/cub31 Callout device for ttyC31 block Hitachi CD-ROM (under development) 0 = /dev/hitcd Hitachi CD-ROM 21 char Generic SCSI access 0 = /dev/sg0 First generic SCSI device 1 = /dev/sg1 Second generic SCSI device - ... + ... Most distributions name these /dev/sga, /dev/sgb...; this sets an unnecessary limit of 26 SCSI devices in @@ -467,7 +499,7 @@ Your cooperation is appreciated. 22 char Digiboard serial card 0 = /dev/ttyD0 First Digiboard port 1 = /dev/ttyD1 Second Digiboard port - ... + ... block Second IDE hard disk/CD-ROM interface 0 = /dev/hdc Master: whole disk (or CD-ROM) 64 = /dev/hdd Slave: whole disk (or CD-ROM) @@ -476,8 +508,8 @@ Your cooperation is appreciated. interface (see major number 3). 23 char Digiboard serial card - alternate devices - 0 = /dev/cud0 Callout device corresponding to ttyD0 - 1 = /dev/cud1 Callout device corresponding to ttyD1 + 0 = /dev/cud0 Callout device for ttyD0 + 1 = /dev/cud1 Callout device for ttyD1 ... block Mitsumi proprietary CD-ROM 0 = /dev/mcd Mitsumi CD-ROM @@ -485,31 +517,31 @@ Your cooperation is appreciated. 24 char Stallion serial card 0 = /dev/ttyE0 Stallion port 0 card 0 1 = /dev/ttyE1 Stallion port 1 card 0 - ... + ... 64 = /dev/ttyE64 Stallion port 0 card 1 65 = /dev/ttyE65 Stallion port 1 card 1 ... 128 = /dev/ttyE128 Stallion port 0 card 2 129 = /dev/ttyE129 Stallion port 1 card 2 - ... + ... 192 = /dev/ttyE192 Stallion port 0 card 3 193 = /dev/ttyE193 Stallion port 1 card 3 - ... + ... block Sony CDU-535 CD-ROM 0 = /dev/cdu535 Sony CDU-535 CD-ROM 25 char Stallion serial card - alternate devices - 0 = /dev/cue0 Callout device corresponding to ttyE0 - 1 = /dev/cue1 Callout device corresponding to ttyE1 - ... - 64 = /dev/cue64 Callout device corresponding to ttyE64 - 65 = /dev/cue65 Callout device corresponding to ttyE65 - ... - 128 = /dev/cue128 Callout device corresponding to ttyE128 - 129 = /dev/cue129 Callout device corresponding to ttyE129 - ... - 192 = /dev/cue192 Callout device corresponding to ttyE192 - 193 = /dev/cue193 Callout device corresponding to ttyE193 + 0 = /dev/cue0 Callout device for ttyE0 + 1 = /dev/cue1 Callout device for ttyE1 + ... + 64 = /dev/cue64 Callout device for ttyE64 + 65 = /dev/cue65 Callout device for ttyE65 + ... + 128 = /dev/cue128 Callout device for ttyE128 + 129 = /dev/cue129 Callout device for ttyE129 + ... + 192 = /dev/cue192 Callout device for ttyE192 + 193 = /dev/cue193 Callout device for ttyE193 ... block First Matsushita (Panasonic/SoundBlaster) CD-ROM 0 = /dev/sbpcd0 Panasonic CD-ROM controller 0 unit 0 @@ -537,7 +569,7 @@ Your cooperation is appreciated. 16 = /dev/zqft0 Unit 0, rewind-on-close, compression 17 = /dev/zqft1 Unit 1, rewind-on-close, compression 18 = /dev/zqft2 Unit 2, rewind-on-close, compression - 19 = /dev/zqt3 Unit 3, rewind-on-close, compression + 19 = /dev/zqtf3 Unit 3, rewind-on-close, compression 20 = /dev/nzqft0 Unit 0, no rewind-on-close, compression 21 = /dev/nzqft1 Unit 1, no rewind-on-close, compression 22 = /dev/nzqft2 Unit 2, no rewind-on-close, compression @@ -546,10 +578,10 @@ Your cooperation is appreciated. 33 = /dev/rawqft1 Unit 1, rewind-on-close, no file marks 34 = /dev/rawqft2 Unit 2, rewind-on-close, no file marks 35 = /dev/rawqft3 Unit 3, rewind-on-close, no file marks - 32 = /dev/nrawqft0 Unit 0, no rewind-on-close, no file marks - 33 = /dev/nrawqft1 Unit 1, no rewind-on-close, no file marks - 34 = /dev/nrawqft2 Unit 2, no rewind-on-close, no file marks - 35 = /dev/nrawqft3 Unit 3, no rewind-on-close, no file marks + 36 = /dev/nrawqft0 Unit 0, no rewind-on-close, no file marks + 37 = /dev/nrawqft1 Unit 1, no rewind-on-close, no file marks + 38 = /dev/nrawqft2 Unit 2, no rewind-on-close, no file marks + 39 = /dev/nrawqft3 Unit 3, no rewind-on-close, no file marks block Third Matsushita (Panasonic/SoundBlaster) CD-ROM 0 = /dev/sbpcd8 Panasonic CD-ROM controller 2 unit 0 1 = /dev/sbpcd9 Panasonic CD-ROM controller 2 unit 1 @@ -564,7 +596,7 @@ Your cooperation is appreciated. char Atari SLM ACSI laser printer (68k/Atari) 0 = /dev/slm0 First SLM laser printer 1 = /dev/slm1 Second SLM laser printer - ... + ... block Fourth Matsushita (Panasonic/SoundBlaster) CD-ROM 0 = /dev/sbpcd12 Panasonic CD-ROM controller 3 unit 0 1 = /dev/sbpcd13 Panasonic CD-ROM controller 3 unit 1 @@ -574,18 +606,19 @@ Your cooperation is appreciated. 0 = /dev/ada First ACSI disk whole disk 16 = /dev/adb Second ACSI disk whole disk 32 = /dev/adc Third ACSI disk whole disk - ... + ... 240 = /dev/adp 16th ACSI disk whole disk Partitions are handled in the same way as for IDE disks (see major number 3) except that the limit on partitions is 15, like SCSI. - 29 char Universal frame buffer + 29 char Universal frame buffers 0 = /dev/fb0 First frame buffer - 32 = /dev/fb1 Second frame buffer - ... - 240 = /dev/fb7 Eighth frame buffer + 1 = /dev/fb1 Second frame buffer + 2 = /dev/fb2 Third frame buffer + ... + 31 = /dev/fb31 32nd frame buffer All additional minor numbers are reserved. @@ -619,13 +652,13 @@ Your cooperation is appreciated. ... 7 = /dev/rom7 Eighth ROM card (rw) 8 = /dev/rrom0 First ROM card (ro) - ... + ... 15 = /dev/rrom7 Eighth ROM card (ro) 16 = /dev/flash0 First flash memory card (rw) - ... + ... 23 = /dev/flash7 Eighth flash memory card (rw) 24 = /dev/rflash0 First flash memory card (ro) - ... + ... 31 = /dev/rflash7 Eighth flash memory card (ro) The read-write (rw) devices support back-caching @@ -636,14 +669,14 @@ Your cooperation is appreciated. 32 char Specialix serial card 0 = /dev/ttyX0 First Specialix port 1 = /dev/ttyX1 Second Specialix port - ... + ... block Philips LMS CM-206 CD-ROM 0 = /dev/cm206cd Philips LMS CM-206 CD-ROM 33 char Specialix serial card - alternate devices - 0 = /dev/cux0 Callout device corresponding to ttyX0 - 1 = /dev/cux1 Callout device corresponding to ttyX1 - ... + 0 = /dev/cux0 Callout device for ttyX0 + 1 = /dev/cux1 Callout device for ttyX1 + ... block Third IDE hard disk/CD-ROM interface 0 = /dev/hde Master: whole disk (or CD-ROM) 64 = /dev/hdf Slave: whole disk (or CD-ROM) @@ -656,7 +689,7 @@ Your cooperation is appreciated. 1 = /dev/scc1 First Z8530, second port 2 = /dev/scc2 Second Z8530, first port 3 = /dev/scc3 Second Z8530, second port - ... + ... In a previous version these devices were named /dev/sc1 for /dev/scc0, /dev/sc2 for /dev/scc1, and so @@ -688,17 +721,25 @@ Your cooperation is appreciated. 36 char Netlink support 0 = /dev/route Routing, device updates, kernel to user 1 = /dev/skip enSKIP security cache control + 3 = /dec/fwmonitor Firewall packet copies + 16 = /dev/tap0 First Ethertap device + ... + 31 = /dev/tap15 16th Ethertap device block MCA ESDI hard disk 0 = /dev/eda First ESDI disk whole disk 64 = /dev/edb Second ESDI disk whole disk - ... + ... Partitions are handled in the same way as IDE disks (see major number 3). 37 char IDE tape 0 = /dev/ht0 First IDE tape + 1 = /dev/ht1 Second IDE tape + ... 128 = /dev/nht0 First IDE tape, no rewind-on-close + 129 = /dev/nht1 Second IDE tape, no rewind-on-close + ... Currently, only one IDE tape drive is supported. @@ -708,7 +749,7 @@ Your cooperation is appreciated. 38 char Myricom PCI Myrinet board 0 = /dev/mlanai0 First Myrinet board 1 = /dev/mlanai1 Second Myrinet board - ... + ... This device is used for status query, board control and "user level packet I/O." This board is also @@ -719,7 +760,7 @@ Your cooperation is appreciated. 39 char ML-16P experimental I/O board 0 = /dev/ml16pa-a0 First card, first analog channel 1 = /dev/ml16pa-a1 First card, second analog channel - ... + ... 15 = /dev/ml16pa-a15 First card, 16th analog channel 16 = /dev/ml16pa-d First card, digital lines 17 = /dev/ml16pa-c0 First card, first counter/timer @@ -727,7 +768,7 @@ Your cooperation is appreciated. 19 = /dev/ml16pa-c2 First card, third counter/timer 32 = /dev/ml16pb-a0 Second card, first analog channel 33 = /dev/ml16pb-a1 Second card, second analog channel - ... + ... 47 = /dev/ml16pb-a15 Second card, 16th analog channel 48 = /dev/ml16pb-d Second card, digital lines 49 = /dev/ml16pb-c0 Second card, first counter/timer @@ -771,12 +812,12 @@ Your cooperation is appreciated. 43 char isdn4linux virtual modem 0 = /dev/ttyI0 First virtual modem - ... + ... 63 = /dev/ttyI63 64th virtual modem block Network block devices 0 = /dev/nb0 First network block device 1 = /dev/nb1 Second network block device - ... + ... Network Block Device is somehow similar to loopback devices: If you read from it, it sends packet accross @@ -786,14 +827,14 @@ Your cooperation is appreciated. the net, implementing block device in userland etc. 44 char isdn4linux virtual modem - alternate devices - 0 = /dev/cui0 Callout device corresponding to ttyI0 - ... - 63 = /dev/cui63 Callout device corresponding to ttyI63 + 0 = /dev/cui0 Callout device for ttyI0 + ... + 63 = /dev/cui63 Callout device for ttyI63 block Flash Translatio Layer (FTL) filesystems 0 = /dev/ftla FTL on first Memory Technology Device 16 = /dev/ftlb FTL on second Memory Technology Device 32 = /dev/ftlc FTL on third Memory Technology Device - ... + ... 240 = /dev/ftlp FTL on 16th Memory Technology Device Partitions are handled in the same way as for IDE @@ -802,14 +843,14 @@ Your cooperation is appreciated. 45 char isdn4linux ISDN BRI driver 0 = /dev/isdn0 First virtual B channel raw data - ... + ... 63 = /dev/isdn63 64th virtual B channel raw data 64 = /dev/isdnctrl0 First channel control/debug - ... + ... 127 = /dev/isdnctrl63 64th channel control/debug 128 = /dev/ippp0 First SyncPPP device - ... + ... 191 = /dev/ippp63 64th SyncPPP device 255 = /dev/isdninfo ISDN monitor interface @@ -826,7 +867,7 @@ Your cooperation is appreciated. 46 char Comtrol Rocketport serial card 0 = /dev/ttyR0 First Rocketport port 1 = /dev/ttyR1 Second Rocketport port - ... + ... block Parallel port ATAPI CD-ROM devices 0 = /dev/pcd0 First parallel port ATAPI CD-ROM 1 = /dev/pcd1 Second parallel port ATAPI CD-ROM @@ -834,9 +875,9 @@ Your cooperation is appreciated. 3 = /dev/pcd3 Fourth parallel port ATAPI CD-ROM 47 char Comtrol Rocketport serial card - alternate devices - 0 = /dev/cur0 Callout device corresponding to ttyR0 - 1 = /dev/cur1 Callout device corresponding to ttyR1 - ... + 0 = /dev/cur0 Callout device for ttyR0 + 1 = /dev/cur1 Callout device for ttyR1 + ... block Parallel port ATAPI disk devices 0 = /dev/pf0 First parallel port ATAPI disk 1 = /dev/pf1 Second parallel port ATAPI disk @@ -849,13 +890,13 @@ Your cooperation is appreciated. 48 char SDL RISCom serial card 0 = /dev/ttyL0 First RISCom port 1 = /dev/ttyL1 Second RISCom port - ... + ... block Reserved for Mylex DAC960 PCI RAID controller 49 char SDL RISCom serial card - alternate devices - 0 = /dev/cul0 Callout device corresponding to ttyL0 - 1 = /dev/cul1 Callout device corresponding to ttyL1 - ... + 0 = /dev/cul0 Callout device for ttyL0 + 1 = /dev/cul1 Callout device for ttyL1 + ... block Reserved for Mylex DAC960 PCI RAID controller 50 char Reserved for GLINT @@ -864,7 +905,7 @@ Your cooperation is appreciated. 51 char Baycom radio modem 0 = /dev/bc0 First Baycom radio modem 1 = /dev/bc1 Second Baycom radio modem - ... + ... block Reserved for Mylex DAC960 PCI RAID controller 52 char Spellcaster DataComm/BRI ISDN card @@ -921,7 +962,7 @@ Your cooperation is appreciated. 57 char Hayes ESP serial card 0 = /dev/ttyP0 First ESP port 1 = /dev/ttyP1 Second ESP port - ... + ... block Sixth IDE hard disk/CD-ROM interface 0 = /dev/hdk Master: whole disk (or CD-ROM) @@ -931,14 +972,25 @@ Your cooperation is appreciated. interface (see major number 3). 58 char Hayes ESP serial card - alternate devices - 0 = /dev/cup0 Callout device corresponding to ttyP0 - 1 = /dev/cup1 Callout device corresponding to ttyP1 - ... + 0 = /dev/cup0 Callout device for ttyP0 + 1 = /dev/cup1 Callout device for ttyP1 + ... block Reserved for logical volume manager 59 char sf firewall package 0 = /dev/firewall Communication with sf kernel module + block Generic PDA filesystem device + 0 = /dev/pda0 First PDA device + 1 = /dev/pda1 Second PDA device + ... + + The pda devices are used to mount filesystems on + remote pda's (basically slow handheld machines with + proprietary OS's and limited memory and storage + running small fs translation drivers) through serial / + IRDA / parallel links. + 60-63 LOCAL/EXPERIMENTAL USE Allocated for local/experimental use. For devices not assigned official numbers, these ranges should be @@ -972,7 +1024,7 @@ Your cooperation is appreciated. 0 = /dev/sdq 16th SCSI disk whole disk 16 = /dev/sdr 17th SCSI disk whole disk 32 = /dev/sds 18th SCSI disk whole disk - ... + ... 240 = /dev/sdaf 32nd SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -982,13 +1034,13 @@ Your cooperation is appreciated. 66 char YARC PowerPC PCI coprocessor card 0 = /dev/yppcpci0 First YARC card 1 = /dev/yppcpci1 Second YARC card - ... + ... block SCSI disk devices (32-47) 0 = /dev/sdag 33th SCSI disk whole disk 16 = /dev/sdah 34th SCSI disk whole disk 32 = /dev/sdai 35th SCSI disk whole disk - ... + ... 240 = /dev/sdav 48nd SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -1004,7 +1056,7 @@ Your cooperation is appreciated. 0 = /dev/sdaw 49th SCSI disk whole disk 16 = /dev/sdax 50th SCSI disk whole disk 32 = /dev/sday 51st SCSI disk whole disk - ... + ... 240 = /dev/sdbl 64th SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -1015,7 +1067,7 @@ Your cooperation is appreciated. 0 = /dev/capi20 Control device 1 = /dev/capi20.00 First CAPI 2.0 application 2 = /dev/capi20.01 Second CAPI 2.0 application - ... + ... 20 = /dev/capi20.19 19th CAPI 2.0 application ISDN CAPI 2.0 driver for use with CAPI 2.0 @@ -1025,7 +1077,7 @@ Your cooperation is appreciated. 0 = /dev/sdbm 64th SCSI disk whole disk 16 = /dev/sdbn 65th SCSI disk whole disk 32 = /dev/sdbo 66th SCSI disk whole disk - ... + ... 240 = /dev/sdcb 80th SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -1039,7 +1091,7 @@ Your cooperation is appreciated. 0 = /dev/sdcc 81st SCSI disk whole disk 16 = /dev/sdcd 82nd SCSI disk whole disk 32 = /dev/sdce 83th SCSI disk whole disk - ... + ... 240 = /dev/sdcr 96th SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -1059,7 +1111,7 @@ Your cooperation is appreciated. 0 = /dev/sdcs 97th SCSI disk whole disk 16 = /dev/sdct 98th SCSI disk whole disk 32 = /dev/sdcu 99th SCSI disk whole disk - ... + ... 240 = /dev/sddh 112nd SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -1069,26 +1121,26 @@ Your cooperation is appreciated. 71 char Computone IntelliPort II serial card 0 = /dev/ttyF0 IntelliPort II board 0, port 0 1 = /dev/ttyF1 IntelliPort II board 0, port 1 - ... + ... 63 = /dev/ttyF63 IntelliPort II board 0, port 63 64 = /dev/ttyF64 IntelliPort II board 1, port 0 65 = /dev/ttyF65 IntelliPort II board 1, port 1 - ... + ... 127 = /dev/ttyF127 IntelliPort II board 1, port 63 128 = /dev/ttyF128 IntelliPort II board 2, port 0 129 = /dev/ttyF129 IntelliPort II board 2, port 1 - ... + ... 191 = /dev/ttyF191 IntelliPort II board 2, port 63 192 = /dev/ttyF192 IntelliPort II board 3, port 0 193 = /dev/ttyF193 IntelliPort II board 3, port 1 - ... + ... 255 = /dev/ttyF255 IntelliPort II board 3, port 63 block SCSI disk devices (112-127) 0 = /dev/sddi 113th SCSI disk whole disk 16 = /dev/sddj 114th SCSI disk whole disk 32 = /dev/sddk 115th SCSI disk whole disk - ... + ... 240 = /dev/sddx 128th SCSI disk whole disk Partitions are handled in the same way as for IDE @@ -1096,22 +1148,22 @@ Your cooperation is appreciated. partitions is 15. 72 char Computone IntelliPort II serial card - alternate devices - 0 = /dev/cuf0 Callout device corresponding to ttyF0 - 1 = /dev/cuf1 Callout device corresponding to ttyF1 - ... - 63 = /dev/cuf63 Callout device corresponding to ttyF63 - 64 = /dev/cuf64 Callout device corresponding to ttyF64 - 65 = /dev/cuf65 Callout device corresponding to ttyF65 - ... - 127 = /dev/cuf127 Callout device corresponding to ttyF127 - 128 = /dev/cuf128 Callout device corresponding to ttyF128 - 129 = /dev/cuf129 Callout device corresponding to ttyF129 - ... - 191 = /dev/cuf191 Callout device corresponding to ttyF191 - 192 = /dev/cuf192 Callout device corresponding to ttyF192 - 193 = /dev/cuf193 Callout device corresponding to ttyF193 - ... - 255 = /dev/cuf255 Callout device corresponding to ttyF255 + 0 = /dev/cuf0 Callout device for ttyF0 + 1 = /dev/cuf1 Callout device for ttyF1 + ... + 63 = /dev/cuf63 Callout device for ttyF63 + 64 = /dev/cuf64 Callout device for ttyF64 + 65 = /dev/cuf65 Callout device for ttyF65 + ... + 127 = /dev/cuf127 Callout device for ttyF127 + 128 = /dev/cuf128 Callout device for ttyF128 + 129 = /dev/cuf129 Callout device for ttyF129 + ... + 191 = /dev/cuf191 Callout device for ttyF191 + 192 = /dev/cuf192 Callout device for ttyF192 + 193 = /dev/cuf193 Callout device for ttyF193 + ... + 255 = /dev/cuf255 Callout device for ttyF255 73 char Computone IntelliPort II serial card - control devices 0 = /dev/ip2ipl0 Loadware device for board 0 @@ -1126,7 +1178,7 @@ Your cooperation is appreciated. 74 char SCI bridge 0 = /dev/SCI/0 SCI device 0 1 = /dev/SCI/1 SCI device 1 - ... + ... Currently for Dolphin Interconnect Solutions' PCI-SCI bridge. @@ -1134,16 +1186,16 @@ Your cooperation is appreciated. 75 char Specialix IO8+ serial card 0 = /dev/ttyW0 First IO8+ port, first card 1 = /dev/ttyW1 Second IO8+ port, first card - ... + ... 8 = /dev/ttyW8 First IO8+ port, second card - ... + ... 76 char Specialix IO8+ serial card - alternate devices - 0 = /dev/cuw0 Callout device corresponding to ttyW0 - 1 = /dev/cuw1 Callout device corresponding to ttyW1 - ... - 8 = /dev/cuw8 Callout device corresponding to ttyW8 - ... + 0 = /dev/cuw0 Callout device for ttyW0 + 1 = /dev/cuw1 Callout device for ttyW1 + ... + 8 = /dev/cuw8 Callout device for ttyW8 + ... 77 char ComScire Quantum Noise Generator 0 = /dev/qng ComScire Quantum Noise Generator @@ -1151,38 +1203,68 @@ Your cooperation is appreciated. 78 char PAM Software's multimodem boards 0 = /dev/ttyM0 First PAM modem 1 = /dev/ttyM1 Second PAM modem - ... + ... 79 char PAM Software's multimodem boards - alternate devices - 0 = /dev/cum0 Callout device corresponding to ttyM0 - 1 = /dev/cum1 Callout device corresponding to ttyM1 - ... + 0 = /dev/cum0 Callout device for ttyM0 + 1 = /dev/cum1 Callout device for ttyM1 + ... 80 char Photometrics AT200 CCD camera 0 = /dev/at200 Photometrics AT200 CCD camera + block I2O hard disk + 0 = /dev/i2o/hda First I2O hard disk, whole disk + 16 = /dev/i2o/hdb Second I2O hard disk, whole disk + ... + 240 = /dev/i2o/hdp 16th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 81 char video4linux 0 = /dev/video0 Video capture/overlay device - ... + ... 63 = /dev/video63 Video capture/overlay device 64 = /dev/radio0 Radio device - ... + ... 127 = /dev/radio63 Radio device 192 = /dev/vtx0 Teletext device - ... + ... 223 = /dev/vtx31 Teletext device 224 = /dev/vbi0 Vertical blank interrupt - ... + ... 255 = /dev/vbi31 Vertical blank interrupt + block I2O hard disk + 0 = /dev/i2o/hdq 17th I2O hard disk, whole disk + 16 = /dev/i2o/hdr 18th I2O hard disk, whole disk + ... + 240 = /dev/i2o/hdaf 32nd I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 82 char WiNRADiO communications receiver card 0 = /dev/winradio0 First WiNRADiO card 1 = /dev/winradio1 Second WiNRADiO card - ... + ... The driver and documentation may be obtained from http://www.proximity.com.au/~brian/winradio/ + block I2O hard disk + 0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk + 16 = /dev/i2o/hdah 34th I2O hard disk, whole disk + ... + 240 = /dev/i2o/hdav 48th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 83 char Teletext/videotext interfaces 0 = /dev/vtx Teletext decoder 16 = /dev/vttuner TV tuner on teletext interface @@ -1190,26 +1272,76 @@ Your cooperation is appreciated. Devices for the driver contained in the VideoteXt package. More information on http://home.pages.de/~videotext/ + block I2O hard disk + 0 = /dev/i2o/hdaw 49th I2O hard disk, whole disk + 16 = /dev/i2o/hdax 50th I2O hard disk, whole disk + ... + 240 = /dev/i2o/hdbl 64th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 84 char Ikon 1011[57] Versatec Greensheet Interface 0 = /dev/ihcp0 First Greensheet port 1 = /dev/ihcp1 Second Greensheet port + block I2O hard disk + 0 = /dev/i2o/hdbm 65th I2O hard disk, whole disk + 16 = /dev/i2o/hdbn 66th I2O hard disk, whole disk + ... + 240 = /dev/i2o/hdcb 80th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 85 char Linux/SGI shared memory input queue 0 = /dev/shmiq Master shared input queue 1 = /dev/qcntl0 First device pushed 2 = /dev/qcntl1 Second device pushed ... + block I2O hard disk + 0 = /dev/i2o/hdcc 81st I2O hard disk, whole disk + 16 = /dev/i2o/hdcd 82nd I2O hard disk, whole disk + ... + 240 = /dev/i2o/hdcr 96th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 86 char SCSI media changer 0 = /dev/sch0 First SCSI media changer 1 = /dev/sch1 Second SCSI media changer ... + block I2O hard disk + 0 = /dev/i2o/hdcs 97th I2O hard disk, whole disk + 16 = /dev/i2o/hdct 98th I2O hard disk, whole disk + ... + 240 = /dev/i2o/hddh 112th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 87 char Sony Control-A1 stereo control bus 0 = /dev/controla0 First device on chain 1 = /dev/controla1 Second device on chain ... + block I2O hard disk + 0 = /dev/i2o/hddi 113rd I2O hard disk, whole disk + 16 = /dev/i2o/hddj 114th I2O hard disk, whole disk + ... + 240 = /dev/i2o/hddx 128th I2O hard disk, whole disk + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 88 char COMX synchronous serial card 0 = /dev/comx0 COMX channel 0 1 = /dev/comx1 COMX channel 1 @@ -1222,6 +1354,7 @@ Your cooperation is appreciated. Partitions are handled the same way as for the first interface (see major number 3). + 89 char I2C bus interface 0 = /dev/i2c0 First I2C adapter 1 = /dev/i2c1 Second I2C adapter @@ -1262,6 +1395,15 @@ Your cooperation is appreciated. 92 char Reserved for ith Kommunikationstechnik MIC ISDN card + block PPDD encrypted disk driver + 0 = /dev/ppdd0 First encrypted disk + 1 = /dev/ppdd1 Second encrypted disk + ... + + Partitions are handled in the same way as for IDE + disks (see major number 3) except that the limit on + partitions is 15. + 93 char IBM Smart Capture Card frame grabber 0 = /dev/iscc0 First Smart Capture Card 1 = /dev/iscc1 Second Smart Capture Card @@ -1270,6 +1412,12 @@ Your cooperation is appreciated. 129 = /dev/isccctl1 Second Smart Capture Card control ... + block NAND Flash Translation Layer filesystem + 0 = /dev/nftla First NFTL layer + 16 = /dev/nftlb Second NFTL layer + ... + 240 = /dev/nftlp 16th NTFL layer + 94 char miroVIDEO DC10/30 capture/playback device 0 = /dev/dcxx0 First capture card 1 = /dev/dcxx1 Second capture card @@ -1281,15 +1429,29 @@ Your cooperation is appreciated. 2 = /dev/ipstate State information log file 3 = /dev/ipauth Authentication control device/log file + block IBM S/390 DASD block storage + 0 = /dev/dasd0 First DASD device, major + 1 = /dev/dasd0a First DASD device, block 1 + 2 = /dev/dasd0b First DASD device, block 2 + 3 = /dev/dasd0c First DASD device, block 3 + 4 = /dev/dasd1 Second DASD device, major + 5 = /dev/dasd1a Second DASD device, block 1 + 6 = /dev/dasd1b Second DASD device, block 2 + 7 = /dev/dasd1c Second DASD device, block 3 + ... + 96 char Parallel port ATAPI tape devices 0 = /dev/pt0 First parallel port ATAPI tape 1 = /dev/pt1 Second parallel port ATAPI tape - 2 = /dev/pt2 Third parallel port ATAPI tape - 3 = /dev/pt3 Fourth parallel port ATAPI tape + ... 128 = /dev/npt0 First p.p. ATAPI tape, no rewind 129 = /dev/npt1 Second p.p. ATAPI tape, no rewind - 130 = /dev/npt2 Third p.p. ATAPI tape, no rewind - 131 = /dev/npt3 Fourth p.p. ATAPI tape, no rewind + ... + + block IBM S/390 VM/ESA minidisk + 0 = /dev/msd0 First VM/ESA minidisk + 1 = /dev/msd1 Second VM/ESA minidisk + ... 97 char Parallel port generic ATAPI interface 0 = /dev/pg0 First parallel port ATAPI device @@ -1364,7 +1526,64 @@ Your cooperation is appreciated. 1 = /dev/srnd1 Second miroMEDIA Surround board ... -111-119 UNALLOCATED +111 char Philips SAA7146-based audio/video card + 0 = /dev/av0 First A/V card + 1 = /dev/av1 Second A/V card + ... + +112 char ISI serial card + 0 = /dev/ttyM0 First ISI port + 1 = /dev/ttyM1 Second ISI port + ... + + There is currently a device-naming conflict between + these and PAM multimodems (major 78). + +113 char ISI serial card - alternate devices + 0 = /dev/cum0 Callout device for ttyM0 + 1 = /dev/cum1 Callout device for ttyM1 + ... + +114 char Picture Elements ISE board + 0 = /dev/ise0 First ISE board + 1 = /dev/ise1 Second ISE board + ... + 128 = /dev/isex0 Control node for first ISE board + 129 = /dev/isex1 Control node for second ISE board + ... + + The ISE board is an embedded computer, optimized for + image processing. The /dev/iseN nodes are the general + I/O access to the board, the /dev/isex0 nodes command + nodes used to control the board. + +115 char Console driver speaker + 0 = /dev/speaker Speaker device file + + Plays music using IBM BASIC style strings. + +116 char Advanced Linux System Driver (ALSA) + +117 char COSA/SRP synchronous serial card + 0 = /dev/cosa0c0 1st board, 1st channel + 1 = /dev/cosa0c1 1st board, 2nd channel + ... + 16 = /dev/cosa1c0 2nd board, 1st channel + 17 = /dev/cosa1c1 2nd board, 2nd channel + ... + +118 char Solidum ??? + 0 = /dev/solnp0 + 1 = /dev/solnp1 + ... + 128 = /dev/solnpctl0 + 129 = /dev/solnpctl1 + ... + +119 char VMware virtual network control + 0 = /dev/vnet0 1st virtual network + 1 = /dev/vnet1 2nd virtual network + ... 120-127 LOCAL/EXPERIMENTAL USE @@ -1377,13 +1596,285 @@ Your cooperation is appreciated. 136-143 char Unix98 PTY slaves 0 = /dev/pts/0 First Unix98 pseudo-TTY 1 = /dev/pts/1 Second Unix98 pesudo-TTY + ... These device nodes are automatically generated with the proper permissions and modes by mounting the devpts filesystem onto /dev/pts with the appropriate - mount options (distribution dependent). + mount options (distribution dependent, however, on + *most* distributions the appropriate options are + "mode=0620,gid=<gid of the "tty" group>".) + +144 char Encapsulated PPP + 0 = /dev/pppox0 First PPP over Ethernet + ... + 63 = /dev/pppox63 64th PPP over Ethernet + + This is primarily used for ADSL. + + The SST 5136-DN DeviceNet interface driver has been + relocated to major 183 due to an unfortunate conflict. + +145 char SAM9407-based soundcard + 0 = /dev/sam0_mixer + 1 = /dev/sam0_sequencer + 2 = /dev/sam0_midi00 + 3 = /dev/sam0_dsp + 4 = /dev/sam0_audio + 6 = /dev/sam0_sndstat + 18 = /dev/sam0_midi01 + 34 = /dev/sam0_midi02 + 50 = /dev/sam0_midi03 + 64 = /dev/sam1_mixer + ... + 128 = /dev/sam2_mixer + ... + 192 = /dev/sam3_mixer + ... + + Device functions match OSS, but offer a number of + addons, which are sam9407 specific. OSS can be + operated simultaneously, taking care of the codec. + +146 char SYSTRAM SCRAMNet mirrored-memory network + 0 = /dev/scramnet0 First SCRAMNet device + 1 = /dev/scramnet1 Second SCRAMNet device + ... + +147 char Aueral Semiconductor Vortex Audio device + 0 = /dev/aureal0 First Aureal Vortex + 1 = /dev/aureal1 Second Aureal Vortex + ... + +148 char Technology Concepts serial card + 0 = /dev/ttyT0 First TCL port + 1 = /dev/ttyT1 Second TCL port + ... + +149 char Technology Concepts serial card - alternate devices + 0 = /dev/cut0 Callout device for ttyT0 + 1 = /dev/cut0 Callout device for ttyT1 + ... + +150 char Real-Time Linux FIFOs + 0 = /dev/rtf0 First RTLinux FIFO + 1 = /dev/rtf1 Second RTLinux FIFO + ... + +151 char DPT I2O SmartRaid V controller + 0 = /dev/dpti0 First DPT I2O adapter + 1 = /dev/dpti1 Second DPT I2O adapter + ... + +154 char Specialix RIO serial card + 0 = /dev/ttySR0 First RIO port + ... + 255 = /dev/ttySR255 256th RIO port + +155 char Specialix RIO serial card - alternate devices + 0 = /dev/cusr0 Callout device for ttySR0 + ... + 255 = /dev/cusr255 Callout device for ttySR255 + +156 char Specialix RIO serial card + 0 = /dev/ttySR256 257th RIO port + ... + 255 = /dev/ttySR511 512th RIO port + +157 char Specialix RIO serial card - alternate devices + 0 = /dev/cusr256 Callout device for ttySR256 + ... + 255 = /dev/cusr511 Callout device for ttySR511 + +158 char Dialogic GammaLink fax driver + 0 = /dev/gfax0 GammaLink channel 0 + 1 = /dev/gfax1 GammaLink channel 1 + ... + +159 char Quicknet Technologies Internet PhoneJack/LineJack + 0 = /dev/ixj0 First device + 1 = /dev/ixj1 Second device + ... + +160 char General Purpose Instrument Bus (GPIB) + 0 = /dev/gpib0 First GPIB bus + 1 = /dev/gpib1 Second GPIB bus + ... + +161 char IrCOMM devices (IrDA serial/parallel emulation) + 0 = /dev/ircomm0 First IrCOMM device + 1 = /dev/ircomm1 Second IrCOMM device + ... + 16 = /dev/irlpt0 First IrLPT device + 17 = /dev/irlpt1 Second IrLPT device + ... + +162 char Raw block device interface + 0 = /dev/raw Raw I/O control device + 1 = /dev/raw1 First raw I/O device + 2 = /dev/raw2 Second raw I/O device + ... + +163 char Radio Tech BIM-XXX-RS232 radio modem + 0 = /dev/bimrt0 First BIM radio modem + 1 = /dev/bimrt1 Second BIM radio modem + ... + +164 char Chase Research AT/PCI-Fast serial card + 0 = /dev/ttyCH0 AT/PCI-Fast board 0, port 0 + ... + 15 = /dev/ttyCH15 AT/PCI-Fast board 0, port 15 + 16 = /dev/ttyCH16 AT/PCI-Fast board 1, port 0 + ... + 31 = /dev/ttyCH31 AT/PCI-Fast board 1, port 15 + 32 = /dev/ttyCH32 AT/PCI-Fast board 2, port 0 + ... + 47 = /dev/ttyCH47 AT/PCI-Fast board 2, port 15 + 48 = /dev/ttyCH48 AT/PCI-Fast board 3, port 0 + ... + 63 = /dev/ttyCH63 AT/PCI-Fast board 3, port 15 + +165 char Chase Research AT/PCI-Fast serial card - alternate devices + 0 = /dev/cuch0 Callout device corresponding to ttyCH0 + ... + 63 = /dev/cuch63 Callout device corresponding to ttyCH63 + +166 char ACM USB modems + 0 = /dev/ttyACM0 First ACM modem + 1 = /dev/ttyACM1 Second ACM modem + ... + +167 char ACM USB modems - alternate devices + 0 = /dev/cuacm0 Callout device for ttyACM0 + 1 = /dev/cuacm1 Callout device for ttyACM1 + ... + +168 char Eracom CSA7000 PCI encryption adaptor + 0 = /dev/ecsa0 First CSA7000 + 1 = /dev/ecsa1 Second CSA7000 + ... + +169 char Eracom CSA8000 PCI encryption adaptor + 0 = /dev/ecsa8-0 First CSA8000 + 1 = /dev/ecsa8-1 Second CSA8000 + ... + +170 char AMI MegaRAC remote access controller + 0 = /dev/megarac0 First MegaRAC card + 1 = /dev/megarac1 Second MegaRAC card + ... + +171 char Reserved for IEEE 1394 (Firewire) + + +172 char Moxa Intellio serial card + 0 = /dev/ttyMX0 First Moxa port + 1 = /dev/ttyMX1 Second Moxa port + ... + 127 = /dev/ttyMX127 128th Moxa port + 128 = /dev/moxactl Moxa control port + +173 char Moxa Intellio serial card - alternate devices + 0 = /dev/cumx0 Callout device for ttyMX0 + 1 = /dev/cumx1 Callout device for ttyMX1 + ... + 127 = /dev/cumx127 Callout device for ttyMX127 + +174 char SmartIO serial card + 0 = /dev/ttySI0 First SmartIO port + 1 = /dev/ttySI1 Second SmartIO port + ... + +175 char SmartIO serial card - alternate devices + 0 = /dev/cusi0 Callout device for ttySI0 + 1 = /dev/cusi1 Callout device for ttySI1 + ... + +176 char nCipher nFast PCI crypto accelerator + 0 = /dev/nfastpci0 First nFast PCI device + 1 = /dev/nfastpci1 First nFast PCI device + ... + +177 char TI PCILynx memory spaces + 0 = /dev/pcilynx/aux0 AUX space of first PCILynx card + ... + 15 = /dev/pcilynx/aux15 AUX space of 16th PCILynx card + 16 = /dev/pcilynx/rom0 ROM space of first PCILynx card + ... + 31 = /dev/pcilynx/rom15 ROM space of 16th PCILynx card + 32 = /dev/pcilynx/ram0 RAM space of first PCILynx card + ... + 47 = /dev/pcilynx/ram15 RAM space of 16th PCILynx card + +178 char Giganet cLAN1xxx virtual interface adapter + 0 = /dev/clanvi0 First cLAN adapter + 1 = /dev/clanvi1 Second cLAN adapter + ... + +179 char CCube DVXChip-based PCI products + 0 = /dev/dvxirq0 First DVX device + 1 = /dev/dvxirq1 Second DVX device + ... + +180 char USB devices + 0 = /dev/usb/lp0 First USB printer + ... + 15 = /dev/usb/lp15 16th USB printer + 16 = /dev/usb/mouse0 First USB mouse + ... + 31 = /dev/usb/mouse15 16th USB mouse + 32 = /dev/usb/ez0 First USB firmware loader + ... + 47 = /dev/usb/ez15 16th USB firmware loader + 48 = /dev/usb/scanner0 First USB scanner + ... + 63 = /dev/usb/scanner15 16th USB scanner + +181 char Conrad Electronic parallel port radio clocks + 0 = /dev/pcfclock0 First Conrad radio clock + 1 = /dev/pcfclock1 Second Conrad radio clock + ... + +182 char Picture Elements THR2 binarizer + 0 = /dev/pethr0 First THR2 board + 1 = /dev/pethr1 Second THR2 board + ... + +183 char SST 5136-DN DeviceNet interface + 0 = /dev/ss5136dn0 First DeviceNet interface + 1 = /dev/ss5136dn1 Second DeviceNet interface + ... + + This device used to be assigned to major number 144. + It had to be moved due to an unfortunate conflict. + +184 char Picture Elements' video simulator/sender + 0 = /dev/pevss0 First sender board + 1 = /dev/pevss1 Second sender board + ... + +185 char Reserved for InterMezzo high availability file system + +186 char Object-based storage control device + 0 = /dev/obd0 First obd control device + 1 = /dev/obd1 Second obd control device + ... + + See ftp://ftp.lustre.org/pub/obd for code and information. + +187 char UNALLOCATED + +188 char USB serial converters + 0 = /dev/ttyUSB0 First USB serial converter + 1 = /dev/ttyUSB1 Second USB serial converter + ... + +189 char USB serial converters - alternate devices + 0 = /dev/cuusb0 Callout device corresponding to ttyUSB0 + 1 = /dev/cuusb1 Callout device corresponding to ttyUSB1 + ... -144-239 UNALLOCATED +190-239 UNALLOCATED 240-254 LOCAL/EXPERIMENTAL USE @@ -1412,8 +1903,9 @@ These links should exist on all systems: /dev/stderr fd/2 symbolic stderr file descriptor /dev/nfsd socksys symbolic Required by iBCS-2 /dev/X0R null symbolic Required by iBCS-2 +/dev/i2o* /dev/i2o/* symbolic Backward compatibility -Note: the last device is <letter X>-<digit 0>-<letter R>. +Note: /dev/X0R is <letter X>-<digit 0>-<letter R>. Recommended links diff --git a/Documentation/fb/clgenfb.txt b/Documentation/fb/clgenfb.txt index 4e3de5e83..a9c71ccfe 100644 --- a/Documentation/fb/clgenfb.txt +++ b/Documentation/fb/clgenfb.txt @@ -1,6 +1,6 @@ Framebuffer driver for Cirrus Logic chipsets - Copyright 1999 Jeff Garzik <jgarzik@pobox.com> + Copyright 1999 Jeff Garzik <jgarzik@mandrakesoft.com> diff --git a/Documentation/fb/framebuffer.txt b/Documentation/fb/framebuffer.txt index 925cc43f2..c36c76f03 100644 --- a/Documentation/fb/framebuffer.txt +++ b/Documentation/fb/framebuffer.txt @@ -2,7 +2,7 @@ ----------------------- Maintained by Geert Uytterhoeven <geert@linux-m68k.org> -Last revised: October 7, 1999 +Last revised: January 2, 2000 0. Introduction @@ -294,7 +294,11 @@ under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt". ------------- For more specific information about the frame buffer device and its -applications, please refer to the following documentation: +applications, please refer to the Linux-fbdev website: + + http://www.linux-fbdev.org/ + +and to the following documentation: - The manual pages for fbset: fbset(8), fb.modes(5) - The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5) diff --git a/Documentation/filesystems/cramfs.txt b/Documentation/filesystems/cramfs.txt new file mode 100644 index 000000000..a408b8828 --- /dev/null +++ b/Documentation/filesystems/cramfs.txt @@ -0,0 +1,13 @@ + + Cramfs - cram a filesystem onto a small ROM + +cramfs is designed to be simple and small, and to compress things well. + +It uses the zlib routines to compress a file one page at a time, and +allows random page access. The meta-data is not compressed, but is +expressed in a very terse representation to make it use much less +diskspace than traditional filesystems. + +You can't write to a cramfs filesystem (making it compressible and +compact also makes it _very_ hard to update on-the-fly), so you have to +create the disk image with the "mkcramfs" utility in scripts/cramfs. diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index 8ee0ea9cc..dc1910933 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -29,8 +29,8 @@ uni_xlate=<bool> -- Translate unhandled Unicode characters to special a '?' is used when no translation is possible. The escape character is ':' because it is otherwise illegal on the vfat filesystem. The escape sequence - that gets used, where u is the unicode character, is: - ':', (u & 0x3f), ((u>>6) & 0x3f), (u>>12), + that gets used is ':' and the four digits of hexadecimal + unicode. posix=<bool> -- Allow names of same letters, different case such as 'LongFileName' and 'longfilename' to coexist. This has some problems currently because 8.3 conflicts are not handled @@ -52,11 +52,6 @@ check=s|r|n -- Case sensitivity checking setting. TODO ---------------------------------------------------------------------- -* When only shortnames exist, translate them from the codepage character - set to the iocharset. Currently, translations only occur when longnames - exist. To translate, first convert from codepage to Unicode and then - to the output character set. - * Need to get rid of the raw scanning stuff. Instead, always use a get next directory entry approach. The only thing left that uses raw scanning is the directory renaming code. diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface new file mode 100644 index 000000000..0d917a8be --- /dev/null +++ b/Documentation/i2c/dev-interface @@ -0,0 +1,124 @@ +Usually, i2c devices are controlled by a kernel driver. But it is also +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. +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, ..., +i2c-10, ...). All 256 minor device numbers are reserved for i2c. + + +C example +========= + +So let's say you want to access an i2c adapter from a C program. The +first thing to do is `#include <linux/i2c.h>" and "#include <linux/i2c-dev.h>. +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 +somewhat dynamically, so you can not even assume /dev/i2c-0 is the +first adapter. + +Next thing, open the device file, as follows: + int file; + int adapter_nr = 2; /* probably dynamically determined */ + char filename[20]; + + sprintf(filename,"/dev/i2c-%d",adapter_nr); + if ((file = open(filename,O_RDWR)) < 0) { + /* ERROR HANDLING; you can check errno to see what went wrong */ + exit(1); + } + +When you have opened the device, you must specify with what device +address you want to communicate: + int addr = 0x40; /* The I2C address */ + if (ioctl(file,I2C_SLAVE,addr) < 0) { + /* ERROR HANDLING; you can check errno to see what went wrong */ + exit(1); + } + +Well, you are all set up now. You can now use SMBus commands or plain +I2C to communicate with your device. SMBus commands are preferred if +the device supports them. Both are illustrated below. + __u8 register = 0x10; /* Device register to access */ + __s32 res; + char buf[10]; + /* Using SMBus commands */ + res = i2c_smbus_read_word_data(file,register); + if (res < 0) { + /* ERROR HANDLING: i2c transaction failed */ + } else { + /* res contains the read word */ + } + /* Using I2C Write, equivalent of + i2c_smbus_write_word_data(file,register,0x6543) */ + buf[0] = register; + buf[1] = 0x43; + buf[2] = 0x65; + if ( write(file,buf,3) != 3) { + /* ERROR HANDLING: i2c transaction failed */ + } + /* Using I2C Read, equivalent of i2c_smbus_read_byte(file) */ + if (read(file,buf,1) != 1) { + /* ERROR HANDLING: i2c transaction failed */ + } else { + /* buf[0] contains the read byte */ + } + + +Full interface description +========================== + +The following IOCTLs are defined and fully supported +(see also i2c-dev.h and i2c.h): + +ioctl(file,I2C_SLAVE,long addr) + Change slave address. The address is passed in the 7 lower bits of the + argument (except for 10 bit addresses, passed in the 10 lower bits in this + case). + +ioctl(file,I2C_TENBIT,long select) + Selects ten bit addresses if select not equals 0, selects normal 7 bit + addresses if select equals 0. + +ioctl(file,I2C_FUNCS,unsigned long *funcs) + Gets the adapter functionality and puts it in *funcs. + +Other values are NOT supported at this moment, except for I2C_SMBUS, +which you should never directly call; instead, use the access functions +below. + +You can do plain i2c transactions by using read(2) and write(2) calls. +Combined read/write transactions are not yet supported (they will in +the future, through an ioctl). You do not need to pass the address +byte; instead, set it through ioctl I2C_SLAVE before you try to +access the device. + +You can do SMBus level transactions (see documentation file smbus-protocol +for details) through the following functions: + __s32 i2c_smbus_write_quick(int file, __u8 value); + __s32 i2c_smbus_read_byte(int file); + __s32 i2c_smbus_write_byte(int file, __u8 value); + __s32 i2c_smbus_read_byte_data(int file, __u8 command); + __s32 i2c_smbus_write_byte_data(int file, __u8 command, __u8 value); + __s32 i2c_smbus_read_word_data(int file, __u8 command); + __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value); + __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value); + __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values); + __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length, + __u8 *values); +All these tranactions return -1 on failure; you can read errno to see +what happened. 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 need not be longer +than 32 bytes. + +The above functions are all macros, that resolve to calls to the +i2c_smbus_access function, that on its turn calls a specific ioctl +with the data in a specific format. Read the source code if you +want to know what happens behind the screens. diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol new file mode 100644 index 000000000..16ba77b7a --- /dev/null +++ b/Documentation/i2c/i2c-protocol @@ -0,0 +1,46 @@ +This document describes the i2c protocol. Or will, when it is finished :-) + +Key to symbols +============== + +S (1 bit) : Start bit +P (1 bit) : Stop bit +Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0. +A, NA (1 bit) : Accept and reverse accept bit. +Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to + get a 10 bit I2C address. +Comm (8 bits): Command byte, a data byte which often selects a register on + the device. +Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh + for 16 bit data. +Count (8 bits): A data byte containing the length of a block operation. + +[..]: Data sent by I2C device, as opposed to data sent by the host adapter. + + +Simple send tranaction +====================== + +This corresponds to i2c_master_send. + + S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P + + +Simple receive transaction +=========================== + +This corresponds to i2c_master_recv + + S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P + + +Combined tranactions +==================== + +This corresponds to i2c_transfer + +They are just like the above transactions, but instead of a stop bit P +a start bit S is sent and the transaction continues. An example of +a byte read, followed by a byte write: + + S Addr Rd [A] [Data] NA S Addr Wr [A] Data [A] P diff --git a/Documentation/i2c/proc-interface b/Documentation/i2c/proc-interface new file mode 100644 index 000000000..de777c418 --- /dev/null +++ b/Documentation/i2c/proc-interface @@ -0,0 +1,53 @@ +i2c-core is the core i2c module (surprise!) which offers general routines on +which other modules build. You will find that all i2c-related modules depend +on this module, so it will (need to) be loaded whenever another i2c-related +module is loaded. Seen from the outside, the most interesting is the /proc +interface. Note that there is no corresponding sysctl interface! + +/proc/bus/i2c +============= + +Whenever i2c-core is loaded, you will find a file /proc/bus/i2c, which lists +all currently registered I2C adapters. Each line contains exactly one +I2C adapter. Each line has the following format: "i2c-%d\t%9s\t%-32s't%-32s\n", +which works out to four columns separated by tabs. Note that the file +will be empty, if no adapters are registered at all. + +Adapters are numbered from 0 upwards. The first column contains the number +of the adapter, for example "i2c-4" for adapter 4. The name listed is also +the name of the /proc file which lists all devices attached to it, and +of the /dev file which corresponds to this adapter. + +The second column documents what kind of adapter this is. Some adapters +understand the full I2C protocol, others only a subset called SMBus, +and yet others are some kind of pseudo-adapters that do not understand +i2c at all. Possible values in here are "i2c", "smbus", "i2c/smbus" +and "dummy". Because the SMBus protocol can be fully emulated by i2c +adapters, if you see "i2c" here, SMBus is supported too. There may +be some future adapters which support both specific SMBus commands and +general I2C, and they will display "i2c/smbus". + +The third and fourth column are respectively the algorithm and adapter +name of this adapter. Each adapter is associated with an algorithm, +and several adapters can share the same algorithm. The combination of +algorithm name and adapter name should be unique for an adapter, but +you can't really count on that yet. + + +/proc/bus/i2c-* +=============== + +Each registered adapter gets its own file in /proc/bus/, which lists +the devices registered to the adapter. Each line in such a file contains +one registered device. Each line has the following format: +"%02x\t%-32s\t%-32s\n", which works out to three columns separated by +tabs. Note that this file can be empty, if no devices are found on +the adapter. + +The first column contains the (hexadecimal) address of the client. As +only 7-bit addresses are supported at this moment, two digits are +enough. + +The second and third column are respectively the client name and the +driver name of this client. Each client is associated with a driver, +and several clients can share the same driver. diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol new file mode 100644 index 000000000..9f024396d --- /dev/null +++ b/Documentation/i2c/smbus-protocol @@ -0,0 +1,127 @@ +Some adapters understand only the SMBus (System Management Bus) protocol, +which is a subset from the I2C protocol. Fortunately, many devices use +only the same subset, which makes it possible to put them on an SMBus. +If you write a driver for some I2C device, please try to use the SMBus +commands if at all possible (if the device uses only that subset of the +I2C protocol). This makes it possible to use the device driver on both +SMBus adapters and I2C adapters (the SMBus command set is automatically +translated to I2C on I2C adapters, but plain I2C commands can not be +handled at all on a pure SMBus adapter). + +Below is a list of SMBus commands. + +Key to symbols +============== + +S (1 bit) : Start bit +P (1 bit) : Stop bit +Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0. +A, NA (1 bit) : Accept and reverse accept bit. +Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to + get a 10 bit I2C address. +Comm (8 bits): Command byte, a data byte which often selects a register on + the device. +Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh + for 16 bit data. +Count (8 bits): A data byte containing the length of a block operation. + +[..]: Data sent by I2C device, as opposed to data sent by the host adapter. + + +SMBus Write Quick +================= + +This sends a single byte to the device, at the place of the Rd/Wr bit. +There is no equivalent Read Quick command. + +A Addr Rd/Wr [A] P + + +SMBus Read Byte +=============== + +This reads a single byte from a device, without specifying a device +register. Some devices are so simple that this interface is enough; for +others, it is a shorthand if you want to read the same register as in +the previous SMBus command. + +S Addr Rd [A] [Data] NA P + + +SMBus Write Byte +================ + +This is the reverse of Read Byte: it sends a single byte to a device. +See Read Byte for more information. + +S Addr Wr [A] Data NA P + + +SMBus Read Byte Data +==================== + +This reads a single byte from a device, from a designated register. +The register is specified through the Comm byte. + +S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P + + +SMBus Read Word Data +==================== + +This command is very like Read Byte Data; again, data is read from a +device, from a designated register that is specified through the Comm +byte. But this time, the data is a complete word (16 bits). + +S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P + + +SMBus Write Byte Data +===================== + +This writes a single byte to a device, to a designated register. The +register is specified through the Comm byte. This is the opposite of +the Read Byte Data command. + +S Addr Wr [A] Comm [A] Data [A] P + + +SMBus Write Word Data +===================== + +This is the opposite operation of the Read Word Data command. 16 bits +of data is read from a device, from a designated register that is +specified through the Comm byte. + +S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P + + +SMBus Process Call +================== + +This command selects a device register (through the Comm byte), sends +16 bits of data to it, and reads 16 bits of data in return. + +S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] + S Addr Rd [A] [DataLow] A [DataHigh] NA P + + +SMBus Block Read +================ + +This command reads a block of upto 32 bytes from a device, from a +designated register that is specified through the Comm byte. The amount +of data is specified by the device in the Count byte. + +S Addr Wr [A] Comm [A] + S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P + + +SMBus Block Write +================= + +The opposite of the Block Read command, this writes upto 32 bytes to +a device, to a designated register that is specified through the +Comm byte. The amount of data is specified in the Count byte. + +S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P diff --git a/Documentation/i2c/summary b/Documentation/i2c/summary new file mode 100644 index 000000000..a6db1b5e5 --- /dev/null +++ b/Documentation/i2c/summary @@ -0,0 +1,63 @@ +This is an explanation of what i2c is, and what is supported. + +I2C and SMBus +============= + +I2C (pronounce: I square C) is a protocol developed by Philips. It is a +slow two-wire protocol (10-100 kHz), but it suffices for many types of +devices. + +SMBus (System Management Bus) is a subset of the I2C protocol. Many +modern mainboards have a System Management Bus. There are a lot of +devices which can be connected to a SMBus; the most notable are modern +memory chips with EEPROM memories and chips for hardware monitoring. + +Because the SMBus is just a special case of the generalized I2C bus, we +can simulate the SMBus protocol on plain I2C busses. The reverse is +regretfully impossible. + + +Terminology +=========== + +When we talk about I2C, we use the following terms: + Bus -> Algorithm + Adapter + Device -> Driver + Client +An Algorithm driver contains general code that can be used for a whole class +of I2C adapters. Each specific adapter driver depends on one algorithm +driver. +A Driver driver (yes, this sounds ridiculous, sorry) contains the general +code to access some type of device. Each detected device gets its own +data in the Client structure. Usually, Driver and Client are more closely +integrated than Algorithm and Adapter. + +For a given configuration, you will need a driver for your I2C bus (usually +a separate Adapter and Algorithm driver), and drivers for your I2C devices +(usually one driver for each device). + + +Included Drivers +================ + +Base modules +------------ + +i2c-core: The basic I2C code, including the /proc interface +i2c-dev: The /dev interface + +Algorithm drivers +----------------- + +i2c-algo-bit: A bit-banging algorithm +i2c-algo-pcf: A PCF 8584 style algorithm + +Adapter drivers +--------------- + +i2c-elektor: Elektor ISA card (uses i2c-algo-pcf) +i2c-elv: ELV parallel port adapter (uses i2c-algo-bit) +i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit) +i2c-velleman: Velleman K9000 parallel port adapter (uses i2c-algo-bit) + diff --git a/Documentation/i2c/ten-bit-addresses b/Documentation/i2c/ten-bit-addresses new file mode 100644 index 000000000..200074f81 --- /dev/null +++ b/Documentation/i2c/ten-bit-addresses @@ -0,0 +1,22 @@ +The I2C protocol knows about two kinds of device addresses: normal 7 bit +addresses, and an extended set of 10 bit addresses. The sets of addresses +do not intersect: the 7 bit address 0x10 is not the same as the 10 bit +address 0x10 (though a single device could respond to both of them). You +select a 10 bit address by adding an extra byte after the address +byte: + S Addr7 Rd/Wr .... +becomes + S 11110 Addr10 Rd/Wr +S is the start bit, Rd/Wr the read/write bit, and if you count the number +of bits, you will see the there are 8 after the S bit for 7 bit addresses, +and 16 after the S bit for 10 bit addresses. + +WARNING! The current 10 bit address support is EXPERIMENTAL. There are +several places in the code that will cause SEVERE PROBLEMS with 10 bit +addresses, even though there is some basic handling and hooks. Also, +almost no supported adapter handles the 10 bit addresses correctly. + +As soon as a real 10 bit address device is spotted 'in the wild', we +can and will add proper support. Right now, 10 bit address devices +are defined by the I2C protocol, but we have never seen a single device +which supports them. diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients new file mode 100644 index 000000000..cbacdf8a7 --- /dev/null +++ b/Documentation/i2c/writing-clients @@ -0,0 +1,857 @@ +This is a small guide for those who want to write kernel drivers for I2C +or SMBus devices. + +To set up a driver, you need to do several things. Some are optional, and +some things can be done slightly or completely different. Use this as a +guide, not as a rule book! + + +General remarks +=============== + +Try to keep the kernel namespace as clean as possible. The best way to +do this is to use a unique prefix for all global symbols. This is +especially important for exported symbols, but it is a good idea to do +it for non-exported symbols too. We will use the prefix `foo_' in this +tutorial, and `FOO_' for preprocessor variables. + + +The driver structure +==================== + +Usually, you will implement a single driver structure, and instantiate +all clients from it. Remember, a driver structure contains general access +routines, a client structure specific information like the actual I2C +address. + + struct i2c_driver foo_driver + { + /* name */ "Foo version 2.3 and later driver", + /* id */ I2C_DRIVERID_FOO, + /* flags */ I2C_DF_NOTIFY, + /* attach_adapter */ &foo_attach_adapter, + /* detach_client */ &foo_detach_client, + /* command */ &foo_command, /* May be NULL */ + /* inc_use */ &foo_inc_use, /* May be NULL */ + /* dec_use */ &foo_dev_use /* May be NULL */ + } + +The name can be choosen freely, and may be upto 40 characters long. Please +use something descriptive here. + +The id should be a unique ID. The range 0xf000 to 0xffff is reserved for +local use, and you can use one of those until you start distributing the +driver. Before you do that, contact the i2c authors to get your own ID(s). + +Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This +means that your driver will be notified when new adapters are found. +This is almost always what you want. + +All other fields are for call-back functions which will be explained +below. + + +Module usage count +================== + +If your driver can also be compiled as a module, there are moments at +which the module can not be removed from memory. For example, when you +are doing a lengthy transaction, or when you create a /proc directory, +and some process has entered that directory (this last case is the +main reason why these call-backs were introduced). + +To increase or decrease the module usage count, you can use the +MOD_{INC,DEC}_USE_COUNT macros. They must be called from the module +which needs to get its usage count changed; that is why each driver +module has to implement its own callback. + + void foo_inc_use (struct i2c_client *client) + { + #ifdef MODULE + MOD_INC_USE_COUNT; + #endif + } + + void foo_dec_use (struct i2c_client *client) + { + #ifdef MODULE + MOD_DEC_USE_COUNT; + #endif + } + +Do not call these call-back functions directly; instead, use one of the +following functions defined in i2c.h: + void i2c_inc_use_client(struct i2c_client *); + void i2c_dec_use_client(struct i2c_client *); + +You should *not* increase the module count just because a device is +detected and a client created. This would make it impossible to remove +an adapter driver! + + +Extra client data +================= + +The client structure has a special `data' field that can point to any +structure at all. You can use this to keep client-specific data. You +do not always need this, but especially for `sensors' drivers, it can +be very useful. + +An example structure is below. + + struct foo_data { + struct semaphore lock; /* For ISA access in `sensors' drivers. */ + int sysctl_id; /* To keep the /proc directory entry for + `sensors' drivers. */ + enum chips type; /* To keep the chips type for `sensors' drivers. */ + + /* Because the i2c bus is slow, it is often useful to cache the read + information of a chip for some time (for example, 1 or 2 seconds). + It depends of course on the device whether this is really worthwhile + or even sensible. */ + struct semaphore update_lock; /* When we are reading lots of information, + another process should not update the + below information */ + char valid; /* != 0 if the following fields are valid. */ + unsigned long last_updated; /* In jiffies */ + /* Add the read information here too */ + }; + + +Accessing the client +==================== + +Let's say we have a valid client structure. At some time, we will need +to gather information from the client, or write new information to the +client. How we will export this information to user-space is less +important at this moment (perhaps we do not need to do this at all for +some obscure clients). But we need generic reading and writing routines. + +I have found it useful to define foo_read and foo_write function for this. +For some cases, it will be easier to call the i2c functions directly, +but many chips have some kind of register-value idea that can easily +be encapsulated. Also, some chips have both ISA and I2C interfaces, and +it useful to abstract from this (only for `sensors' drivers). + +The below functions are simple examples, and should not be copied +literally. + + int foo_read_value(struct i2c_client *client, u8 reg) + { + if (reg < 0x10) /* byte-sized register */ + return i2c_smbus_read_byte_data(client,reg); + else /* word-sized register */ + return i2c_smbus_read_word_data(client,reg); + } + + int foo_write_value(struct i2c_client *client, u8 reg, u16 value) + { + if (reg == 0x10) /* Impossible to write - driver error! */ { + return -1; + else if (reg < 0x10) /* byte-sized register */ + return i2c_smbus_write_byte_data(client,reg,value); + else /* word-sized register */ + return i2c_smbus_write_word_data(client,reg,value); + } + +For sensors code, you may have to cope with ISA registers too. Something +like the below often works. Note the locking! + + int foo_read_value(struct i2c_client *client, u8 reg) + { + int res; + if (i2c_is_isa_client(client)) { + down(&(((struct foo_data *) (client->data)) -> lock)); + outb_p(reg,client->addr + FOO_ADDR_REG_OFFSET); + res = inb_p(client->addr + FOO_DATA_REG_OFFSET); + up(&(((struct foo_data *) (client->data)) -> lock)); + return res; + } else + return i2c_smbus_read_byte_data(client,reg); + } + +Writing is done the same way. + + +Probing and attaching +===================== + +Most i2c devices can be present on several i2c addresses; for some this +is determined in hardware (by soldering some chip pins to Vcc or Ground), +for others this can be changed in software (by writing to specific client +registers). Some devices are usually on a specific address, but not always; +and some are even more tricky. So you will probably need to scan several +i2c addresses for your clients, and do some sort of detection to see +whether it is actually a device supported by your driver. + +To give the user a maximum of possibilities, some default module parameters +are defined to help determine what addresses are scanned. Several macros +are defined in i2c.h to help you support them, as well as a generic +detection algorithm. + +You do not have to use this parameter interface; but don't try to use +function i2c_probe() (or sensors_detect()) if you don't. + +NOTE: If you want to write a `sensors' driver, the interface is slightly + different! See below. + + + +Probing classes (i2c) +--------------------- + +All parameters are given as lists of unsigned 16-bit integers. Lists are +terminated by I2C_CLIENT_END. +The following lists are used internally: + + normal_i2c: filled in by the module writer. + A list of I2C addresses which should normally be examined. + normal_i2c_range: filled in by the module writer. + A list of pairs of I2C addresses, each pair being an inclusive range of + addresses which should normally be examined. + probe: insmod parameter. + A list of pairs. The first value is a bus number (-1 for any I2C bus), + the second is the address. These addresses are also probed, as if they + were in the 'normal' list. + probe_range: insmod parameter. + A list of triples. The first value is a bus number (-1 for any I2C bus), + the second and third are addresses. These form an inclusive range of + addresses that are also probed, as if they were in the 'normal' list. + ignore: insmod parameter. + A list of pairs. The first value is a bus number (-1 for any I2C bus), + the second is the I2C address. These addresses are never probed. + This parameter overrules 'normal' and 'probe', but not the 'force' lists. + ignore_range: insmod parameter. + A list of triples. The first value is a bus number (-1 for any I2C bus), + the second and third are addresses. These form an inclusive range of + I2C addresses that are never probed. + This parameter overrules 'normal' and 'probe', but not the 'force' lists. + force: insmod parameter. + A list of pairs. The first value is a bus number (-1 for any I2C bus), + the second is the I2C address. A device is blindly assumed to be on + the given address, no probing is done. + +Fortunately, as a module writer, you just have to define the `normal' +and/or `normal_range' parameters. The complete declaration could look +like this: + + /* Scan 0x20 to 0x2f, 0x37, and 0x40 to 0x4f */ + static unsigned short normal_i2c[] = { 0x37,I2C_CLIENT_END }; + static unsigned short normal_i2c_range[] = { 0x20, 0x2f, 0x40, 0x4f, + I2C_CLIENT_END }; + + /* Magic definition of all other variables and things */ + I2C_CLIENT_INSMOD; + +Note that you *have* to call the two defined variables `normal_i2c' and +`normal_i2c_range', without any prefix! + + +Probing classes (sensors) +------------------------- + +If you write a `sensors' driver, you use a slightly different interface. +As well as I2C addresses, we have to cope with ISA addresses. Also, we +use a enum of chip types. Don't forget to include `sensors.h'. + +The following lists are used internally. They are all lists of integers. + + normal_i2c: filled in by the module writer. Terminated by SENSORS_I2C_END. + A list of I2C addresses which should normally be examined. + normal_i2c_range: filled in by the module writer. Terminated by + SENSORS_I2C_END + A list of pairs of I2C addresses, each pair being an inclusive range of + addresses which should normally be examined. + normal_isa: filled in by the module writer. Terminated by SENSORS_ISA_END. + A list of ISA addresses which should normally be examined. + normal_isa_range: filled in by the module writer. Terminated by + SENSORS_ISA_END + A list of triples. The first two elements are ISA addresses, being an + range of addresses which should normally be examined. The third is the + modulo parameter: only addresses which are 0 module this value relative + to the first address of the range are actually considered. + probe: insmod parameter. Initialize this list with SENSORS_I2C_END values. + A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for + the ISA bus, -1 for any I2C bus), the second is the address. These + addresses are also probed, as if they were in the 'normal' list. + probe_range: insmod parameter. Initialize this list with SENSORS_I2C_END + values. + A list of triples. The first value is a bus number (SENSORS_ISA_BUS for + the ISA bus, -1 for any I2C bus), the second and third are addresses. + These form an inclusive range of addresses that are also probed, as + if they were in the 'normal' list. + ignore: insmod parameter. Initialize this list with SENSORS_I2C_END values. + A list of pairs. The first value is a bus number (SENSORS_ISA_BUS for + the ISA bus, -1 for any I2C bus), the second is the I2C address. These + addresses are never probed. This parameter overrules 'normal' and + 'probe', but not the 'force' lists. + ignore_range: insmod parameter. Initialize this list with SENSORS_I2C_END + values. + A list of triples. The first value is a bus number (SENSORS_ISA_BUS for + the ISA bus, -1 for any I2C bus), the second and third are addresses. + These form an inclusive range of I2C addresses that are never probed. + This parameter overrules 'normal' and 'probe', but not the 'force' lists. + +Also used is a list of pointers to sensors_force_data structures: + force_data: insmod parameters. A list, ending with an element of which + the force field is NULL. + Each element contains the type of chip and a list of pairs. + The first value is a bus number (SENSORS_ISA_BUS for the ISA bus, + -1 for any I2C bus), the second is the address. + These are automatically translated to insmod variables of the form + force_foo. + +So we have a generic insmod variabled `force', and chip-specific variables +`force_CHIPNAME'. + +Fortunately, as a module writer, you just have to define the `normal' +and/or `normal_range' parameters, and define what chip names are used. +The complete declaration could look like this: + /* Scan i2c addresses 0x20 to 0x2f, 0x37, and 0x40 to 0x4f + static unsigned short normal_i2c[] = {0x37,SENSORS_I2C_END}; + static unsigned short normal_i2c_range[] = {0x20,0x2f,0x40,0x4f, + SENSORS_I2C_END}; + /* Scan ISA address 0x290 */ + static unsigned int normal_isa[] = {0x0290,SENSORS_ISA_END}; + static unsigned int normal_isa_range[] = {SENSORS_ISA_END}; + + /* Define chips foo and bar, as well as all module parameters and things */ + SENSORS_INSMOD_2(foo,bar); + +If you have one chip, you use macro SENSORS_INSMOD_1(chip), if you have 2 +you use macro SENSORS_INSMOD_2(chip1,chip2), etc. If you do not want to +bother with chip types, you can use SENSORS_INSMOD_0. + +A enum is automatically defined as follows: + enum chips { any_chip, chip1, chip2, ... } + + +Attaching to an adapter +----------------------- + +Whenever a new adapter is inserted, or for all adapters if the driver is +being registered, the callback attach_adapter() is called. Now is the +time to determine what devices are present on the adapter, and to register +a client for each of them. + +The attach_adapter callback is really easy: we just call the generic +detection function. This function will scan the bus for us, using the +information as defined in the lists explained above. If a device is +detected at a specific address, another callback is called. + + int foo_attach_adapter(struct i2c_adapter *adapter) + { + return i2c_probe(adapter,&addr_data,&foo_detect_client); + } + +For `sensors' drivers, use the sensors_detect function instead: + + int foo_attach_adapter(struct i2c_adapter *adapter) + { + return sensors_detect(adapter,&addr_data,&foo_detect_client); + } + +Remember, structure `addr_data' is defined by the macros explained above, +so you do not have to define it yourself. + +The i2c_probe or sensors_detect function will call the foo_detect_client +function only for those i2c addresses that actually have a device on +them (unless a `force' parameter was used). In addition, addresses that +are already in use (by some other registered client) are skipped. + + +The detect client function +-------------------------- + +The detect client function is called by i2c_probe or sensors_detect. +The `kind' parameter contains 0 if this call is due to a `force' +parameter, and 0 otherwise (for sensors_detect, it contains 0 if +this call is due to the generic `force' parameter, and the chip type +number if it is due to a specific `force' parameter). + +Below, some things are only needed if this is a `sensors' driver. Those +parts are between /* SENSORS ONLY START */ and /* SENSORS ONLY END */ +markers. + +This function should only return an error (any value != 0) if there is +some reason why no more detection should be done anymore. If the +detection just fails for this address, return 0. + +For now, you can ignore the `flags' parameter. It is there for future use. + + /* Unique ID allocation */ + static int foo_id = 0; + + int foo_detect_client(struct i2c_adapter *adapter, int address, + unsigned short flags, int kind) + { + int err = 0; + int i; + struct i2c_client *new_client; + struct foo_data *data; + const char *client_name = ""; /* For non-`sensors' drivers, put the real + name here! */ + + /* Let's see whether this adapter can support what we need. + Please substitute the things you need here! + For `sensors' drivers, add `! is_isa &&' to the if statement */ + if (i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA | + I2C_FUNC_SMBUS_WRITE_BYTE)) + goto ERROR0; + + /* SENSORS ONLY START */ + const char *type_name = ""; + int is_isa = i2c_is_isa_adapter(adapter); + + if (is_isa) { + + /* If this client can't be on the ISA bus at all, we can stop now + (call `goto ERROR0'). But for kicks, we will assume it is all + right. */ + + /* Discard immediately if this ISA range is already used */ + if (check_region(address,FOO_EXTENT)) + goto ERROR0; + + /* Probe whether there is anything on this address. + Some example code is below, but you will have to adapt this + for your own driver */ + + if (kind < 0) /* Only if no force parameter was used */ { + /* We may need long timeouts at least for some chips. */ + #define REALLY_SLOW_IO + i = inb_p(address + 1); + if (inb_p(address + 2) != i) + goto ERROR0; + if (inb_p(address + 3) != i) + goto ERROR0; + if (inb_p(address + 7) != i) + goto ERROR0; + #undef REALLY_SLOW_IO + + /* Let's just hope nothing breaks here */ + i = inb_p(address + 5) & 0x7f; + outb_p(~i & 0x7f,address+5); + if ((inb_p(address + 5) & 0x7f) != (~i & 0x7f)) { + outb_p(i,address+5); + return 0; + } + } + } + + /* SENSORS ONLY END */ + + /* OK. For now, we presume we have a valid client. We now create the + client structure, even though we cannot fill it completely yet. + But it allows us to access several i2c functions safely */ + + /* Note that we reserve some space for foo_data too. If you don't + need it, remove it. We do it here to help to lessen memory + fragmentation. */ + if (! (new_client = kmalloc(sizeof(struct i2c_client)) + + sizeof(struct foo_data), + GFP_KERNEL)) { + err = -ENOMEM; + goto ERROR0; + } + + /* This is tricky, but it will set the data to the right value. */ + client->data = new_client + 1; + data = (struct foo_data *) (client->data); + + new_client->addr = address; + new_client->data = data; + new_client->adapter = adapter; + new_client->driver = &foo_driver; + new_client->flags = 0; + + /* Now, we do the remaining detection. If no `force' parameter is used. */ + + /* First, the generic detection (if any), that is skipped if any force + parameter was used. */ + if (kind < 0) { + /* The below is of course bogus */ + if (foo_read(new_client,FOO_REG_GENERIC) != FOO_GENERIC_VALUE) + goto ERROR1; + } + + /* SENSORS ONLY START */ + + /* Next, specific detection. This is especially important for `sensors' + devices. */ + + /* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter + was used. */ + if (kind <= 0) { + i = foo_read(new_client,FOO_REG_CHIPTYPE); + if (i == FOO_TYPE_1) + kind = chip1; /* As defined in the enum */ + else if (i == FOO_TYPE_2) + kind = chip2; + else { + printk("foo: Ignoring 'force' parameter for unknown chip at " + "adapter %d, address 0x%02x\n",i2c_adapter_id(adapter),address); + goto ERROR1; + } + } + + /* Now set the type and chip names */ + if (kind == chip1) { + type_name = "chip1"; /* For /proc entry */ + client_name = "CHIP 1"; + } else if (kind == chip2) { + type_name = "chip2"; /* For /proc entry */ + client_name = "CHIP 2"; + } + + /* Reserve the ISA region */ + if (is_isa) + request_region(address,FOO_EXTENT,type_name); + + /* SENSORS ONLY END */ + + /* Fill in the remaining client fields. */ + strcpy(new_client->name,client_name); + + /* SENSORS ONLY BEGIN */ + data->type = kind; + /* SENSORS ONLY END */ + + new_client->id = foo_id++; /* Automatically unique */ + data->valid = 0; /* Only if you use this field */ + init_MUTEX(&data->update_lock); /* Only if you use this field */ + + /* Any other initializations in data must be done here too. */ + + /* Tell the i2c layer a new client has arrived */ + if ((err = i2c_attach_client(new_client))) + goto ERROR3; + + /* SENSORS ONLY BEGIN */ + /* Register a new directory entry with module sensors. See below for + the `template' structure. */ + if ((i = sensors_register_entry(new_client, type_name, + foo_dir_table_template,THIS_MODULE)) < 0) { + err = i; + goto ERROR4; + } + data->sysctl_id = i; + + /* SENSORS ONLY END */ + + /* This function can write default values to the client registers, if + needed. */ + foo_init_client(new_client); + return 0; + + /* OK, this is not exactly good programming practice, usually. But it is + very code-efficient in this case. */ + + ERROR4: + i2c_detach_client(new_client); + ERROR3: + ERROR2: + /* SENSORS ONLY START */ + if (is_isa) + release_region(address,FOO_EXTENT); + /* SENSORS ONLY END */ + ERROR1: + kfree(new_client); + ERROR0: + return err; + } + + +Removing the client +=================== + +The detach_client call back function is called when a client should be +removed. It may actually fail, but only when panicking. This code is +much simpler than the attachment code, fortunately! + + int foo_detach_client(struct i2c_client *client) + { + int err,i; + + /* SENSORS ONLY START */ + /* Deregister with the `sensors' module. */ + sensors_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id); + /* SENSORS ONLY END */ + + /* Try to detach the client from i2c space */ + if ((err = i2c_detach_client(client))) { + printk("foo.o: Client deregistration failed, client not detached.\n"); + return err; + } + + /* SENSORS ONLY START */ + if i2c_is_isa_client(client) + release_region(client->addr,LM78_EXTENT); + /* SENSORS ONLY END */ + + kfree(client); /* Frees client data too, if allocated at the same time */ + return 0; + } + + +Initializing the module or kernel +================================= + +When the kernel is booted, or when your foo driver module is inserted, +you have to do some initializing. Fortunately, just attaching (registering) +the driver module is usually enough. + + /* Keep track of how far we got in the initialization process. If several + things have to initialized, and we fail halfway, only those things + have to be cleaned up! */ + static int __initdata foo_initialized = 0; + + int __init foo_init(void) + { + int res; + printk("foo version %s (%s)\n",FOO_VERSION,FOO_DATE); + + if ((res = i2c_add_driver(&foo_driver))) { + printk("foo: Driver registration failed, module not inserted.\n"); + foo_cleanup(); + return res; + } + foo_initialized ++; + return 0; + } + + int __init foo_cleanup(void) + { + int res; + if (foo_initialized == 1) { + if ((res = i2c_del_driver(&foo_driver))) { + printk("foo: Driver registration failed, module not removed.\n"); + return res; + } + foo_initialized --; + } + return 0; + } + + #ifdef MODULE + + /* Substitute your own name and email address */ + MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>" + MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices"); + + int init_module(void) + { + return foo_init(); + } + + int cleanup_module(void) + { + return foo_cleanup(); + } + + #endif /* def MODULE */ + +Note that some functions are marked by `__init', and some data structures +by `__init_data'. If this driver is compiled as part of the kernel (instead +of as a module), those functions and structures can be removed after +kernel booting is completed. + +Command function +================ + +A generic ioctl-like function call back is supported. You will seldomly +need this. You may even set it to NULL. + + /* No commands defined */ + int foo_command(struct i2c_client *client, unsigned int cmd, void *arg) + { + return 0; + } + + +Sending and receiving +===================== + +If you want to communicate with your device, there are several functions +to do this. You can find all of them in i2c.h. + +If you can choose between plain i2c communication and SMBus level +communication, please use the last. All adapters understand SMBus level +commands, but only some of them understand plain i2c! + + +Plain i2c communication +----------------------- + + extern int i2c_master_send(struct i2c_client *,const char* ,int); + extern int i2c_master_recv(struct i2c_client *,char* ,int); + +These routines read and write some bytes from/to a client. The client +contains the i2c address, so you do not have to include it. The second +parameter contains the bytes the read/write, the third the length of the +buffer. Returned is the actual number of bytes read/written. + + extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[], + int num); + +This sends a series of messages. Each message can be a read or write, +and they can be mixed in any way. The transactions are combined: no +stop bit is sent between transaction. The i2c_msg structure contains +for each message the client address, the number of bytes of the message +and the message data itself. + +You can read the file `i2c-protocol' for more information about the +actual i2c protocol. + + +SMBus communication +------------------- + + extern s32 i2c_smbus_xfer (struct i2c_adapter * adapter, u16 addr, + unsigned short flags, + char read_write, u8 command, int size, + union i2c_smbus_data * data); + + This is the generic SMBus function. All functions below are implemented + in terms of it. Never use this function directly! + + + extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value); + extern s32 i2c_smbus_read_byte(struct i2c_client * client); + extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value); + extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command); + extern s32 i2c_smbus_write_byte_data(struct i2c_client * client, + u8 command, u8 value); + 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); + +All these tranactions 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 +need not be longer than 32 bytes. + +You can read the file `smbus-protocol' for more information about the +actual SMBus protocol. + + +General purpose routines +======================== + +Below all general purpose routines are listed, that were not mentioned +before. + + /* This call returns a unique low identifier for each registered adapter, + * or -1 if the adapter was not regisitered. + */ + extern int i2c_adapter_id(struct i2c_adapter *adap); + + +The sensors sysctl/proc interface +================================= + +This section only applies if you write `sensors' drivers. + +Each sensors driver creates a directory in /proc/sys/dev/sensors for each +registered client. The directory is called something like foo-i2c-4-65. +The sensors module helps you to do this as easily as possible. + +The template +------------ + +You will need to define a ctl_table template. This template will automatically +be copied to a newly allocated structure and filled in where necessary when +you call sensors_register_entry. + +First, I will give an example definition. + static ctl_table foo_dir_table_template[] = { + { FOO_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &sensors_proc_real, + &sensors_sysctl_real,NULL,&foo_func }, + { FOO_SYSCTL_FUNC2, "func2", NULL, 0, 0644, NULL, &sensors_proc_real, + &sensors_sysctl_real,NULL,&foo_func }, + { FOO_SYSCTL_DATA, "data", NULL, 0, 0644, NULL, &sensors_proc_real, + &sensors_sysctl_real,NULL,&foo_data }, + { 0 } + }; + +In the above example, three entries are defined. They can either be +accessed through the /proc interface, in the /proc/sys/dev/sensors/* +directories, as files named func1, func2 and data, or alternatively +through the sysctl interface, in the appropriate table, with identifiers +FOO_SYSCTL_FUNC1, FOO_SYSCTL_FUNC2 and FOO_SYSCTL_DATA. + +The third, sixth and ninth parameters should always be NULL, and the +fourth should always be 0. The fifth is the mode of the /proc file; +0644 is safe, as the file will be owned by root:root. + +The seventh and eigth parameters should be &sensors_proc_real and +&sensors_sysctl_real if you want to export lists of reals (scaled +integers). You can also use your own function for them, as usual. +Finally, the last parameter is the call-back to gather the data +(see below) if you use the *_proc_real functions. + + +Gathering the data +------------------ + +The call back functions (foo_func and foo_data in the above example) +can be called in several ways; the operation parameter determines +what should be done: + + * If operation == SENSORS_PROC_REAL_INFO, you must return the + magnitude (scaling) in nrels_mag; + * If operation == SENSORS_PROC_REAL_READ, you must read information + from the chip and return it in results. The number of integers + to display should be put in nrels_mag; + * If operation == SENSORS_PROC_REAL_WRITE, you must write the + supplied information to the chip. nrels_mag will contain the number + of integers, results the integers themselves. + +The *_proc_real functions will display the elements as reals for the +/proc interface. If you set the magnitude to 2, and supply 345 for +SENSORS_PROC_REAL_READ, it would display 3.45; and if the user would +write 45.6 to the /proc file, it would be returned as 4560 for +SENSORS_PROC_REAL_WRITE. A magnitude may even be negative! + +An example function: + + /* FOO_FROM_REG and FOO_TO_REG translate between scaled values and + register values. Note the use of the read cache. */ + void foo_in(struct i2c_client *client, int operation, int ctl_name, + int *nrels_mag, long *results) + { + struct foo_data *data = client->data; + int nr = ctl_name - FOO_SYSCTL_FUNC1; /* reduce to 0 upwards */ + + if (operation == SENSORS_PROC_REAL_INFO) + *nrels_mag = 2; + else if (operation == SENSORS_PROC_REAL_READ) { + /* Update the readings cache (if necessary) */ + foo_update_client(client); + /* Get the readings from the cache */ + results[0] = FOO_FROM_REG(data->foo_func_base[nr]); + results[1] = FOO_FROM_REG(data->foo_func_more[nr]); + results[2] = FOO_FROM_REG(data->foo_func_readonly[nr]); + *nrels_mag = 2; + } else if (operation == SENSORS_PROC_REAL_WRITE) { + if (*nrels_mag >= 1) { + /* Update the cache */ + data->foo_base[nr] = FOO_TO_REG(results[0]); + /* Update the chip */ + foo_write_value(client,FOO_REG_FUNC_BASE(nr),data->foo_base[nr]); + } + if (*nrels_mag >= 2) { + /* Update the cache */ + data->foo_more[nr] = FOO_TO_REG(results[1]); + /* Update the chip */ + foo_write_value(client,FOO_REG_FUNC_MORE(nr),data->foo_more[nr]); + } + } + } diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index e88c7c150..d82ffd885 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -52,7 +52,7 @@ be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up. - 53c7xx= [HW,SCSI] + 53c7xx= [HW,SCSI] Amiga SCSI controllers adb_buttons= [HW,MOUSE] @@ -70,6 +70,8 @@ running once the system is up. arcrimi= [HW,NET] + ataflop= [HW, M68k] + atamouse= [HW,MOUSE] Atari Mouse. atascsi= [HW,SCSI] Atari SCSI. @@ -98,22 +100,22 @@ running once the system is up. com90xx= [HW,NET] - console= + console= [KNL] output console + comm spec (speed, control, parity) cyclades= [HW,SERIAL] Cyclades multi-serial port adapter. - debug [KNL] Enable kernel debugging. + debug [KNL] Enable kernel debugging (events log level). decnet= [HW,NET] - digi= [HW,SERIAL] + digi= [HW,SERIAL] io parameters + enable/disable command digiepca= [HW,SERIAL] dmascc= [HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA support available. - dmasound= [HW,SOUND] + dmasound= [HW,SOUND] (sound subsystem buffers) dtc3181e= [HW,SCSI] @@ -123,7 +125,7 @@ running once the system is up. edb= [HW,PS2] - ether= [HW,NET] Ethernet. + ether= [HW,NET] Ethernet cards parameters (iomem,irq,dev_name). fd_mcs= [HW,SCSI] @@ -131,7 +133,7 @@ running once the system is up. floppy= [HW] - ftape= [HW] Floppy Tape subsystem. + ftape= [HW] Floppy Tape subsystem debugging options. gdth= [HW,SCSI] @@ -139,7 +141,8 @@ running once the system is up. gvp11= [HW,SCSI] - hd= [EIDE] IDE and EIDE hard drive subsystem. + hd= [EIDE] (E)IDE hard drive subsystem + geometry (Cyl/heads/sectors) or tune parameters. hfmodem= [HW,AX25] @@ -147,13 +150,27 @@ running once the system is up. hisax= [HW,ISDN] + in2000= [HW,SCSI] + + init= [KNL] + + + ibmmcascsi= [HW,MCA,SCSI] IBM MicroChannel SCSI adapter. icn= [HW,ISDN] + ide?= [HW] (E)IDE subsystem : config (iomem/irq), tuning or + debugging (serialize,reset,no{dma,tune,probe}) or + chipset specific parameters + + idebus= [HW] (E)IDE subsystem : VLB/PCI bus speed + in2000= [HW,SCSI] - init= [KNL] + init= [KNL] default init level + + initrd= [KNL] initial ramdisk path ip= [PNP] @@ -187,7 +204,7 @@ running once the system is up. kbd-reset [VT] - load_ramdisk= [RAM] + load_ramdisk= [RAM] initrd loading boolean lp=0 [LP] Specify parallel ports to use, e.g, or lp=port[,port...] lp=none,parport0 (lp0 not configured, lp1 uses @@ -223,10 +240,13 @@ or lp=auto driver. 'lp=reset' (which can be specified in mcdx= [HW,CD] - md= [HW] + md= [HW] RAID subsystems devices and level mdacon= [MDA] + mem= [KNL] force use XX Mb of memory when the kernel is not able + to see the whole system memory or for test + msmouse= [HW,MOUSE] Microsoft Mouse. ncr5380= [HW,SCSI] @@ -241,7 +261,9 @@ or lp=auto driver. 'lp=reset' (which can be specified in nfsaddrs= [NFS] - nfsroot= [NFS] + nfsroot= [NFS] nfs root filesystem for disk-less boxes + + nmi_watchdog= [KNL, BUGS=ix86] debugging features for SMP kernels no387 [BUGS=ix86] Tells the kernel to use the 387 maths emulation library even if a 387 maths coprocessor @@ -250,6 +272,10 @@ or lp=auto driver. 'lp=reset' (which can be specified in noapic [SMP,APIC] Tells the kernel not to make use of any APIC that may be present on the system. + noasync [HW, M68K] Disables async and sync negotiation for all devices. + + nodisconnect [HW,SCSI, M68K] Disables SCSI disconnects. + no-halt [BUGS=ix86] noinitrd [RAM] Tells the kernel not to load any configured @@ -259,9 +285,11 @@ or lp=auto driver. 'lp=reset' (which can be specified in nosmp [SMP] Tells an SMP kernel to act as a UP kernel. + nosync [HW, M68K] Disables sync negotiation for all devices. + optcd= [HW,CD] - panic= + panic= [KNL] kernel behaviour on panic parport=0 [HW,PPT] Specify parallel ports. 0 or parport=auto disables. Use 'auto' to force the driver @@ -293,11 +321,11 @@ or parport=0xBBB[,IRQ[,DMA]] to use any IRQ/DMA settings detected pg. [PARIDE] - pirq= [SMP,APIC] + pirq= [SMP,APIC] mp-table plip= [PPT,NET] Parallel port network link. - profile= + profile= [KNL] enable kernel profiling via /proc/profile (param:log level) prompt_ramdisk= [RAM] Whether to prompt for ramdisk before loading its contents into memory. @@ -312,16 +340,18 @@ or parport=0xBBB[,IRQ[,DMA]] to use any IRQ/DMA settings detected reboot= [BUGS=ix86] - reserve= + reserve= [KNL,BUGS] force the kernel to ignore some iomem area riscom8= [HW,SERIAL] ro [KNL] Mount root device read-only on boot. - root= + root= [KNL] root filesystem rw [KNL] Mount root device read-write on boot. + S [KNL] run init in single mode + sbpcd= [HW,CD] Soundblaster CD adapter. scsi_logging= [SCSI] @@ -336,12 +366,14 @@ or parport=0xBBB[,IRQ[,DMA]] to use any IRQ/DMA settings detected specialix= [HW,SERIAL] Specialix multi-serial port adapter. - st= [HW] + st= [HW] SCSI tape parameters (buffers, ..) st0x= [HW,SCSI] stram_swap= [HW] + switches= [HW, M68K] + sym53c416= [HW,SCSI] sym53c8xx= [HW,SCSI] @@ -356,7 +388,10 @@ or parport=0xBBB[,IRQ[,DMA]] to use any IRQ/DMA settings detected u14-34f= [HW,SCSI] - video= [FB] + video= [FB] frame buffer configuration + + vga= [KNL] on ix386, enable to choose a peculiar video mode + vga=ask wd33c93= [HW,SCSI] @@ -364,6 +399,6 @@ or parport=0xBBB[,IRQ[,DMA]] to use any IRQ/DMA settings detected wdt= [HW] - xd= [HW,XT] + xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks xd_geo= [HW,XT] diff --git a/Documentation/kmod.txt b/Documentation/kmod.txt index 759a300b1..be1a9a518 100644 --- a/Documentation/kmod.txt +++ b/Documentation/kmod.txt @@ -45,3 +45,24 @@ If kerneld worked, why replace it? - kmod reports errors through the normal kernel mechanisms, which avoids the chicken and egg problem of kerneld and modular Unix domain sockets + + +Keith Owens <kaos@ocs.com.au> December 1999 + +The combination of kmod and modprobe can loop, especially if modprobe uses a +system call that requires a module. If modules.dep does not exist and modprobe +was started with the -s option (kmod does this), modprobe tries to syslog() a +message. syslog() needs Unix sockets, if Unix sockets are modular then kmod +runs "modprobe -s net-pf-1". This runs a second copy of modprobe which +complains that modules.dep does not exist, tries to use syslog() and starts yet +another copy of modprobe. This is not the only possible kmod/modprobe loop, +just the most common. + +To detect loops caused by "modprobe needs a service which is in a module", kmod +limits the number of concurrent kmod issued modprobes. See MAX_KMOD_CONCURRENT +in kernel/kmod.c. When this limit is exceeded, the kernel issues message "kmod: +runaway modprobe loop assumed and stopped". + +Note for users building a heavily modularised system. It is a good idea to +create modules.dep after installing the modules and before booting a kernel for +the first time. "depmod -ae m.n.p" where m.n.p is the new kernel version. diff --git a/Documentation/networking/cops.txt b/Documentation/networking/cops.txt index 3251a247c..b7e06c55f 100644 --- a/Documentation/networking/cops.txt +++ b/Documentation/networking/cops.txt @@ -1,5 +1,5 @@ Text File for the COPS LocalTalk Linux driver (cops.c). - By Jay Schulist <Jay.Schulist@spacs.k12.wi.us> + By Jay Schulist <jschlst@turbolinux.com> This driver has two modes and they are: Dayna mode and Tangent mode. Each mode corresponds with the type of card. It has been found diff --git a/Documentation/networking/ethertap.txt b/Documentation/networking/ethertap.txt index 27202efba..7af37a004 100644 --- a/Documentation/networking/ethertap.txt +++ b/Documentation/networking/ethertap.txt @@ -1,6 +1,6 @@ Documentation on setup and use of EtherTap. -Contact Jay Schulist <Jay.Schulist@spacs.k12.wi.us> if you +Contact Jay Schulist <jschlst@turbolinux.com> if you have questions or need futher assistance. Introduction diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 86fc021af..76ee08458 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -1,5 +1,5 @@ filter.txt: Linux Socket Filtering -Written by: Jay Schulist <Jay.Schulist@spacs.k12.wi.us> +Written by: Jay Schulist <jschlst@turbolinux.com> Introduction ============ diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 8def0e7fc..614cf43b7 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -51,6 +51,36 @@ ipfrag_low_thresh - INTEGER ipfrag_time - INTEGER Time in seconds to keep an IP fragment in memory. +INET peer storage: + +inet_peer_threshold - INTEGER + The approximate size of the storage. Starting from this threshold + entries will be thrown aggressively. This threshold also determines + entries' time-to-live and time intervals between garbage collection + passes. More entries, less time-to-live, less GC interval. + +inet_peer_minttl - INTEGER + Minimum time-to-live of entries. Should be enough to cover fragment + time-to-live on the reassembling side. This minimum time-to-live is + guaranteed if the pool size is less than inet_peer_threshold. + Measured in jiffies. + +inet_peer_maxttl - INTEGER + Maximum time-to-live of entries. Unused entries will expire after + this period of time if there is no memory pressure on the pool (i.e. + when the number of entries in the pool is very small). + Measured in jiffies. + +inet_peer_gc_mintime - INTEGER + Minimum interval between garbage collection passes. This interval is + in effect under high memory pressure on the pool. + Measured in jiffies. + +inet_peer_gc_maxtime - INTEGER + Minimum interval between garbage collection passes. This interval is + in effect under low (or absent) memory pressure on the pool. + Measured in jiffies. + TCP variables: tcp_syn_retries - INTEGER @@ -211,4 +241,4 @@ kuznet@ms2.inr.ac.ru Updated by: Andi Kleen ak@muc.de -$Id: ip-sysctl.txt,v 1.9 1999/05/08 02:58:44 davem Exp $ +$Id: ip-sysctl.txt,v 1.10 2000/01/06 00:41:42 davem Exp $ diff --git a/Documentation/networking/ipddp.txt b/Documentation/networking/ipddp.txt index c2cabb682..8df88a7df 100644 --- a/Documentation/networking/ipddp.txt +++ b/Documentation/networking/ipddp.txt @@ -1,7 +1,7 @@ Text file for ipddp.c: AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation -This text file writen by Jay Schulist <Jay.Schulist@spacs.k12.wi.us> +This text file writen by Jay Schulist <jschlst@turbolinux.com> Introduction ------------ @@ -38,7 +38,7 @@ Basic instructions for user space tools To enable AppleTalk-IP decapsulation/encapsulation you will need the proper tools. You can get the tools for decapsulation from -http://spacs1.spacs.k12.wi.us/~jschlst/MacGate and for encapsulation +http://spacs1.spacs.k12.wi.us/~jschlst/index.html and for encapsulation from http://www.maths.unm.edu/~bradford/ltpc.html I will briefly describe the operation of the tools, but you will @@ -72,7 +72,7 @@ EtherTalk only network. Further Assistance ------------------- -You can contact me (Jay Schulist <Jay.Schulist@spacs.k12.wi.us>) with any +You can contact me (Jay Schulist <jschlst@turbolinux.com>) with any questions regarding decapsulation or encapsulation. Bradford W. Johnson <johns393@maroon.tc.umn.edu> originally wrote the ipddp.c driver for IP encapsulation in AppleTalk. diff --git a/Documentation/networking/sis900.txt b/Documentation/networking/sis900.txt index 474d3c081..b353eaa3b 100644 --- a/Documentation/networking/sis900.txt +++ b/Documentation/networking/sis900.txt @@ -1,6 +1,6 @@ SiS 900/7016 Fast Ethernet Device Driver by Ollie Lho (ollie@sis.com.tw) - November 4, 1999. Document Revision: 0.1 + November 4, 1999. Document Revision: 0.2 This document gives some information on installation and usage of SiS 900/7016 device driver under Linux. @@ -17,7 +17,7 @@ 4. Tested Environment - 5. Files in This Rackage + 5. Files in This Package 6. Installation @@ -111,9 +111,11 @@ 9. Names of variables were changed to be more consistent. - 10. Clean up of auo-negotiation and timer code. + 10. + Clean up of auo-negotiation and timer code. - 11. Automatic detection and change of PHY on the fly. + 11. + Automatic detection and change of PHY on the fly. 4. Tested Environment @@ -137,7 +139,7 @@ o Samba version 2.0.3 - 5. Files in This Rackage + 5. Files in This Package In the package you can find these files: @@ -157,10 +159,16 @@ 6. Installation - Before trying to install the driver, be sure to get the latest - revision from SiS' Home Page. If you have no prior experience in - networking under Linux, please read Ethernet HOWTO and Networking - HOWTO available from Linux Documentation Project (LDP). + Silicon Integrated System Corp. is cooperating closely with core Linux + Kernel developers. The revisions of SiS 900 driver are distributed by + the usuall channels for kernel tar files and patches. Those kernel tar + files for official kernel and patches for kernel pre-release can be + download at official kernel ftp site + <http://ftp.kernel.org/pub/linux/kernel/> and its mirrors. The 1.06 + revision can be found in kernel version later than 2.3.15 and + pre-2.2.14. If you have no prior experience in networking under + Linux, please read Ethernet HOWTO and Networking HOWTO available from + Linux Documentation Project (LDP). The installation procedure are different according to your kernel versions. @@ -244,6 +252,7 @@ sis900.c: v1.06 11/04/99 eth0: SiS 900 PCI Fast Ethernet at 0xd000, IRQ 10, 00:00:e8:83:7f:a4. eth0: SiS 900 Internal MII PHY transceiver found at address 1. + eth0: Using SiS 900 Internal MII PHY as default @@ -269,7 +278,6 @@ - eth0: Using SiS 900 Internal MII PHY as default eth0: Media Link On 100mbps full-duplex diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt new file mode 100644 index 000000000..f93c51470 --- /dev/null +++ b/Documentation/networking/smctr.txt @@ -0,0 +1,68 @@ +Text File for the SMC TokenCard TokenRing Linux driver (smctr.c). + By Jay Schulist <jschlst@turbolinux.com> + +The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) +ISA adapters. Preliminary support for the SMC TokenCard Elite/A (8115T/A) +MCA adapter has been started but is not complete. (Contact me for information +if you have the proper setup to finish the MCA parts). + +Latest information on this driver can be obtained on the Linux-SNA WWW site. +Please point your browser to: http://www.linux-sna.org + +This driver is rather simple to use. Select Y to Token Ring adapter support +in the kernel configuration. A choice for SMC Token Ring adapters will +appear. This drives supports all SMC ISA/MCA adapters. Choose this +option. I personally recommend compiling the driver as a module (M), but if you +you would like to compile it staticly answer Y instead. + +This driver supports multiple adapters without the need to load multiple copies +of the driver. You should be able to load up to 7 adapters without any kernel +modifications, if you are in need of more please contact the maintainer of this +driver. + +Load the driver either by lilo/loadlin or as a module. When a module using the +following command will suffice for most: + +# modprobe smctr +smctr.c: v1.00 12/6/99 by jschlst@turbolinux.com +tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000. + +Now just setup the device via ifconfig and set and routes you may have. After +this you are ready to start sending some tokens. + +Errata: +1). For anyone wondering where to pick up the SMC adapters please browse + to http://www.smc.com + +2). If you are the first/only Token Ring Client on a Token Ring LAN, please + specify the ringspeed with the ringspeed=[4/16] module option. If no + ringspeed is specified the driver will attempt to autodetect the ring + speed and/or if the adapter is the first/only station on the ring take + the appropriate actions. + + NOTE: Default ring speed is 16MB UTP. + +3). PnP support for this adapter sucks. I recommend hard setting the + IO/MEM/IRQ by the jumpers on the adapter. If this is not possible + load the module with the following io=[ioaddr] mem=[mem_addr] + irq=[irq_num]. + + The following IRQ, IO, and MEM settings are supported. + + IO ports: + 0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300, + 0x320, 0x340, 0x360, 0x380. + + IRQs: + 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15 + + Memory addresses: + 0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000, + 0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000, + 0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000, + 0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000 + +This driver is under the GNU General Public License. Its Firmware image is +included as an initialized C-array and is licensed by SMC to the Linux +users of this driver. However no waranty about its fitness is expressed or +implied by SMC. diff --git a/Documentation/networking/sktr.txt b/Documentation/networking/tms380tr.txt index a35332af1..f73895f4f 100644 --- a/Documentation/networking/sktr.txt +++ b/Documentation/networking/tms380tr.txt @@ -1,5 +1,5 @@ Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver. - Text file by: Jay Schulist <jschlst@samba.anu.edu.au> + Text file by: Jay Schulist <jschlst@turbolinux.com> The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA, SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the @@ -7,7 +7,7 @@ SK NET TR4/16 ISA card. Latest information on this driver can be obtained on the Linux-SNA WWW site. Please point your browser to: -http://samba.anu.edu.au/linux-sna/documents/drivers/SysKonnect/ +http://www.linux-sna.org Many thanks to Christoph Goos for his excellent work on this driver and SysKonnect for donating the adapters to Linux-SNA for the testing and maintaince diff --git a/Documentation/parport.txt b/Documentation/parport.txt index db0c13e0b..4a0a25e49 100644 --- a/Documentation/parport.txt +++ b/Documentation/parport.txt @@ -38,13 +38,17 @@ KMod If you use kmod, you will find it useful to edit /etc/modules.conf. Here is an example of the lines that need to be added: - post-install parport modprobe -k parport_pc + alias parport_lowlevel parport_pc options parport_pc io=0x378,0x278 irq=7,auto KMod will then automatically load parport_pc (with the options "io=0x378,0x278 irq=7,auto") whenever a parallel port device driver (such as lp) is loaded. +Note that these are example lines only! You shouldn't in general need +to specify any options to parport_pc in order to be able to use a +parallel port. + Parport probe [optional] ------------- diff --git a/Documentation/pci.txt b/Documentation/pci.txt index 7108532cb..e74477fd4 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -35,8 +35,13 @@ pci_find_subsys(VENDOR_ID, DEVICE_ID, SUBSYS_VENDOR_ID, SUBSYS_DEVICE_ID, dev). VENDOR_ID or DEVICE_ID. This allows searching for any device from a specific vendor, for example. - In case you want to do some complex matching, look at pci_devices -- it's -a linked list of pci_dev structures for all PCI devices in the system. + In case you want to do some complex matching, you can walk the list of all +known PCI devices: + + struct pci_dev *dev; + pci_for_each_dev(dev) { + ... do anything you want with dev ... + } The `struct pci_dev *' pointer serves as an identification of a PCI device and is passed to all other functions operating on PCI devices. diff --git a/Documentation/serial-console.txt b/Documentation/serial-console.txt index 5b4168833..80fd38300 100644 --- a/Documentation/serial-console.txt +++ b/Documentation/serial-console.txt @@ -11,6 +11,7 @@ The format of this option is: device: tty0 for the foreground virtual console ttyX for any other virtual console ttySx for a serial port + lp0 for the first parallel port options: depend on the driver. For the serial port this defines the baudrate/parity/bits of the port, diff --git a/Documentation/sound/Maestro b/Documentation/sound/Maestro new file mode 100644 index 000000000..f3cc4ab77 --- /dev/null +++ b/Documentation/sound/Maestro @@ -0,0 +1,98 @@ + An OSS/Lite Driver for the ESS Maestro family of sound cards + + Zach Brown, December 1999 + +Driver Status and Availability +------------------------------ + +The most recent version of this driver will hopefully always be available at + http://people.redhat.com/zab/maestro/ + +I will try and maintain the most recent stable version of the driver +in both the stable and development kernel lines. + +ESS Maestro Chip Family +----------------------- + +There are 3 main variants of the ESS Maestro PCI sound chip. The first +is the Maestro 1. It was originally produced by Platform Tech as the +'AGOGO'. It can be recognized by Platform Tech's PCI ID 0x1285 with +0x0100 as the device ID. It was put on some sound boards and a few laptops. +ESS bought the design and cleaned it up as the Maestro 2. This starts +their marking with the ESS vendor ID 0x125D and the 'year' device IDs. +The Maestro 2 claims 0x1968 while the Maestro 2e has 0x1978. + +The various families of Maestro are mostly identical as far as this +driver is concerned. It doesn't touch the DSP parts that differ (though +it could for FM synthesis) + +Driver OSS Behavior +-------------------- + +This OSS driver exports /dev/mixer and /dev/dsp to applications, which +mostly adhere to the OSS spec. This driver doesn't register itself +with /dev/sndstat, so don't expect information to appear there. + +The /dev/dsp device exported behaves almost as expected. Playback is +supported in all the various lovely formats. 8/16bit stereo/mono from +8khz to 48khz, and mmap()ing for playback behaves. Capture/recording +is limited due to oddities with the Maestro hardware. One can only +record in 16bit stereo. For recording the maestro uses non interleaved +stereo buffers so that mmap()ing the incoming data does not result in +a ring buffer of LRLR data. mmap()ing of the read buffers is therefore +disallowed until this can be cleaned up. + +/dev/mixer is an interface to the AC'97 codec on the Maestro. It is +worth noting that there are a variety of AC'97s that can be wired to +the Maestro. Which is used is entirely up to the hardware implementor. +This should only be visible to the user by the presence, or lack, of +'Bass' and 'Treble' sliders in the mixer. Not all AC'97s have them. + +The driver doesn't support MIDI or FM playback at the moment. Typically +the Maestro is wired to an MPU MIDI chip, but some hardware implementations +don't. We need to assemble a white list of hardware implementations that +have MIDI wired properly before we can claim to support it safely. + +Compiling and Installing +------------------------ + +With the drivers inclusion into the kernel, compiling and installing +is the same as most OSS/Lite modular sound drivers. Compilation +of the driver is enabled through the CONFIG_SOUND_MAESTRO variable +in the config system. + +It may be modular or statically linked. If it is modular it should be +installed with the rest of the modules for the kernel on the system. +Typically this will be in /lib/modules/ somewhere. 'alias sound maestro' +should also be added to your module configs (typically /etc/conf.modules) +if you're using modular OSS/Lite sound and want to default to using a +maestro chip. + +As this is a PCI device, the module does not need to be informed of +any IO or IRQ resources it should use, it devines these from the +system. Somtimes, on sucky PCs, the BIOS fails to allocated resources +for the maestro. This will result in a message like: + maestro: PCI subsystem reports IRQ 0, this might not be correct. +from the kernel. Should this happen the sound chip most likely will +not operate correctly. To solve this one has to dig through their BIOS +(typically entered by hitting a hot key at boot time) and figure out +what magic needs to happen so that the BIOS will reward the maestro with +an IRQ. This operation is incredibly system specific, so you're on your +own. Sometimes the magic lies in 'PNP Capable Operating System' settings. + +There are very few options to the driver. One is 'debug' which will +tell the driver to print minimal debugging information as it runs. This +can be collected with 'dmesg' or through the klogd daemon. + +The other, more interesting option, is 'dsps_order'. Typically at +install time the driver will only register one available /dev/dsp device +for its use. The 'dsps_order' module parameter allows for more devices +to be allocated, as a power of two. Up to 4 devices can be registered +( dsps_order=2 ). These devices act as fully distinct units and use +separate channels in the maestro. + +.. more details .. +----------------- + +drivers/sound/maestro.c contains comments that hopefully explain +the maestro implementation. diff --git a/Documentation/sound/via82cxxx.txt b/Documentation/sound/via82cxxx.txt new file mode 100644 index 000000000..62877fd79 --- /dev/null +++ b/Documentation/sound/via82cxxx.txt @@ -0,0 +1,146 @@ + Via motherboard audio driver + Copyright 1999,2000 Jeff Garzik <jgarzik@mandrakesoft.com> + +Driver software and documentation distributed under the GNU GENERAL +PUBLIC LICENSE (GPL) Version 2. See the "COPYING" file distributed with +this software for more info. + + + +Introduction +------------------------------------------------------------------------ +The via82cxxx audio driver found in the drivers/sound directory +of the kernel source tree is a PCI audio driver for audio chips +found on Via-based motherboards, such as the MVP4. + +Currently the driver provides audio via SoundBlaster Pro compatibility, +and MIDI via MPU-401 compatibility. An AC97 mixing device is also +supported, and is generally preferred over the SoundBlaster mixer. + +IMPORTANT NOTE: Some users report that the SoundBlaster mixer does +not work at all -- use the AC97 mixer if possible. + +Please send bug reports to the mailing list linux-via@gtf.org. +To subscribe, e-mail majordomo@gtf.org with "subscribe linux-via" in the +body of the message. + + +Thanks +------------------------------------------------------------------------ +Via for providing e-mail support, specs, and NDA's source code. + +MandrakeSoft for providing hacking time. + +AC97 mixer interface fixes and debugging by Ron Cemer <roncemer@gte.net> + + + +Installation +------------------------------------------------------------------------ +If the driver is being statically compiled into the kernel, no +configuration should be necessary. + +If the driver is being compiled as a module, generally two lines must +be added to your /etc/conf.modules (or /etc/modules.conf) file: + + alias sound via82cxxx + options sb support=1 + +The second line is very important: it tells the required 'sb' module +not to load SoundBlaster support, but to instead let the Via driver +do so at a later time. + + + +Driver notes +------------------------------------------------------------------------ +This driver by default supports all PCI audio devices which report +a vendor id of 0x1106, and a device id of 0x3058. Subsystem vendor +and device ids are not examined. + +Only supports a single sound chip, as this is a motherboard chipset. +Some architecture remains for multiple cards, feel free to submit +a patch to clean some of that up. Ideally, + +No consideration for SMP, this chipset is not known to be found on +any SMP motherboards. However, this will change when we start handling +our own interrupts in "native mode." + +GNU indent formatting options: -kr -i8 -pcs + + + +Tested Hardware +------------------------------------------------------------------------ +The following is an _incomplete_ list of motherboards supported by this +audio driver. If your motherboard (or notebook) is not listed here, +please e-mail the maintainer with details. + + AOpen MX59 Pro (Apollo MVP4) + + + +The Future +------------------------------------------------------------------------ +Via has graciously donated e-mail support and source code to help further +the development of this driver. Their assistance has been invaluable +in the design and coding of the next major version of this driver. + +This audio chip supports a DirectSound(tm)-style hardware interface, +with a single 16-bit stereo input channel, and a single 16-bit stereo +output channel. Data is transferred to/from the hardware using +table-driven scatter-gather DMA buffers. + +Work is currently underway to support this "native mode" of the chip. +When complete, SoundBlaster legacy mode will be completely removed. +After a round of testing, this code will become version 2.0.0. + +Following the 2.0.0 release, the last major task to complete is +MIDI support. MPU-401 legacy support is available currently, but +not well tested at all. + +The Via audio chip apparently provides a second PCM scatter-gather +DMA channel just for FM data, but does not have a full hardware MIDI +processor. I haven't put much thought towards a solution here, but it +might involve using SoftOSS midi wave table, or simply disabling MIDI +support altogether and using the FM PCM channel as a second (input? output?) + + + +General To-do List (patches/suggestions welcome) +------------------------------------------------------------------------ +Better docs + +Code review by sound guru(s) + +Native DSP audio driver using scatter-gather DMA, as described above + +Native MIDI driver, as described above + + + +Known bugs (patches/suggestions welcome) +------------------------------------------------------------------------ +1) Two MIDI devices are loaded by the sound driver. Eliminate one of them. +Sample /proc/sound output: + + Midi devices: + 0: Sound Blaster + 1: VIA 82Cxxx Audio driver 1.1.2 + +2) Two mixer devices are loaded by the sound driver. Eliminate one of +them. At least one bug report says that SB mixer does not work at all, +only AC97 mixer. Sample /proc/sound output: + + Mixers: + 0: via82cxxxAC97Mixer + 1: Sound Blaster + +3) After unloading the driver, a SoundBlaster MIDI device is still +listed in /proc/sound. Investigate what is not being unloaded, +and fix it. Sample /proc/sound output, after 'rmmod via82cxxx': + + Midi devices: + 0: Sound Blaster + + diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt new file mode 100644 index 000000000..ce67a823c --- /dev/null +++ b/Documentation/telephony/ixj.txt @@ -0,0 +1,406 @@ +Linux Quicknet-Drivers-Howto +Quicknet Technologies, Inc. (www.quicknet.net) +Version 0.3.4 December 18, 1999 + +1.0 Introduction + +This document describes the first GPL release version of the Linux +driver for the Quicknet Internet PhoneJACK and Internet LineJACK +cards. More information about these cards is available at +www.quicknet.net. The driver version discussed in this document is +0.3.4. + +These cards offer nice telco style interfaces to use your standard +telephone/key system/PBX as the user interface for VoIP applications. +The Internet LineJACK also offers PSTN connectivity for a single line +Internet to PSTN gateway. Of course, you can add more than one card +to a system to obtain multi-line functionality. At this time, the +driver supports the POTS port on both the Internet PhoneJACK and the +Internet LineJACK, but the PSTN port on the latter card is not yet +supported. + +This document, and the drivers for the cards, are intended for a +limited audience that includes technically capable programmers who +would like to experiment with Quicknet cards. The drivers are +considered in ALPHA status and are not yet considered stable enough +for general, widespread use in an unlimited audience. + +That's worth saying again: + +THE LINUX DRIVERS FOR QUICKNET CARDS ARE PRESENTLY IN A ALPHA STATE +AND SHOULD NOT BE CONSIDERED AS READY FOR NORMAL WIDESPREAD USE. + +They are released early in the spirit of Internet development and to +make this technology available to innovators who would benefit from +early exposure. + +When we promote the device driver to "beta" level it will be +considered ready for non-programmer, non-technical users. Until then, +please be aware that these drivers may not be stable and may affect +the performance of your system. + + +1.1 Latest Additions/Improvements + +The 0.3.4 version of the driver is the first GPL release. Several +features had to be removed from the prior binary only module, mostly +for reasons of Intellectual Property rights. We can't release +information that is not ours - so certain aspects of the driver had to +be removed to protect the rights of others. + +Specifically, very old Internet PhoneJACK cards have non-standard +G.723.1 codecs (due to the early nature of the DSPs in those days). +The auto-conversion code to bring those cards into compliance with +todays standards is available as a binary only module to those people +needing it. If you bought your card after 1997 or so, you are OK - +it's only the very old cards that are affected. + +Also, the code to download G.728/G.729/G.729a codecs to the DSP is +available as a binary only module as well. This IP is not ours to +release. + +Hooks are built into the GPL driver to allow it to work with other +companion modules that are completely separate from this module. + +1.2 Copyright, Trademarks, Disclaimer, & Credits + +Copyright + +Copyright (c) 1999 Quicknet Technologies, Inc. Permission is granted +to freely copy and distribute this document provided you preserve it +in its original form. For corrections and minor changes contact the +maintainer at linux@quicknet.net. + +Trademarks + +Internet PhoneJACK and Internet LineJACK are registered trademarks of +Quicknet Technologies, Inc. + +Disclaimer + +Much of the info in this HOWTO is early information released by +Quicknet Technologies, Inc. for the express purpose of allowing early +testing and use of the Linux drivers developed for their products. +While every attempt has been made to be thorough, complete and +accurate, the information contained here may be unreliable and there +are likely a number of errors in this document. Please let the +maintainer know about them. Since this is free documentation, it +should be obvious that neither I nor previous authors can be held +legally responsible for any errors. + +Credits + +This HOWTO was written by: + + Greg Herlein <gherlein@quicknet.net> + Ed Okerson <eokerson@quicknet.net> + +1.3 Future Plans: You Can Help + +Please let the maintainer know of any errors in facts, opinions, +logic, spelling, grammar, clarity, links, etc. But first, if the date +is over a month old, check to see that you have the latest +version. Please send any info that you think belongs in this document. + +You can also contribute code and/or bug-fixes for the sample +applications. + + +1.4 Where to get things + +You can download the latest versions of the driver from: + +http://www.quicknet.net/develop.htm + +You can download the latest version of this document from: + +http://www.quicknet.net/develop.htm + + +1.5 Mailing List + +Quicknet operates a mailing list to provide a public forum on using +these drivers. + +To subscribe to the linux-sdk mailing list, send an email to: + + majordomo@linux.quicknet.net + +In the body of the email, type: + + subscribe linux-sdk <your-email-address> + +Please delete any signature block that you would normally add to the +bottom of your email - it tends to confuse majordomo. + +To send mail to the list, address your mail to + + linux-sdk@linux.quicknet.net + +Your message will go out to everyone on the list. + +To unsubscribe to the linux-sdk mailing list, send an email to: + + majordomo@linux.quicknet.net + +In the body of the email, type: + + unsubscribe linux-sdk <your-email-address> + + + +2.0 Requirements + +2.1 Quicknet Card(s) + +You will need at least one Internet PhoneJACK or Internet LineJACK +cards. These are ISA or PCI bus devices that use Plug-n-Play for +configuration, and use no IRQs. The driver will support up to 16 +cards in any one system, of any mix between the two types. + +Note that you will need two cards to do any useful testing alone, since +you will need a card on both ends of the connection. Of course, if +you are doing collaborative work, perhaps your friends or coworkers +have cards too. If not, we'll gladly sell them some! + + +2.2 ISAPNP + +Since the Quicknet cards are Plug-n-Play devices, you will need the +isapnp tools package to configure the cards, or you can use the isapnp +module to autoconfigure them. The former package probably came with +your Linux distribution. Documentation on this package is available +online at: + +http://mailer.wiwi.uni-marburg.de/linux/LDP/HOWTO/Plug-and-Play-HOWTO.html + +The isapnp autoconfiguration is available on the Quicknet website at: + + http://www.quicknet.net/develop.htm + +though it may be in the kernel by the time you read this. + + +3.0 Card Configuration + +If you did not get your drivers as part of the linux kernel, do the +following to install them: + + a. untar the distribution file. We use the following command: + tar -xvzf ixj-0.x.x.tgz + +This creates a subdirectory holding all the necessary files. Go to that +subdirectory. + + b. run the "ixj_dev_create" script to remove any stray device +files left in the /dev directory, and to create the new officially +designated device files. Note that the old devices were called +/dev/ixj, and the new method uses /dev/phone. + + c. type "make;make install" - this will compile and install the +module. + + d. type "depmod -av" to rebuild all your kernel version dependencies. + + e. if you are using the isapnp module to configure the cards + automatically, then skip to step f. Otherwise, ensure that you + have run the isapnp configuration utility to properly configure + the cards. + + e1. The Internet PhoneJACK has one configuration register that + requires 16 IO ports. The Internet LineJACK card has two + configuration registers and isapnp reports that IO 0 + requires 16 IO ports and IO 1 requires 8. The Quicknet + driver assumes that these registers are configured to be + contiguous, i.e. if IO 0 is set to 0x340 then IO 1 should + be set to 0x350. + + Make sure that none of the cards overlap if you have + multiple cards in the system. + + If you are new to the isapnp tools, you can jumpstart + yourself by doing the following: + + e2. go to the /etc directory and run pnpdump to get a blank + isapnp.conf file. + + pnpdump > /etc/isapnp.conf + + e3. edit the /etc/isapnp.conf file to set the IO warnings and + the register IO addresses. The IO warnings means that you + should find the line in the file that looks like this: + + (CONFLICT (IO FATAL)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # or WARNING + + and you should edit the line to look like this: + + (CONFLICT (IO WARNING)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # + or WARNING + + The next step is to set the IO port addresses. The issue + here is that isapnp does not identify all of the ports out + there. Specifically any device that does not have a driver + or module loaded by Linux will not be registered. This + includes older sound cards and network cards. We have + found that the IO port 0x300 is often used even though + isapnp claims that no-one is using those ports. We + recommend that for a single card installation that port + 0x340 (and 0x350) be used. The IO port line should change + from this: + + (IO 0 (SIZE 16) (BASE 0x0300) (CHECK)) + + to this: + + (IO 0 (SIZE 16) (BASE 0x0340) ) + + e4. if you have multiple Quicknet cards, make sure that you do + not have any overlaps. Be especially careful if you are + mixing Internet PhoneJACK and Internet LineJACK cards in + the same system. In these cases we recommend moving the + IO port addresses to the 0x400 block. Please note that on + a few machines the 0x400 series are used. Feel free to + experiment with other addresses. Our cards have been + proven to work using IO addresses of up to 0xFF0. + + e5. the last step is to uncomment the activation line so the + drivers will be associated with the port. This means the + line (immediately below) the IO line should go from this: + + # (ACT Y) + + to this: + + (ACT Y) + + Once you have finished editing the isapnp.conf file you + must submit it into the pnp driverconfigure the cards. + This is done using the following command: + + isapnp isapnp.conf + + If this works you should see a line that identifies the + Quicknet device, the IO port(s) chosen, and a message + "Enabled OK". + + f. if you are loading the module by hand, use insmod. An example +of this would look like this: + + insmod phonedev + insmod ixj dspio=0x320,0x310 xio=0,0x330 + +Then verify the module loaded by running lsmod. If you are not using a +module that matches your kernel version, you may need to "force" the +load using the -f option in the insmod command. + + insmod phonedev + insmod -f ixj dspio=0x320,0x310 xio=0,0x330 + + +If you are using isapnp to autoconfigure your card, then you do NOT +need any of the above, though you need to use depmod to load the +driver, like this: + + depmod ixj + +which will result in the needed drivers getting loaded automatically. + + g. if you are planning on using kerneld to automatically load the +module for you, then you need to edit /etc/conf.modules and add the +following lines: + + options ixj dspio=0x340 xio=0x330 ixjdebug=0 + +If you do this, then when you execute an application that uses the +module kerneld will load the module for you. Note that to do this, +you need to have your kernel set to support kerneld. You can check +for this by looking at /usr/src/linux/.config and you should see this: + + # Loadable module support + # + <snip> + CONFIG_KMOD=y + + h. if you want non-root users to be able to read and write to the +ixj devices (this is a good idea!) you should do the following: + + - decide upon a group name to use and create that group if + needed. Add the user names to that group that you wish to + have access to the device. For example, we typically will + create a group named "ixj" in /etc/group and add all users + to that group that we want to run software that can use the + ixjX devices. + + - change the permissions on the device files, like this: + + chgrp ixj /dev/ixj* + chmod 660 /dev/ixj* + +Once this is done, then non-root users should be able to use the +devices. If you have enabled autoloading of modules, then the user +should be able to open the device and have the module loaded +automatically for them. + + +4.0 Driver Installation problems. + +We have tested these drivers on the 2.2.9, 2.2.10, 2.2.12, and 2.2.13 kernels +and in all cases have eventually been able to get the drivers to load and +run. We have found four types of problems that prevent this from happening. +The problems and solutions are: + + a. A step was missed in the installation. Go back and use section 3 +as a checklist. Many people miss running the ixj_dev_create script and thus +never load the device names into the filesystem. + + b. The kernel is inconsistently linked. We have found this problem in +the Out Of the Box installation of several distributions. The symptoms +are that neither driver will load, and that the unknown symbols include "jiffy" +and "kmalloc". The solution is to recompile both the kernel and the +modules. The command string for the final compile looks like this: + + In the kernel directory: + 1. cp .config /tmp + 2. make mrproper + 3. cp /tmp/.config . + 4. make dep;make clean;make bzImage;make modules;make modules_install + +This rebuilds both the kernel and all the modules and makes sure they all +have the same linkages. This generally solves the problem once the new +kernel is installed and the system rebooted. + + c. The kernel has been patched, then unpatched. This happens when +someone decides to use an earlier kernel after they load a later kernel. +The symptoms are proceeding through all three above steps and still not +being able to load the driver. What has happened is that the generated +header files are out of sync with the kernel itself. The solution is +to recompile (again) using "make mrproper". This will remove and then +regenerate all the necessary header files. Once this is done, then you +need to install and reboot the kernel. We have not seen any problem +loading one of our drivers after this treatment. + +5.0 Known Limitations + +We cannot currently play "dial-tone" and listen for DTMF digits at the +same time using the ISA PhoneJACK. This is a bug in the 8020 DSP chip +used on that product. All other Quicknet products function normally +in this regard. We have a work-around, but it's not done yet. Until +then, if you want dial-tone, you can always play a recorded dial-tone +sound into the audio until you have gathered the DTMF digits. + + + + + + + + + + + + + + + + + diff --git a/Documentation/usb/CREDITS b/Documentation/usb/CREDITS new file mode 100644 index 000000000..04e67607c --- /dev/null +++ b/Documentation/usb/CREDITS @@ -0,0 +1,160 @@ +Credits for the Simple Linux USB Driver: + +The following people have contributed to this code (in alphabetical +order by last name). I'm sure this list should be longer, its +difficult to maintain, add yourself with a patch if desired. + + Alan Cox <alan@lxorguk.ukuu.org.uk> + Johannes Erdfelt <jerdfelt@sventech.com> + ham <ham@unsuave.com> + Bradley M Keryan <keryan@andrew.cmu.edu> + Paul Mackerras <paulus@cs.anu.edu.au> + David E. Nelson <dnelson@jump.net> + Vojtech Pavlik <vojtech@suse.cz> + Gregory P. Smith <greg@electricrain.com> + Linus Torvalds <torvalds@transmeta.com> + Roman Weissgaerber <weissg@vienna.at> + <Kazuki.Yasumatsu@fujixerox.co.jp> + +Special thanks to: + + Inaky Perez Gonzalez <inaky@peloncho.fis.ucm.es> for starting the + Linux USB driver effort and writing much of the larger uusbd driver. + Much has been learned from that effort. + + The NetBSD & FreeBSD USB developers. For being on the Linux USB list + and offering suggestions and sharing implementation experiences. + +Additional thanks to the following companies and people for donations +of hardware, support, time and development (this is from the original +THANKS file in Inaky's driver): + + The following corporations have helped us in the development + of Linux USB / UUSBD: + + - 3Com GmbH for donating a ISDN Pro TA and supporting me + in technical questions and with test equipment. I'd never + expect such a great help. + + - USAR Systems provided us with one of their excellent USB + Evaluation Kits. It allows us to test the Linux-USB driver + for compilance with the latest USB specification. USAR + Systems recognized the importance of an up-to-date open + Operating System and supports this project with + Hardware. Thanks!. + + - Thanks to Intel Corporation for their precious help. + + - We teamed up with Cherry to make Linux the first OS with + built-in USB support. Cherry is one of the biggest keyboard + makers in the world. + + - CMD Technology, Inc. sponsored us kindly donating a CSA-6700 + PCI-to-USB Controller Board to test the OHCI implementation. + + - Due to their support to us, Keytronic can be sure that they + will sell keyboards to some of the 3 million (at least) + Linux users. + + - Many thanks to ing büro h doran [http://www.ibhdoran.com]! + It was almost imposible to get a PC backplate USB connector + for the motherboard here at Europe (mine, home-made, was + quite lowsy :). Now I know where to adquire nice USB stuff! + + - Genius Germany donated a USB mouse to test the mouse boot + protocol. They've also donated a F-23 digital joystick and a + NetMouse Pro. Thanks! + + - AVM GmbH Berlin is supporting the development of the Linux + USB driver for the AVM ISDN Controller B1 USB. AVM is a + leading manufacturer for active and passive ISDN Controllers + and CAPI 2.0-based software. The active design of the AVM B1 + is open for all OS platforms, including Linux. + + - Thanks to Y-E Data, Inc. for donating their FlashBuster-U + USB Floppy Disk Drive, so we could test the bulk transfer + code. + + - Many thanks to Logitech for contributing a three axis USB + mouse. + + Logitech designs, manufactures and markets + Human Interface Devices, having a long history and + experience in making devices such as keyboards, mice, + trackballs, cameras, loudspeakers and control devices for + gaming and professional use. + + Being a recognized vendor and seller for all these devices, + they have donated USB mice, a joystick and a scanner, as a + way to acknowledge the importance of Linux and to allow + Logitech customers to enjoy support in their favorite + operating systems and all Linux users to use Logitech and + other USB hardware. + + Logitech is official sponsor of the Linux Conference on + Feb. 11th 1999 in Vienna, where we'll will present the + current state of the Linux USB effort. + + - CATC has provided means to uncover dark corners of the UHCI + inner workings with a USB Inspector. + + - Thanks to Entrega for providing PCI to USB cards, hubs and + converter products for development. + + + And thanks go to (hey! in no particular order :) + + - Oren Tirosh <orenti@hishome.net>, for standing so patiently + all my doubts'bout USB and giving lots of cool ideas. + + - Jochen Karrer <karrer@wpfd25.physik.uni-wuerzburg.de>, for + pointing out mortal bugs and giving advice. + + - Edmund Humemberger <ed@atnet.at>, for it's great work on + public relationships and general management stuff for the + Linux-USB effort. + + - Alberto Menegazzi <flash@flash.iol.it> is starting the + documentation for the UUSBD. Go for it! + + - Ric Klaren <ia_ric@cs.utwente.nl> for doing nice + introductory documents (compiting with Alberto's :). + + - Christian Groessler <cpg@aladdin.de>, for it's help on those + itchy bits ... :) + + - Paul MacKerras for polishing OHCI and pushing me harder for + the iMac support, giving improvements and enhancements. + + - Fernando Herrera <fherrera@eurielec.etsit.upm.es> has taken + charge of composing, maintaining and feeding the + long-awaited, unique and marvelous UUSBD FAQ! Tadaaaa!!! + + - Rasca Gmelch <thron@gmx.de> has revived the raw driver and + pointed bugs, as well as started the uusbd-utils package. + + - Peter Dettori <dettori@ozy.dec.com> is unconvering bugs like + crazy, as well as making cool suggestions, great :) + + - All the Free Software and Linux community, the FSF & the GNU + project, the MIT X consortium, the TeX people ... everyone! + You know who you are! + + - Big thanks to Richard Stallman for creating Emacs! + + - The people at the linux-usb mailing list, for reading so + many messages :) Ok, no more kidding; for all your advices! + + - All the people at the USB Implementors Forum for their + help and assistance. + + - Nathan Myers <ncm@cantrip.org>, for his advice! (hope you + liked Cibeles' party). + + - Linus Torvalds, for starting, developing and managing Linux. + + - Mike Smith, Craig Keithley, Thierry Giron and Janet Schank + for convincing me USB Standard hubs are not that standard + and that's good to allow for vendor specific quirks on the + standard hub driver. + diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt new file mode 100644 index 000000000..67cb9e31f --- /dev/null +++ b/Documentation/usb/URB.txt @@ -0,0 +1,196 @@ +1. Specification of the API + +1.1. Basic concept or 'What is an URB?' + +The basic idea of the new driver is message passing, the message itself is +called USB Request Block, or URB for short. + +- An URB consists of all relevant information to execute any USB transaction +and deliver the data and status back. + +- Execution of an URB is an inherently asynchronous operation, i.e. the +submit_urb(urb) call returns immediately after it has successfully queued +the requested action. + +- Ongoing transfers for one URB (e.g. ISO) can simply be canceled with +unlink_urb(urb) at any time. + +- Each URB has a completion handler, which is called after the action +has been successfully completed or canceled (INT transfers behave a bit +different, see below). The URB also contains a context-pointer for free +usage and information passing to the completion handler. + +- URBs can be linked. After completing one URB, the next one can be +automatically submitted. This is especially useful for ISO transfers: +You only have read/write the data from/to the buffers in the completion +handler, the continous streaming itself is transparently done by the +URB-machinery. + +1.2. The URB structure + +typedef struct urb +{ +// ignore, for host controller/URB machine internal use + void *hcpriv; // private data for host controller + struct list_head urb_list; // list pointer to all active urbs + +// This is used for urb linking + struct urb* next; // pointer to next URB + struct usb_device *dev; // pointer to associated USB device + +// pipe is assembled by the various well known pipe-macros in usb.h + unsigned int pipe; // pipe information + +// status after each completion + int status; // returned status + unsigned int transfer_flags; // ASAP, SP_OK, EARLY_COMPLETE + +// for data stage (CTRL), BULK, INT and ISO + void *transfer_buffer; // associated data buffer + +// expected length + int transfer_buffer_length; // data buffer length + int actual_length; // actual data buffer length + +// setup stage for CTRL (always 8 bytes!) + unsigned char* setup_packet; // setup packet (control only) + +// with ASAP, start_frame is set to the determined frame + int start_frame; // start frame (iso/irq) + int number_of_packets; // # of packets (iso/int) + int interval; // polling interval (irq only) + int error_count; // number of errors (iso only) + // + void *context; // context for completion routine + usb_complete_t complete; // pointer to completion routine + // +// specification of the requested data offsets and length for ISO + iso_packet_descriptor_t iso_frame_desc[0]; +} urb_t, *purb_t; + +1.3. How to get an URB? + +URBs are allocated with the following call + + purb_t alloc_urb(int isoframes) + +Return value is a pointer to the allocated URB, 0 if allocation failed. +The parameter isoframes specifies the number of isochronous transfer frames +you want to schedule. For CTRL/BULK/INT, use 0. + +To free an URB, use + + void free_urb(purb_t purb) + +This call also may free internal (host controller specific) memory in the +future. + +1.4. What has to be filled in? + +Depending on the type of transaction, there are some macros +(FILL_CONTROL_URB, FILL_BULK_URB, and FILL_INT_URB, defined in uhci.h) +that simplify the URB creation. In general, all macros need the usb +device pointer, the pipe (usual format), the transfer buffer, the +desired transfer length, the completion handler, and its context. +Take a look at the uhci_control_msg-function that convert the old API +into an URB. + +Flags: +For ISO there are two startup behaviors: Specified start_frame or ASAP. +For ASAP set USB_ISO_ASAP in transfer_flags. + +If short packets should NOT be tolerated, set USB_DISABLE_SPD in +transfer_flags. + +Usually, (to reduce restart time) the completion handler is called +AFTER the URB re-submission. You can get the other way by setting +USB_URB_EARLY_COMPLETE in transfer_flags. This is implicite for +INT transfers. + +1.5. How to submit an URB? + +Just call + + int submit_urb(purb_t purb) + +It immediately returns, either with status 0 (request queued) or some +error code, usually caused by the following: + +- Out of memory (-ENOMEM) +- Wrong pipe handle (-ENXIO) +- Unplugged device (-ENODEV) +- Stalled endpoint (-EPIPE) +- Too many queued ISO transfers (-EAGAIN) +- Too many requested ISO frames (-EFBIG) +- Invalid INT interval (-EINVAL) +- More than one packet for INT (-EINVAL) + +After submission, urb->status is USB_ST_URB_PENDING. + +For isochronous endpoints, subsequent submitting of URBs to the same endpoint +with the ASAP flag result in a seamless ISO streaming. Exception: The +execution cannot be scheduled later than 900 frames from the 'now'-time. +The same applies to INT transfers, but here the seamless continuation is +independent of the transfer flags (implicitely ASAP). + +1.6. How to cancel an already running URB? + +Call + int unlink_urb(purb_t purb) + +It removes the urb from the internal list and frees all allocated +HW descriptors. The status is changed to USB_ST_URB_KILLED. After +unlink_urb() returns, you can safely free the URB with free_urb(urb) +and all other possibly associated data (urb->context etc.) + +1.7. What about the completion handler? + +The completion handler is optional, but useful for fast data processing +or wakeup of a sleeping process (as shown in the compatibility wrapper's +completion handler). + +The handler is of the following type: + + typedef void (*usb_complete_t)(struct urb *); + +i.e. it gets just the URB that caused the completion call. +In the completion handler, you should have a look at urb->status to +detect any USB errors. Since the context parameter is included in the URB, +you can pass information to the completion handler. + + +1.8. How to do isochronous (ISO) transfers? + +For ISO transfers you have to append the iso_packet_descriptor_t structure +to the URB for each frame you want to schedule. When using alloc_urb(n) +(recommended), the isoframe-parameter n can be used to allocate the +structures for n frames. + +For each entry you have to specify the data offset for this frame (base is +transfer_buffer), and the length you want to write/expect to read. +After completion, actual_length contains the actual transfered length and +status contains the resulting USB-status for the ISO transfer for this frame. +It is allowed to specify a varying length from frame to frame (e.g. for +audio synchronisation/adaptive transfer rates). You can also use the length +0 to omit one or more frames (striping). + +As can be concluded from above, the UHCI-driver does not care for continous +data in case of short packet ISO reads! There's no fixup_isoc() like in the +old driver. There may be a common routine to do this in the future, but this +has nothing to do with the UHCI-driver! + +For scheduling you can choose your own start frame or ASAP. As written above, +queuing more than one ISO frame with ASAP to the same device&endpoint result +in seamless ISO streaming. For continous streaming you have to use URB +linking. + +1.9. How to start interrupt (INT) transfers? + +INT transfers are currently implemented with 8 different queues for intervals +for 1, 2, 4,... 128ms. Only one TD is allocated for each interrupt. After +calling the completion handler, the TD is recycled. +With the submission of one URB, the interrupt is scheduled until it is +canceled by unlink_urb. + +The submit_urb()-call modifies urb->interval to the rounded value. + diff --git a/Documentation/usb/acm.txt b/Documentation/usb/acm.txt new file mode 100644 index 000000000..c978974f1 --- /dev/null +++ b/Documentation/usb/acm.txt @@ -0,0 +1,94 @@ +The ACM driver works with modems and ISDN TAs that use the USB Abstract +Control Model standard. + +**************************** +Test it: +Watch out, the driver is not stable and tested. Sync often, make backups, +most importand: don't blame me... + +Create device files: +mknod /dev/ttyACM0 c 166 0 +mknod /dev/ttyACM1 c 166 1 +mknod /dev/ttyACM2 c 166 2 +mknod /dev/ttyACM3 c 166 3 +Compile a kernel with support for your host controller (uhci only for now!) +and support for ACM. Boot this kernel. If you connect your device to the +USB bus you should see messages like the following: + +Jul 19 20:14:29 office kernel: USB new device connect, assigned device number 1 +Jul 19 20:14:29 office kernel: Found 02:09 +Jul 19 20:14:29 office kernel: Found 04:09 +Jul 19 20:14:29 office kernel: Found 05:07 +Jul 19 20:14:29 office last message repeated 2 times +Jul 19 20:14:29 office kernel: parsed = 39 len = 67 +Jul 19 20:14:29 office kernel: Expected descriptor 04/09, got 02/09 - skipping +Jul 19 20:14:29 office kernel: 0 09 +Jul 19 20:14:29 office kernel: 1 02 +Jul 19 20:14:29 office kernel: 2 43 +Jul 19 20:14:29 office kernel: 3 00 +Jul 19 20:14:29 office kernel: 4 02 +Jul 19 20:14:29 office kernel: 5 02 +Jul 19 20:14:29 office kernel: 6 04 +Jul 19 20:14:29 office kernel: 7 60 +Jul 19 20:14:29 office kernel: 8 00 +Jul 19 20:14:29 office kernel: Found 04:09 +Jul 19 20:14:29 office kernel: Found 02:09 +Jul 19 20:14:29 office kernel: Found 04:09 +Jul 19 20:14:29 office kernel: Found 05:07 +Jul 19 20:14:29 office kernel: Found 04:09 +Jul 19 20:14:29 office kernel: Found 05:07 +Jul 19 20:14:29 office kernel: Found 05:07 +Jul 19 20:14:29 office kernel: parsed = 67 len = 0 +Jul 19 20:14:29 office kernel: getstringtable +Jul 19 20:14:29 office kernel: acm_probe +Jul 19 20:14:29 office kernel: USB ACM found + +Watch out for the line: +Jul 19 20:14:29 office kernel: USB new device connect, assigned device number 1 +and the line: +Jul 19 20:14:29 office kernel: USB ACM found +These two lines show that the device was seen by the usb host controller and +then recognized by the acm driver as a valid device. + +If you use a terminal emulation software like minicom with /dev/ttyACM0 you +should be able to send AT commands to your device and get responses. I've +been able to do zmodem downloads to another pc. However downloads from one +ISDN TA to another ISDN TA connected to the same PC didn't work. Don't +know why. Flow control is not finised after all and i'd guess there might +be problems on heavily loades PCs. I also did some tests with ppp but i'm +not finised with this. There might be a chance to get it working. However +i'd like to know if your device is recognized as an ACM device. I'm also +interested if the thing is stable or if it crashes. +(should i say how it crases?) + +You should be able to add and remove devices from the bus. The driver will +always try to fill up unused ttys. This means if you hotplug devices their +order may have changed after reboot. This is not the behaviour Linus liked +to see but it's ok for now. (I hope ;-) + +Please report your experiences to me: +fuerst@in.tum.de + +*************************** +I've tested it with: +3Com ISDN Pro TA. + +It should work with (That means i know these devices conform to ACM): +3Com Office Connect Modem +3Com Sportster USB (I think that's what it's called) + +*************************** +Many thanks to 3Com which did not only support me with hardware but also +with technical support in USB questions. They also allowed me to do tests in +their lab. Great! + +*************************** +Known bugs: +Flow control not tested (likely not to work) +Some tty function calls not implemented (putchar, etc...) +Huge amounts of debug output (compile in [*] Magic SysRq key and press ALT+PRTSCR+0 ) +Not all mem is freed at close (need terminate irq in hcd) + +*************************** +Have fun, + Armin Fuerst diff --git a/Documentation/usb/dc2xx.txt b/Documentation/usb/dc2xx.txt new file mode 100644 index 000000000..25b024123 --- /dev/null +++ b/Documentation/usb/dc2xx.txt @@ -0,0 +1,110 @@ +13 November 1999 +david-b@pacbell.net + +This is an overview of how to use the "dc2xx" USB driver with certain +digital still cameras from Kodak and other vendors. + + +CAMERAS + +This driver will mostly be used with Kodak DC-2xx series digital still +cameras, but it should be trivial to tell it about several non-Kodak +USB-enabled cameras. + +You'll most likely want to hook it up to recent versions of "gPhoto" +(www.gphoto.org), since version 0.4 and later know how to use it to talk +to Kodak DC-240 and DC-280 cameras over USB. + +In addition the DC-260, DC-265, and DC-290 are currently recognized. +However, like other cameras using the "Digita OS" (from www.flashpoint.com) +there is no gPhoto support for this camera. At this writing the best +known support for these cameras is a Python script that supports image +downloading from those cameras. (See archives of the linux-usb mailing +list.) The DC-220 should also work with this driver, given information +about the USB product IDs. When it becomes available, the HP PhotoSmart +C500 should also work ... it's another Digita OS camera with USB support.) + +It's likely that other digital still cameras can also use this USB driver, +even if they're not from Kodak and don't use Digita. The reason is that +most currently known USB still camera protocols treat USB like a faster +packet-carrying connection than a serial line, which is exactly how this +driver looks to an application. + + +USB HARDWARE + +This has been shown to work on x86 OHCI and UHCI (Intel) chipsets. OHCI has +been trouble free; not so with UHCI, which was first seen to be happy with +2.3.24 kernels, and has not been as fast as OHCI. + +Note that in some cases changes in BIOS settings may be needed before +your USB works. At least one user has reported a need for SMP-related +settings as well. + +As yet, no reports have come from Linux users on non-Intel hardware. +(You could color coordinate your iMac with a DC-240i ... :-) + + +SETUP + +Configure in the DC2XX USB driver, and have it in your kernel. Recently I +compile it right in, but I've done it as a module in the past. + +Create a device, perhaps like this (both read and write): + + # mknod -m 0666 /dev/kodak c 10 170 + +That "170" is not formally assigned, and this command may change. If you're +using a non-Kodak camera, you may prefer another name. + +Don't plug in more than one compatible camera at this time. One of them +will be ignored, but I'd not be sure which one! + + +SANITY TESTING + +First: if you've got /proc support, make sure that the driver has hooked +itself up correctly. + + - you should see an entry in /proc/misc for the a Kodak DC-2xx + minor device number + + - you should see an entry in /proc/bus/usb/drivers for "dc2xx", + if you also enabled USB /proc support. + +Second: when you connect your camera to the computer, does it get recognized +by the driver? + + - if you've got /proc/bus/usb/devices, you should see an entry + something like this. The "ProdID" may be different if you didn't + plug in a DC-240, but the "Driver=dc2xx" had better be there. + + T: Lev=01 Prnt=00 Port=00 Cnt=01 Dev#= 1 Spd=12 MxCh= 0 + D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 + P: Vendor=040a ProdID=0120 Rev= 1.08 + C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA + I: If#= 0 Alt= 0 #EPs= 2 Cls=00(>ifc ) Sub=00 Prot=00 Driver=dc2xx + E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms + + - if you don't have /proc support for USB, see if "dmesg" output + tells you that you plugged in your camera. + + USB new device connect, assigned device number 1 + Manufacturer: Eastman Kodak Company + Product: KODAK DC240 Zoom Digital Camera + USB Camera is connected + usbcore: dc2xx driver claimed interface c3a68600 + ohci-control thread sleeping + +Third: (optional) can you use gPhoto to talk to the camera? + + - When you configure your camera, tell it to use "/dev/kodak" (or + whatever name you used). Right now, gPhoto emits a diagnostic + message (non-GUI) saying that it since it didn't act like a TTY, + it's assuming it's got a USB connection. + + - With the camera turned on, get the "camera summary". It'll + talk to the camera -- and tell you you're using USB. + +If you got that far, you should be able to use everything fine. diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt new file mode 100644 index 000000000..836661375 --- /dev/null +++ b/Documentation/usb/error-codes.txt @@ -0,0 +1,108 @@ +$Id: README.error-codes,v 1.1 1999/12/14 14:03:02 fliegl Exp $ + +This is the documentation of (hopefully) all possible error codes (and +their interpretation) that can be returned from the hostcontroller driver +and from usbcore. + +NOTE: +The USB_ST_* codes are deferred and are only listed for compatibility, new +software should use only -E* instead! + + + +************************************************************************** +* Error codes returned by usb_submit_urb * +************************************************************************** + +Non-USB-specific: + +USB_ST_NOERROR +0 URB submission went fine + +-ENOMEM no memory for allocation of internal structures + +USB-specific: + +-ENODEV specified USB-device or bus doesn't exist + +-ENXIO specified endpoint doesn't exist on the device + +USB_ST_URB_INVALID_ERROR +-EINVAL a) Invalid transfer type specified (or not supported) + b) Invalid interrupt interval (0<=n<256) + c) more than one interrupt packet requested + +-EAGAIN a) specified ISO start frame too early + b) (using ISO-ASAP) too much scheduled for the future + wait some time and try again. + +-EFBIG too much ISO frames requested (currently uhci>900) + +-EPIPE specified pipe-handle is already stalled + +-EMSGSIZE endpoint message size is zero, do interface/alternate setting + + +************************************************************************** +* Error codes returned by in urb->status * +* or in iso_frame_desc[n].status (for ISO) * +************************************************************************** + +USB_ST_NOERROR +0 Transfer completed successfully + +USB_ST_URB_KILLED +-ENOENT URB was canceled by unlink_urb + +USB_ST_URB_PENDING +-EINPROGRESS URB still pending, no results yet + (actually no error until now;-) + +USB_ST_BITSTUFF +USB_ST_INTERNALERROR +-EPROTO a) bitstuff error + b) unknown USB error + +USB_ST_CRC +-EILSEQ CRC mismatch + +-EPIPE a) babble detect + b) endpoint stalled + +USB_ST_BUFFERUNDERRUN +-ENOST buffer error + +USB_ST_NORESPONSE +USB_ST_TIMEOUT +-ETIMEDOUT transfer timed out, NAK + +USB_ST_REMOVED +-ENODEV device was removed + +USB_ST_SHORT_PACKET +-EREMOTEIO short packet detected + +USB_ST_PARTIAL_ERROR +-EXDEV ISO transfer only partially completed + look at individual frame status for details + +USB_ST_URB_INVALID_ERROR +-EINVAL ISO madness, if this happens: Log off and go home + +************************************************************************** +* Error codes returned by usbcore-functions * +* (expect also other submit and transfer status codes) * +************************************************************************** + +usb_register(): +USB_ST_NOTSUPPORTED +-EINVAL error during registering new driver + +usb_terminate_bulk(): +USB_ST_REMOVED +-ENODEV urb already removed + +usb_get_*/usb_set_*(): + All USB errors (submit/status) can occur + + diff --git a/Documentation/usb/hid.txt b/Documentation/usb/hid.txt new file mode 100644 index 000000000..3cd3373ff --- /dev/null +++ b/Documentation/usb/hid.txt @@ -0,0 +1,162 @@ + Linux HID driver v0.8 + (c) 1999 Vojtech Pavlik <vojtech@suse.cz> + (c) 1999 Andreas Gal <agal@uwsp.edu> + Sponsored by SuSE +---------------------------------------------------------------------------- + +0. Disclaimer +~~~~~~~~~~~~~ + 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 the Free +Software Foundation; either version 2 of the License, or (at your option) +any later version. + + This program is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +more details. + + You should have received a copy of the GNU General Public License along +with this program; if not, write to the Free Software Foundation, Inc., 59 +Temple Place, Suite 330, Boston, MA 02111-1307 USA + + Should you need to contact me, the author, you can do so either by e-mail +- mail your message to <vojtech@suse.cz>, or by paper mail: Vojtech Pavlik, +Ucitelska 1576, Prague 8, 182 00 Czech Republic + + For your convenience, the GNU General Public License version 2 is included +in the package: See the file COPYING. + +1. Introduction +~~~~~~~~~~~~~~~ + This is a driver for USB devices conforming to the USB HID (Human Input +Device) standard. These devices include namely keyboards, mice and +joysticks. + + However many other devices (monitors, speakers, UPSs ...) also communicate +through the same protocol, which makes its specification somewhat bloated. +This isn't a problem, though, because the driver doesn't need to know about +all the possible devices it can control, and can just parse the protocol and +leave the rest of the job (for example understanding what the UPS wants to +say) to the userland. + + Because of this, the USB HID driver has two interfaces. One is via the +proc filesystem, allowing userland applications send and read arbitrary +reports to and from a connected USB device. The other is via a very simple +yet generic input device driver, which dispatches input events (keystrokes, +mouse or joystick movements) to specific, backward compatible userland +interfaces. This way a PS/2 mouse, an AT keyboard or a Linux joystick driver +interface are emulated, and allow applications to immediately work with USB +mice, USB keyboards and USB joysticks without any changes. + + The input driver is aimed for a little more than USB device handling in +the future, though. It's generic enough so that it can be used for any +mouse, keyboard or joystick (and more, of course). A PS/2 mouse driver, a +serial mouse, Sun mouse, and most of the busmouse drivers were rewritten to +use this as well as the AT keyboard and Sun keyboard drivers. This will +hopefully allow conversion of all Linux keyboard and mouse and joystick +drivers to this scheme. + + This effort has it's home page at: + + http://www.suse.cz/development/input/ + +You'll find both the latest HID driver and the complete Input driver there. +There is also a mailing list for this: + + listproc@atrey.karlin.mff.cuni.cz + +Send "subscribe linux-joystick Your Name" to subscribe to it. + +2. Usage +~~~~~~~~ + Since the driver comes with recent 2.3 kernels, all that's needed to use +it is to enable it either as a module or compiled-in into the kernel. + + After that, after reboot (and possibly also inserting the USB and HID +modules) the following will happen: + +* If you selected keyboard support, all USB keystrokes will be also routed + to the Linux keyboard driver as if being input through the ordinary system + keyboard. + +* If you selected mouse support, there will be (one or more) simulated PS/2 + mouse devices on major 10, minor 32, 33 and more. These simulated mice can + in addition to a standard 3-button PS/2 mouse behave like MS Intellimice, + with a wheel. If you want to use the wheel, just specify '-t imps2' to gpm + and 'Protocol "ImPS/2"' to X, and it will work. A single emulated mouse + device can be open by any number of processes (unlike the /dev/psaux), and + for each of them the emulation is separate, each can use a different mode. + The mousedev driver, which emulates the mice, can also emulate a Genius + NewScroll 5 buttons-and-a-wheel mouse, if you set it to a Genius PS/2 + mode ('-t netmouse' 'Protocol "NetMousePS/2"'). However, not gpm, nor X + can decode the 5 buttons yet, so this isn't very useful right now. + +* If you selected joystick support, the driver will take over major 15, the + joystick major number, and will emulate joysticks on it. This means the + normal joystick driver can't be used together with it (now, after the + normal joystick drivers are converted to the input scheme, all will work + nicely together). Also, you'll probably need to calibrate your joystick + manually ('man jscal') to be able to use it, because the USB + autocalibration is far from perfect yet. + +* If you selected event device support, there will be devices on major 10, + minors 64, 65 and more for each input device connected through this + driver. These devices output raw events the input driver dispatches. Each + has a timestamp. This hopefully will be THE way X will talk to keyboard + and mice, because it's hardware independent, and not limited by existing + de-facto standards. + +3. Verifying if it works +~~~~~~~~~~~~~~~~~~~~~~~~ + Typing a couple keys on the keyboard should be enough to check that a USB +keyboard works and is correctly connected to the kernel keyboard driver. + + Doing a cat /dev/hidmouse (c, 10, 32) will verify that a mouse is also +emulated, characters should appear if you move it. + + You can test the joystick emulation with the 'jstest' utility, available +in the joystick package (see Documentation/joystick.txt). + + You can test the event devics with the 'evtest' utitily available on the +input driver homepage (see the URL above). + +4. FAQ +~~~~~~ +Q: Why aren't any questions here yet? +A: Because none were frequent enough yet. + +5. Event interface +~~~~~~~~~~~~~~~~~~ + Should you want to add event device support into any application (X, gpm, +svgalib ...) I (vojtech@suse.cz) will be happy to provide you any help I +can. Here goes a description of the current state of things, which is going +to be extended, but not changed incompatibly as time goes: + + You can use blocking and nonblocking reads, also select() on the +/dev/inputX devices, and you'll always get a whole number of input events on +a read. Their layout is: + +struct input_event { + struct timeval time; + unsigned short type; + unsigned short code; + unsigned int value; +}; + + 'time' is the timestamp, it returns the time at which the event happened. +Type is for example EV_REL for relative momement, REL_KEY for a keypress or +release. More types are defined in include/linux/input.h. + + 'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete +list is in include/linux/input.h. + + 'value' is the value the event carries. Either a relative change for +EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for +release, 1 for keypress and 2 for autorepeat. + +6. Proc interface +~~~~~~~~~~~~~~~~~ + For HID-specific devices there is also the /proc interface. It isn't +present in this release yet, though, so it's description will appear here +together with the code in the driver. diff --git a/Documentation/usb/ohci-hcd.txt b/Documentation/usb/ohci-hcd.txt new file mode 100644 index 000000000..37a637251 --- /dev/null +++ b/Documentation/usb/ohci-hcd.txt @@ -0,0 +1,98 @@ + +The OHCI HCD layer is a simple but nearly complete implementation of what the +USB people would call a HCD for the OHCI. + (ISO comming soon, Bulk, INT u. CTRL transfers enabled) +It is based on Linus Torvalds UHCI code and Gregory Smith OHCI fragments (0.03 source tree). +The layer (functions) on top of it, is for interfacing to the alternate-usb device-drivers. + +- Roman Weissgaerber <weissg@vienna.at> + + * v4.0 1999/08/18 removed all dummy eds, unlink unused eds, code cleanup, bulk transfers + * v2.1 1999/05/09 ep_addr correction, code cleanup + * v0.2.0 1999/05/04 + * everything has been moved into 2 files (ohci-hcd.c, ohci-hub-root.c and headers) + * virtual root hub is now an option, + * memory allocation based on kmalloc and kfree now, simple Bus error handling, + * INT and CTRL transfers enabled, Bulk included but disabled, ISO needs completion + * + * from Linus Torvalds (uhci.c): APM (not tested); hub, usb_device, bus and related stuff + * from Greg Smith (ohci.c): better reset ohci-controller handling, hub + * + * v0.1.0 1999/04/27 initial release + +to remove the module try: +rmmod usb-ohci-hcd + +Features: +- virtual root hub, all basic hub descriptors and commands (state: complete) + this is an option now (v0.2.0) + #define CONFIG_USB_OHCI_VROOTHUB includes the virtual hub code, (VROOTHUB) + default is with. + (at the moment: the Virtual Root Hub is included automatically) + + files: ohci-root-hub.c, ohci-root-hub.h + + +- Endpoint Descriptor (ED) handling more static approach + (EDs should be allocated in parallel to the SET CONFIGURATION command and they live + as long as the function (device) is alive or another configuration is choosen. + In the HCD layer the EDs has to be allocated manually either by calling a subroutine + or by sending a USB root hub vendor specific command to the virtual root hub. + At the alternate linux usb stack EDs will be added (allocated) at their first use. + ED will be unlinked from the HC chains if they are not bussy. + + files: ohci-hcd.c ohci-hcd.h + routines: (do not use for drivers, use the top layer alternate usb commands instead) + + int usb_ohci_add_ep(struct ohci * ohci, unsigned int ep_addr1, + int interval, int load, f_handler handler, int ep_size, int speed) + adds an endpoint, (if the endpoint already exists some parameters will be updated) + + int usb_ohci_rm_ep( ) + removes an endpoint and all pending TDs of that EP + + usb_ohci_rm_function( ) + removes all Endpoints of a function (device) + +- Transfer Descriptors (TD): handling and allocation of TDs is transparent to the upper layers + The HCD takes care of TDs and EDs memory allocation whereas the upper layers (UBSD ...) has + to take care of buffer allocation. + files: ohci-hcd.c ohci-hcd.h + + There is one basic command for all types of bus transfers (INT, BULK, ISO, CTRL): + + int ohci_trans_req(struct ohci * ohci, hcd_ed, int ctrl_len, void *ctrl, void * data, int data_len, __OHCI_BAG lw0, __OHCI_BAG lw1) + + CTRL: ctrl, ctrl_len ... cmd buffer + data, data_len ... data buffer (in or out) + INT, BULK: ctrl = NULL, ctrl_len=0, + data, data_len ... data buffer (in or out) + ISO: tbd + + There is no buffer reinsertion done by the internal HCD function. + (The interface layer does this for a INT-pipe on request.) + If you want a transfer then you have to + provide buffers by sending ohci_trans_req requests. As they are queued as TDs on an ED + you can send as many as you like. They should come back by the callback f_handler in + the same order (for each endpoint, not globally) If an error occurs all + queued transfers of an endpoint will return unsent. They will be marked with an error status. + + e.g double-buffering for int transfers: + + ohci_trans_req(ohci, ep_addr, 0, NULL, data0, data0_len, 0,0) + ohci_trans_req(ohci, ep_addr, 0, NULL, data1, data1_len, 0,0) + + and when a data0 packet returns by the callback f_handler requeue it: + ohci_trans_req(ohci, ep_addr, 0, NULL, data0, data0_len, 0,0) + and when a data1 packet returns by the callback f_handler requeue it: + ohci_trans_req(ohci, ep_addr, 0, NULL, data1, data1_len, 0,0) + + lw0, lw1 are private fields for upper layers for ids or fine grained handlers. + The alternate usb uses them for dev_id and usb_device_irq handler. + + +- Done list handling: returns the requests (callback f_handler in ED) and does + some error handling, root-hub request dequeuing + (files: ohci-done-list.c in ohci-hcd.c now(v0.2.0)) + + diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt new file mode 100644 index 000000000..14163ae87 --- /dev/null +++ b/Documentation/usb/ov511.txt @@ -0,0 +1,70 @@ +------------------------------------------------------------------------------- +Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC +------------------------------------------------------------------------------- + +INTRODUCTION: + +This is a preliminary version of my OV511 Linux device driver. At the moment, +it does not do much more than detect the chip and initialize it. As trivial +as this sounds, it represents many hours of my work. Since OmniVision refused +to release the full specs to me, I had to write code to probe out the register +read/write commands. Some code is in place to allow a frame to be grabbed, but +it is nowhere near complete. + +SUPPORTED CAMERAS: +____________________________________________ +Manufacturer | Model | Custom ID +-----------------+--------------+----------- +D-Link | DSB-C300 | 3 +Creative Labs | WebCam 3 | 21 +-------------------------------------------- + +Any camera using the OV511 and the OV7610 CCD should work with this driver. The +driver only detects known cameras though, based on their custom id number. If +you have a currently unsupported camera, the ID number should be reported to you +in the kernel logs. If you have an unsupported camera, please send me the model, +manufacturer and ID number and I will add it to the detection code. In the +meantime, you can add to the code yourself in the function ov511_probe() + +WHAT YOU NEED: + +- If you want to help with the development, get the chip's specification docs at + http://www.ovt.com/omniusbp.html + +- A Video4Linux compatible frame grabber program (I recommend vidcat) + (see: http://www.exploits.org/v4l/ ) + +WHAT NEEDS TO BE DONE: + +In short, a lot. + +UPDATE: +Currently, the control messages are working fine ("vendor commands"; for +reading and writing the OV511 registers.) The I2C bus commands for reading and +writing the camera (OV7610) registers are implemented and working, with at least +one person's camera. The isochronous-in endpoint for video data is finally +producing data, but since ov511_parse_data() is not implemented you will not see +a picture yet. + +Support for specific CCD's will have to be implemented as well (such as the +OV7610.) + +The rest of the work will involve implementing support for all the different +resolutions, color depths, etc. Also, while support for the OV511's proprietary +lossy compression is apparently not necessary (the code currently disables it,) +it would be a nice addition as it improves performance quite a bit. OmniVision +wouldn't tell me how the algorithm works, so we can't really work on that yet. +Please kindly inform OmniVision that you would like them to release their +specifications to the Linux community. + +HOW TO CONTACT ME: + +You can email me at mmcclelland@delphi.com . Please prefix the subject line +with "OV511: " so that I am certain to notice your message. + +CREDITS: + +The code is based in no small part on the CPiA driver by Johannes Erdfelt, +Randy Dunlap, and others. Big thanks to them for their pioneering work on that +and the USB stack. Thanks to Bret Wallach for getting camera reg IO and ISOC +working. diff --git a/Documentation/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index e3c705581..8d1066a9f 100644 --- a/Documentation/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt @@ -1,6 +1,6 @@ /proc/bus/usb filesystem output =============================== -(version 19990722) +(version 19991218) The /proc filesystem for USB devices generates @@ -22,9 +22,11 @@ different topo/connections and it looked possible.) Each line is tagged with a one-character ID for that line: T = Topology (etc.) +B = Bandwidth D = Device descriptor info. P = Product ID info. (from Device descriptor, but they won't fit together on one line) +S = String info C = Configuration descriptor info. (* = active configuration) I = Interface descriptor info. E = Endpoint descriptor info. @@ -41,19 +43,26 @@ Legend: Topology info: -T: Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd If#=ddd MxCh=dd Driver=%s -| | | | | | | | | |__DriverName -| | | | | | | | |__MaxChildren -| | | | | | | |__Configured InterfaceNumber -| | | | | | |__Device Speed in Mbps -| | | | | |__DeviceNumber -| | | | |__Count of devices at this level -| | | |__Connector/Port on Parent for this device -| | |__Parent DeviceNumber -| |__Level in topology +T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd +| | | | | | | | |__MaxChildren +| | | | | | | |__Device Speed in Mbps +| | | | | | |__DeviceNumber +| | | | | |__Count of devices at this level +| | | | |__Connector/Port on Parent for this device +| | | |__Parent DeviceNumber +| | |__Level in topology for this bus +| |__Bus number |__Topology info tag +Bandwidth info: +B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd +| | | |__Number if isochronous requests +| | |__Number of interrupt requests +| |__Total Bandwidth allocated to this bus +|__Bandwidth info tag + + Device descriptor info & Product ID info: D: Ver=x.xx Cls=xx(s) Sub=xx Prot=xx MxPS=dd #Cfgs=dd @@ -77,6 +86,17 @@ P: Vendor=xxxx ProdID=xxxx Rev=xx.xx |__Device info tag #2 +String descriptor info: + +S: Manufacturer=ssss +| |__Manufacturer of this device as read from the device. +|__String info tag + +S: Product=ssss +| |__Product description of this device as read from the device. +|__String info tag + + Configuration descriptor info: C: #Ifs=dd Cfg#=dd Atr=xx MPwr=dddmA @@ -89,7 +109,8 @@ C: #Ifs=dd Cfg#=dd Atr=xx MPwr=dddmA Interface descriptor info (can be multiple per Config): -I: If#=dd Alt=dd #EPs=dd Cls=xx(sssss) Sub=xx Prot=xx +I: If#=dd Alt=dd #EPs=dd Cls=xx(sssss) Sub=xx Prot=xx Driver=ssss +| | | | | | | |__Driver name | | | | | | |__InterfaceProtocol | | | | | |__InterfaceSubClass | | | | |__InterfaceClass @@ -103,8 +124,8 @@ Endpoint descriptor info (can be multiple per Interface): E: Ad=xx(s) Atr=xx(ssss) MxPS=dddd Ivl=dddms E: Ad=xx(s) Atr=xx(ssss) MxPS=dddd Ivl=dddms -| | | | |__Interval -| | | |__EndpointMaxPacketSize +| | | | |__Interval +| | | |__EndpointMaxPacketSize | | |__Attributes(EndpointType) | |__EndpointAddress(I=In,O=Out) |__Endpoint info tag @@ -128,6 +149,9 @@ The Topology lines can be used to generate a graphic/pictorial of the USB devices on a system's root hub. (See more below on how to do this.) +The Interface lines can be used to determine what driver is +being used for each device. + The Configuration lines could be used to list maximum power (in milliamps) that a system's USB devices are using. For example, "grep ^C: /proc/bus/usb/devices". @@ -135,65 +159,57 @@ For example, "grep ^C: /proc/bus/usb/devices". Here's an example, from a system which has a UHCI root hub, an external hub connected to the root hub, and a mouse and -a video camera connected to the external hub. [The video -camera is listed as (none) since it is not recognized by -any driver.] - +a serial converter connected to the external hub. -T: Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= -1 Spd=12 If#= 0 MxCh= 2 Driver=(root hub) -T: Lev=01 Prnt=00 Port=00 Cnt=01 Dev#= 1 Spd=12 If#= 0 MxCh= 4 Driver=hub +T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +B: Alloc= 28/900 us ( 3%), #Int= 2, #Iso= 0 +T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=1446 Rev= 1.00 -C:* #If= 1 Cfg#= 1 Atr=e0 MxPwr=100mA -I: If#= 0 Alt= 0 #EP= 1 Cls=09(hub ) Sub=00 Prot=00 +C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA +I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms -T: Lev=02 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=1.5 If#= 0 MxCh= 0 Driver=mouse +T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 -P: Vendor=0458 ProdID=0001 Rev= 0.00 -C:* #If= 1 Cfg#= 1 Atr=a0 MxPwr=100mA -I: If#= 0 Alt= 0 #EP= 1 Cls=03(HID ) Sub=01 Prot=02 +P: Vendor=04b4 ProdID=0001 Rev= 0.00 +C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA +I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms -T: Lev=02 Prnt=01 Port=02 Cnt=02 Dev#= 4 Spd=12 If#= 0 MxCh= 0 Driver=(none) +T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 -P: Vendor=04c8 ProdID=0720 Rev= 1.01 -C:* #If= 1 Cfg#= 1 Atr=80 MxPwr=500mA -I: If#= 0 Alt= 0 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 -E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms -E: Ad=82(I) Atr=01(Isoc) MxPS= 384 Ivl= 1ms -I: If#= 0 Alt= 1 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 -E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms -E: Ad=82(I) Atr=01(Isoc) MxPS= 240 Ivl= 1ms -I: If#= 0 Alt= 2 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 -E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms -E: Ad=82(I) Atr=01(Isoc) MxPS= 576 Ivl= 1ms -I: If#= 0 Alt= 3 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 -E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms -E: Ad=82(I) Atr=01(Isoc) MxPS= 464 Ivl= 1ms -I: If#= 0 Alt= 4 #EP= 2 Cls=0a(unk. ) Sub=ff Prot=00 -E: Ad=81(I) Atr=01(Isoc) MxPS= 1 Ivl= 1ms -E: Ad=82(I) Atr=01(Isoc) MxPS= 688 Ivl= 1ms - - -Selecting only the "T:" lines from this (for example, by using -"procusb t"), we have: - -T: Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= -1 Spd=12 If#= 0 MxCh= 2 Driver=(root hub) -T: Lev=01 Prnt=00 Port=00 Cnt=01 Dev#= 1 Spd=12 If#= 0 MxCh= 4 Driver=hub -T: Lev=02 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=1.5 If#= 0 MxCh= 0 Driver=mouse -T: Lev=02 Prnt=01 Port=02 Cnt=02 Dev#= 4 Spd=12 If#= 0 MxCh= 0 Driver=(none) +P: Vendor=0565 ProdID=0001 Rev= 1.08 +S: Manufacturer=Peracom Networks, Inc. +S: Product=Peracom USB to Serial Converter +C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA +I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial +E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl= 16ms +E: Ad=01(O) Atr=02(Bulk) MxPS= 16 Ivl= 16ms +E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= 8ms + + +Selecting only the "T:" and "I:" lines from this (for example, by using +"procusb ti"), we have: + +T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 +I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub +T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 +I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse +T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 +I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial Physically this looks like (or could be converted to): +------------------+ - | PC/root_hub (12)| Dev# = -1 + | PC/root_hub (12)| Dev# = 1 +------------------+ (nn) is Mbps. Level 0 | CN.0 | CN.1 | [CN = connector/port #] +------------------+ / / +-----------------------+ - Level 1 | Dev#1: 4-port hub (12)| + Level 1 | Dev#2: 4-port hub (12)| +-----------------------+ |CN.0 |CN.1 |CN.2 |CN.3 | +-----------------------+ @@ -201,7 +217,7 @@ Physically this looks like (or could be converted to): \_____ \ \ \ +--------------------+ +--------------------+ - Level 2 | Dev# 3: mouse (1.5)| | Dev# 4: (none) (12)| + Level 2 | Dev# 3: mouse (1.5)| | Dev# 4: serial (12)| +--------------------+ +--------------------+ @@ -209,11 +225,11 @@ Physically this looks like (or could be converted to): Or, in a more tree-like structure (ports [Connectors] without connections could be omitted): -PC: Dev# -1, root hub, 2 ports, 12 Mbps -|_ CN.0: Dev# 1, hub, 4 ports, 12 Mbps +PC: Dev# 1, root hub, 2 ports, 12 Mbps +|_ CN.0: Dev# 2, hub, 4 ports, 12 Mbps |_ CN.0: Dev #3, mouse, 1.5 Mbps |_ CN.1: - |_ CN.2: Dev #4, (none), 12 Mbps [or use "unknown" for (none)] + |_ CN.2: Dev #4, serial, 12 Mbps |_ CN.3: |_ CN.1: diff --git a/Documentation/usb/scanner-hp-sane.txt b/Documentation/usb/scanner-hp-sane.txt new file mode 100644 index 000000000..220bbb290 --- /dev/null +++ b/Documentation/usb/scanner-hp-sane.txt @@ -0,0 +1,69 @@ +Oct. 19, 1999 + +CHANGES + +- Ammended for Linux-2.3.22+ + + +INTRODUCTION + +This document will hopefully provide enough info on how to get SANE +working with a Hewlett Packard USB capable scanner using the USB +interface. The majority of HP Scanners support the Scanner Control +Language (SCL) which is both published by HP and supported by SANE. +The only HP Scanner that I'm aware of that does not support SCL is the +4200C. All other HP scanners with USB interfaces should work (4100C, +5200C, 6200C, and 6300C). Of course as HP releases new scanners this +information may change. + + +REQUIREMENTS + +In order to get this running you'll need USB support in your kernel in +addition to USB Scanner support. Please refer to README.scanner +for issues pertaining to Linux USB and USB Scanner support. + +An installed version of SANE which is available from +http://www.mostang.com/sane/. Testing has been performed using +version SANE-1.0.1. For instructions on building and installing SANE, +refer to the various README files within the SANE distribution. + + +OK, I'VE INSTALLED SANE. SO WHAT DO I DO NOW? + +NOTE: $INSTALL_DIR is the location where SANE was installed. It may +be /usr/local, /usr, /opt or somewhere else. If you don't know, ask +your system administrator. + +1) Make sure that you have the libsane-hp.* libraries under the +$INSTALL_DIR/lib/sane/ directory. If you don't, then the HP backend +was either not compiled or installed properly. + +2) Under the directory $INSTALL_DIR/etc/sane.d/ edit the following +files: dll.conf, hp.conf. + + dll.conf: Make sure that the 'hp' entry is present and uncommented. + + hp.conf: This should contain two lines: + + /dev/usbscanner + option connect-device + +3) You should now be able to use SANE (xscanimage or scanimage). + +Don't forget to read any relevant man pages regarding the usage of +SANE. If you have other entries uncommented in dll.conf, you may have +to specify the device to (x)scanimage. Again, `man` is your friend. +The xscanimage (1) man page has info on how to get 'The Gimp' to work +with xscanimage. Note that Gimp support must be compiled into SANE +for it work. If you are dealing with a RedHat system, this means that +you'll also need to install the gimp-devel rpm package. + +NOTE: The issues regarding core dumping by (x)scanimage have (or seem +to be thus far) been resolved with version 0.2+ of the USB scanner +driver which should be available in linux-2.3.23. If you notice +otherwise, please contact me. + +David /\/elson +dnelson@jump.net +http://www.jump.net/~dnelson diff --git a/Documentation/usb/scanner.txt b/Documentation/usb/scanner.txt new file mode 100644 index 000000000..4b5de2be8 --- /dev/null +++ b/Documentation/usb/scanner.txt @@ -0,0 +1,231 @@ +Oct 19, 1999 + +CHANGES + +- Ammended for linux-2.3.22+ +- Appended hp_scan.c to end of this README +- Removed most references to HP + + +OVERVIEW + +This README will address issues regarding how to configure the kernel +to access a USB scanner. Although the driver was originally conceived +for USB HP scanners, it's general enough so that it can be used with +other scanners. Also, one can now pass the USB Vendor and +Product ID's using module parameters for unknown scanners. Refer to +the document README.scanner_hp_sane for guidance on how to configure +SANE to use a USB HP Scanner. + + +ADDITIONAL INFORMATION + +http://www.linux-usb.org/ +http://www.dynamine.net/linux-usb/HOWTO/ + + +REQUIREMENTS + +A host with a USB port. Ideally, either a UHCI (Intel) or OHCI +(Compaq and others) hardware port should work. However, I've only +been able to really use an OHCI controller. I did have access to a +system with a UHCI controller but some very limited testing did not +produce satisfactory results. Luke Ordelmans +<postbus@ordelmans.demon.nl> has reported success using the UHCI host +controller with kernel 2.3.18 and a ChainTech motherboard. Here +lately I've been having better success with the ohci-hcd driver. But +since Linux USB support is still in a state of constant development +that may change at a later date. I am confident that eventually all +the host contollers will perform without incident. + +A Linux kernel with USB support (preferably linux-2.3.18+) + +A Linux kernel with USB Scanner support. + + +CONFIGURATION + +Using `make menuconfig` or your prefered method for configuring the +kernel, select 'Support for USB', 'OHCI/OHCI-HCD/UHCI' depending on +your hardware, 'USB hub support', and 'USB Scanner support'. Compile +and install the modules (you may need to execute `depmod -a` to update +the module dependencies). Testing was performed only as modules, +YMMV. + +Add a device for the USB scanner: + linux-2.3.22 and above: `mknod /dev/usbscanner c 180 48` + linux-2.3.21 and below: `mknod /dev/usbscanner c 16 1` + +Set appropriate permissions for /dev/usbscanner (don't forget about +group and world permissions). Both read and write permissions are +required for proper operation. + +Load the appropriate modules (if compiled as modules): + + OHCI: + modprobe usb-ohci + modprobe scanner + + OHCI-HCD: + modprobe usb-ohci-hcd + modprobe hub + modprobe scanner + + UHCI: + modprobe usb-uhci + modprobe hub (don't know if this is required or not) + modprobe scanner + +That's it. SANE should now be able to access the device. + +There is a small test program (hp_scan.c -- appended below) that can +be used to test the scanner device if it's an HP scanner that supports +SCL. Its purpose is to test the driver without having to +retrieve/configure SANE. Hp_scan.c will scan the entire bed and put +the output into a file called 'out.dat' in the current directory. The +data in the file is raw data so it's not very useful for imaging. + + +MODULE PARAMETERS + +If you have a device that wish to experiment with or try using this +driver with, but the Vendor and Product ID's are not coded in, don't +despair. If the driver was compiled as a module, you can pass options +to the driver. Simply add 'options scanner vendor=0x#### +product=0x****' to the conf.modules/modules.conf file replacing the +#'s and the *'s with the correct ID's. The ID's can be retrieved from +the messages file or using `cat /proc/bus/usb/devices` if USB /proc +support was selected during kernel configuration. + + +BUGS + +If you encounter any problems feel free to drop me an email. + +David /\/elson +dnelson@jump.net +http://www.jump.net/~dnelson + +--------------- snip -- hp_scan.c -- snip --------------- +/* + +This is a really crude attempt at writing a short test program. It's +mostly only to be used to test connectivity with USB HP scanners that +understand SCL. Currently, the supported models are 4100C, 5200C, +6200C, and the 6300C. Note that the 4200C is *NOT* acceptable. + +Copyright (C) David E. Nelson <dnelson@jump.net>, 1999 + +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 +the Free Software Foundation; either version 2 of the License, or (at +your option) any later version. + +*/ + +#include <stdio.h> +#include <stdlib.h> +#include <error.h> +#include <unistd.h> +#include <fcntl.h> + +/* + Gray Output produces about a 8945400 byte file. + Color Output produces a 26836200 byte file. + + To compile: gcc -o hp_scan hp_scan.c +*/ + +// #define COLOR /* Undef to scan GrayScale */ + +int send_cmd(int, const char *, int); +int read_cmd(int, char *, int); + +int +main(void) { + + ssize_t cnt = 0, total_cnt = 0; + + FILE *fpout; + + int fp; + int data_size = 32768; + + char *data; + + static char reset_cmd[] = {'\x1b','E'}; + +#ifdef COLOR + static char data_type_cmd[] = {'\x1b','*','a','5','T'}; /* Color */ + static char data_width_cmd[] = {'\x1b','*','a','2','4','G'}; /* 24 Bit Color */ +#else + static char data_type_cmd[] = {'\x1b','*','a','4','T'}; /* Gray */ + static char data_width_cmd[] = {'\x1b','*','a','8','G'}; /* 8 Bit Gray */ +#endif + + static char query_cmd[] = {'\x1b', '*', 's', '2', '5', '7', 'E'}; + static char start_scan_cmd[] = {'\x1b','*','f','0','S'}; + + if(!(data=malloc(data_size))) { + perror("malloc failed"); + exit (1); + } + + if((fp=open("/dev/usbscanner", O_RDWR)) < 0) { + perror("Unable to open scanner device"); + exit (1); + } + + if((fpout=fopen("out.dat", "w+")) == NULL) { + perror("Unable to open ouput file"); + exit(1); + } + + send_cmd(fp, reset_cmd, sizeof(reset_cmd)); + send_cmd(fp, data_type_cmd, sizeof(data_type_cmd)); + send_cmd(fp, data_width_cmd, sizeof(data_width_cmd)); + send_cmd(fp, start_scan_cmd, sizeof(start_scan_cmd)); + + while ((cnt = read(fp, data, data_size)) > 0) { + printf("Read: %u\n", cnt); + if(fwrite(data, sizeof(char), cnt, fpout) < 0) { + perror("Write to output file failed"); + exit (1); + } + total_cnt += cnt; + } + if (cnt < 0) { + perror("Read from scanner failed"); + exit (1); + } + + printf("\nRead %lu bytes.\n", total_cnt); + + send_cmd(fp, reset_cmd, sizeof(reset_cmd)); + + close(fp); + fclose(fpout); + return (0); +} + +int +send_cmd(int fp, const char * cmd, int length) { + + int result; + int x; + + if((result = write(fp, cmd, length)) != length) { + printf ("Write warning: %d bytes requested, %d written\n"); + } else if (result < 0) { + perror ("send_cmd failure"); + exit (1); + } + return (result); +} + +int +read_cmd(int fp, char * response, int length) { + + return read(fp, response, length); + +} diff --git a/Documentation/usb/uhci.txt b/Documentation/usb/uhci.txt new file mode 100644 index 000000000..53aaa11d8 --- /dev/null +++ b/Documentation/usb/uhci.txt @@ -0,0 +1,165 @@ +Specification and Internals for the New UHCI Driver (Whitepaper...) + + brought to you by + + Georg Acher, acher@in.tum.de (executive slave) (base guitar) + Deti Fliegl, deti@fliegl.de (executive slave) (lead voice) + Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader) + + $Id: README.uhci,v 1.1 1999/12/14 14:03:02 fliegl Exp $ + +This document and the new uhci sources can be found on + http://hotswap.in.tum.de/usb + +1. General issues + +1.1 Why a new UHCI driver, we already have one?!? + +Correct, but its internal structure got more and more mixed up by the (still +ongoing) efforts to get isochronous transfers (ISO) to work. +Since there is an increasing need for reliable ISO-transfers (especially +for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF), +this state was a bit unsatisfying in our opinion, so we've decided (based +on knowledge and experiences with the old UHCI driver) to start +from scratch with a new approach, much simpler but at the same time more +powerful. +It is inspired by the way Win98/Win2000 handles USB requests via URBs, +but it's definitely 100% free of MS-code and doesn't crash while +unplugging an used ISO-device like Win98 ;-) +Some code for HW setup and root hub management was taken from the +original UHCI driver, but heavily modified to fit into the new code. +The invention of the basic concept, and major coding were completed in two +days (and nights) on the 16th and 17th of October 1999, now known as the +great USB-October-Revolution started by GA, DF, and TS ;-) + +Since the concept is in no way UHCI dependant, we hope that it will also be +transfered to the OHCI-driver, so both drivers share a common API. + +1.2. Advantages and disadvantages + ++ All USB transfer types work now! ++ Asynchronous operation ++ Simple, but powerful interface (only two calls for start and cancel) ++ Easy migration to the new API, simplified by a compatibility API ++ Simple usage of ISO transfers ++ Automatic linking of requests ++ ISO transfers allow variable length for each frame and striping ++ No CPU dependent and non-portable atomic memory access, no asm()-inlines ++ Tested on x86 and Alpha + +- Rewriting for ISO transfers needed + +1.3. Is there some compatibility to the old API? + +Yes, but only for control, bulk and interrupt transfers. We've implemented +some wrapper calls for these transfer types. The usbcore works fine with +these wrappers. For ISO there's no compatibility, because the old ISO-API +and its semantics were unnecessary complicated in our opinion. + +1.4. What's really working? + +As said above, CTRL und BULK already work fine even with the wrappers, +so legacy code wouldn't notice the change. +Regarding to Thomas, ISO transfers now run stable with USB audio. +INT transfers (e.g. mouse driver) work fine, too. + +1.5. Are there any bugs? + +No ;-) +Hm... +Well, of course this implementation needs extensive testing on all available +hardware, but we believe that any fixes shouldn't harm the overall concept. + +1.6. What should be done next? + +A large part of the request handling seems to be identical for UHCI and +OHCI, so it would be a good idea to extract the common parts and have only +the HW specific stuff in uhci.c. Furthermore, all other USB device drivers +should need URBification, if they use isochronous or interrupt transfers. +One thing missing in the current implementation (and the old UHCI driver) +is fair queueing for BULK transfers. Since this would need (in principle) +the alteration of already constructed TD chains (to switch from depth to +breadth execution), another way has to be found. Maybe some simple +heuristics work with the same effect. + +--------------------------------------------------------------------------- + +2. Internal structure and mechanisms + +To get quickly familiar with the internal structures, here's a short +description how the new UHCI driver works. However, the ultimate source of +truth is only uhci.c! + +2.1. Descriptor structure (QHs and TDs) + +During initialization, the following skeleton is allocated in init_skel: + + framespecific | common chain + +framelist[] +[ 0 ]-----> TD --> TD -------\ +[ 1 ]-----> TD --> TD --------> TD ----> QH -------> QH -------> QH ---> NULL + ... TD --> TD -------/ +[1023]-----> TD --> TD ------/ + + ^^ ^^ ^^ ^^ ^^ ^^ + 1024 TDs for 7 TDs for 1 TD for Start of Start of End Chain + ISO INT (2-128ms) 1ms-INT CTRL Chain BULK Chain + +For each CTRL or BULK transfer a new QH is allocated and the containing data +transfers are appended as (vertical) TDs. After building the whole QH with its +dangling TDs, the QH is inserted before the BULK Chain QH (for CTRL) or +before the End Chain QH (for BULK). Since only the QH->next pointers are +affected, no atomic memory operation is required. The three QHs in the +common chain are never equipped with TDs! + +For ISO or INT, the TD for each frame is simply inserted into the apropriate +ISO/INT-TD-chain for the desired frame. The 7 skeleton INT-TDs are scattered +among the 1024 frames similar to the old UHCI driver. + +For CTRL/BULK/ISO, the last TD in the transfer has the IOC-bit set. For INT, +every TD (there is only one...) has the IOC-bit set. + +Besides the data for the UHCI controller (2 or 4 32bit words), the descriptors +are double-linked through the .vertical and .horizontal elements in the +SW data of the descriptor (using the double-linked list structures and +operations), but SW-linking occurs only in closed domains, i.e. for each of +the 1024 ISO-chains and the 8 INT-chains there is a closed cycle. This +simplifies all insertions and unlinking operations and avoids costly +bus_to_virt()-calls. + +2.2. URB structure and linking to QH/TDs + +During assembly of the QH and TDs of the requested action, these descriptors +are stored in urb->urb_list, so the allocated QH/TD descriptors are bound to +this URB. +If the assembly was successful and the descriptors were added to the HW chain, +the corresponding URB is inserted into a global URB list for this controller. +This list stores all pending URBs. + +2.3. Interrupt processing + +Since UHCI provides no means to directly detect completed transactions, the +following is done in each UHCI interrupt (uhci_interrupt()): + +For each URB in the pending queue (process_urb()), the ACTIVE-flag of the +associated TDs are processed (depending on the transfer type +process_{transfer|interrupt|iso}()). If the TDs are not active anymore, +they indicate the completion of the transaction and the status is calculated. +Inactive QH/TDs are removed from the HW chain (since the host controller +already removed the TDs from the QH, no atomic access is needed) and +eventually the URB is marked as completed (OK or errors) and removed from the +pending queue. Then the next linked URB is submitted. After (or immediately +before) that, the completion handler is called. + +2.4. Unlinking URBs + +First, all QH/TDs stored in the URB are unlinked from the HW chain. +To ensure that the host controller really left a vertical TD chain, we +wait for one frame. After that, the TDs are physically destroyed. + +2.5. URB linking and the consequences + +Since URBs can be linked and the corresponding submit_urb is called in +the UHCI-interrupt, all work associated with URB/QH/TD assembly has to be +interrupt save. This forces kmalloc to use GFP_ATOMIC in the interrupt. diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt new file mode 100644 index 000000000..053f18d2e --- /dev/null +++ b/Documentation/usb/usb-serial.txt @@ -0,0 +1,42 @@ +This serial driver currently only works with the Belkin and Peracom USB +Serial devices. It should also work for the Etek converter, but I do +not know the vendor id and device id of that device (if anyone does, +please let me know.) + +If your device is not compatible with the above models, you can try +out the "generic" interface. This interface does not provide any type +of control messages sent to the device, and does not support any kind +of device flow control. All that is required of your device is that +it has at least one bulk in endpoint, or one bulk out endpoint. +To enable the driver to recognize your device, build the driver as +a module and load it by the following invocation: + insmod usb-serial.o vendor=0x#### product=0x#### +where the #### is replaced with the hex representation of your device's +vendor id and product id. + +The driver can handle enumerating the device, and sending and receiving +data from the converter. However, since I do not have a spec for the Belkin, +Peracom, and eTek devices, and the raw dumps from the Win98 driver are +confusing, and eTek keeps giving me the run around, no control signals are +currently handled, and the data will most likely come through on a baud +rate that you are not expecting. So if you have these devices, do not +expect the correct data to show up at either end. + +The major number that the driver uses is 188 so to use the driver, create +the following nodes: +mknod /dev/ttyUSB0 c 188 0 +mknod /dev/ttyUSB1 c 188 1 +mknod /dev/ttyUSB2 c 188 2 +mknod /dev/ttyUSB3 c 188 3 + +then plug in a device and use your friendly terminal program to see what +happens. + +If anyone has any problems getting the device to enumerate, or data to +flow through it, please contact me. + + + +greg k-h +greg@kroah.com + diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html index b4b9d0dcc..7f144ad9c 100644 --- a/Documentation/video4linux/API.html +++ b/Documentation/video4linux/API.html @@ -30,7 +30,7 @@ passed to the ioctl is completed and returned. It contains the following information <P> <TABLE> -<TR><TD><b>name[32]</b><TD>Cannonical name for this interface</TD> +<TR><TD><b>name[32]</b><TD>Canonical name for this interface</TD> <TR><TD><b>type</b><TD>Type of interface</TD> <TR><TD><b>channels</b><TD>Number of radio/tv channels if appropriate</TD> <TR><TD><b>audios</b><TD>Number of audio devices if appropriate</TD> @@ -125,7 +125,7 @@ disabled by passing it a value of 0. <P> Some capture devices can capture a subfield of the image they actually see. This is indicated when VIDEO_TYPE_SUBCAPTURE is defined. -The video_capture describes the time and spacial subfields to capture. +The video_capture describes the time and special subfields to capture. The video_capture structure contains the following fields. <P> <TABLE> @@ -235,7 +235,7 @@ giving the tuner to use. A struct tuner has the following fields <P> <TABLE> <TR><TD><b>tuner</b><TD>Number of the tuner</TD> -<TR><TD><b>name</b><TD>Cannonical name for this tuner (eg FM/AM/TV)</TD> +<TR><TD><b>name</b><TD>Canonical name for this tuner (eg FM/AM/TV)</TD> <TR><TD><b>rangelow</b><TD>Lowest tunable frequency</TD> <TR><TD><b>rangehigh</b><TD>Highest tunable frequency</TD> <TR><TD><b>flags</b><TD>Flags describing the tuner</TD> @@ -279,7 +279,7 @@ The structure contains the following fields <P> <TABLE> <TR><TD><b>audio</b><TD>The channel number</TD> -<TR><TD><b>volume</b><TD>The voume level</TD> +<TR><TD><b>volume</b><TD>The volume level</TD> <TR><TD><b>bass</b><TD>The bass level</TD> <TR><TD><b>treble</b><TD>The treble level</TD> <TR><TD><b>flags</b><TD>Flags describing the audio channel</TD> @@ -359,13 +359,13 @@ For radio devices that support it, it is possible to receive Radio Data System (RDS) data by means of a read() on the device. The data is packed in groups of three, as follows: <TABLE> -<TR><TD>First Octet</TD><TD>Least Siginificant Byte of RDS Block</TD></TR> -<TR><TD>Second Octet</TD><TD>Most Siginificant Byte of RDS Block +<TR><TD>First Octet</TD><TD>Least Significant Byte of RDS Block</TD></TR> +<TR><TD>Second Octet</TD><TD>Most Significant Byte of RDS Block <TR><TD>Third Octet</TD><TD>Bit 7:</TD><TD>Error bit. Indicates that -an uncorrectable error occured during reception of this block.</TD></TR> +an uncorrectable error occurred during reception of this block.</TD></TR> <TR><TD> </TD><TD>Bit 6:</TD><TD>Corrected bit. Indicates that an error was corrected for this data block.</TD></TR> -<TR><TD> </TD><TD>Bits 5-3:</TD><TD>Reeived Offset. Indicates the +<TR><TD> </TD><TD>Bits 5-3:</TD><TD>Received Offset. Indicates the offset received by the sync system.</TD></TR> <TR><TD> </TD><TD>Bits 2-0:</TD><TD>Offset Name. Indicates the offset applied to this data.</TD></TR> diff --git a/Documentation/video4linux/README.buz b/Documentation/video4linux/README.buz index b9eb9cd74..5eaf517bc 100644 --- a/Documentation/video4linux/README.buz +++ b/Documentation/video4linux/README.buz @@ -41,7 +41,7 @@ grabbing facilities, you must either various kernel versions floating around in the net, you may obtain one e.g. from: http://www.polyware.nl/~middelin/patch/bigphysarea-2.2.1.tar.gz - You also have to compile your driber AFTER installing that patch + You also have to compile your driver AFTER installing that patch in order to get it working or @@ -91,9 +91,9 @@ These values do not affect the MJPEG grabbing facilities of the driver, they are needed for uncompressed image grabbing only!!! v4l_nbufs is the number of buffers to allocate, a value of 2 (the default) -should be sufficient in allmost all cases. Only special applications +should be sufficient in almost all cases. Only special applications (streaming captures) will need more buffers and then mostly the -MJPEG capturing features of the Buz will be more apropriate. +MJPEG capturing features of the Buz will be more appropriate. So leave this parameter at it's default unless you know what you do. The things for v4l_bufsize are more complicated: @@ -107,7 +107,7 @@ In order to be able to capture bigger images you have either to the necessary memory during boot time or - start your kernel with the mem=xxx option, where xxx is your real memory minus the memory needed for the buffers. -In that case, usefull settings for v4l_bufsize are +In that case, useful settings for v4l_bufsize are - 1296 [Kb] for grabbing 24 bit images of max size 768*576 - 1728 [Kb] for 32bit images of same size (4*768*576 = 1728 Kb!) You may reduce these numbers accordingly if you know you are only @@ -137,7 +137,7 @@ triton, natoma -------------- The driver tries to detect if you have a triton or natome chipset -in order to take special messures for these chipsets. +in order to take special measures for these chipsets. If this detection fails but you are sure you have such a chipset, set the corresponding variable to 1. This is a very special option and may go away in the future. @@ -151,7 +151,7 @@ This driver should be fully compliant to Video for Linux, so all tools working with Video for Linux should work with (hopefully) no problems. -A description of the Video for Linux programming interace can be found at: +A description of the Video for Linux programming interface can be found at: http://roadrunner.swansea.linux.org.uk/v4lapi.shtml Besides the Video for Linux interface, the driver has a "proprietary" @@ -162,7 +162,7 @@ The ioctls for that interface are as follows: BUZIOC_G_PARAMS BUZIOC_S_PARAMS -Get and set the parameters of the buz. The user should allways +Get and set the parameters of the buz. The user should always do a BUZIOC_G_PARAMS (with a struct buz_params) to obtain the default settings, change what he likes and then make a BUZIOC_S_PARAMS call. A typical application should at least set the members diff --git a/Documentation/video4linux/bttv/CARDLIST b/Documentation/video4linux/bttv/CARDLIST new file mode 100644 index 000000000..5fd5b826b --- /dev/null +++ b/Documentation/video4linux/bttv/CARDLIST @@ -0,0 +1,52 @@ +bttv.o + card=0 - unknown + card=1 - MIRO PCTV + card=2 - Hauppauge old + card=3 - STB + card=4 - Intel + card=5 - Diamond DTV2000 + card=6 - AVerMedia TVPhone + card=7 - MATRIX-Vision MV-Delta + card=8 - Fly Video II + card=9 - TurboTV + card=10 - Hauppauge new (bt878) + card=11 - MIRO PCTV pro + card=12 - ADS Technologies Channel Surfer TV + card=13 - AVerMedia TVCapture 98 + card=14 - Aimslab VHX + card=15 - Zoltrix TV-Max + card=16 - Pixelview PlayTV (bt878) + card=17 - Leadtek WinView 601 + card=18 - AVEC Intercapture + card=19 - LifeView FlyKit w/o Tuner + card=20 - CEI Raffles Card + card=21 - Lucky Star Image World ConferenceTV + card=22 - Phoebe Tv Master + FM + card=23 - Modular Technology MM205 PCTV, bt878 + card=24 - Magic TView CPH061 (bt878) + card=25 - Terratec/Vobis TV-Boostar + card=26 - Newer Hauppauge WinCam (bt878) + card=27 - MAXI TV Video PCI2 + card=28 - Terratec TerraTV+ + card=29 - Imagenation PXC200 + card=30 - FlyVideo 98 + card=31 - iProTV + card=32 - Intel Create and Share PCI + card=33 - Askey/Typhoon/Anubis Magic TView + card=34 - Terratec TerraTValue + +tuner.o + type=0 - Temic PAL + type=1 - Philips PAL_I + type=2 - Philips NTSC + type=3 - Philips SECAM + type=4 - NoTuner + type=5 - Philips PAL + type=6 - Temic NTSC + type=7 - Temic PAL_I + type=8 - Temic 4036 FY5 NTSC + type=9 - Alps HSBH1 + type=10 - Alps TSBE1 + type=11 - Alps TSBB5 + type=12 - Alps TSBE5 + type=13 - Alps TSBC5 diff --git a/Documentation/video4linux/bttv/CARDS b/Documentation/video4linux/bttv/CARDS deleted file mode 100644 index ff47a322a..000000000 --- a/Documentation/video4linux/bttv/CARDS +++ /dev/null @@ -1,114 +0,0 @@ -Suppported cards: - - -Bt848/Bt848a/Bt849/Bt878/Bt879 cards ------------------------------------- - -All cards with Bt848/Bt848a/Bt849/Bt878/Bt879 and normal Composite/S-VHS inputs -are supported. -Teletext and Intercast support (PAL only) via VBI samples decoding in software. - -Some cards with additional multiplexing of inputs are only partially -supported (unless specifications by the card manufacturer are given). - -All other cards only differ by additional components as tuners, sound decoders, -EEPROMs, teletext decoders ... - -Tuner and sound decoder support for Bt878/879 is not fully working yet. - - -MATRIX Vision -------------- - -MV-Delta -- Bt848A -- 4 Composite inputs, 1 S-VHS input (shared with 4th composite) -- EEPROM - -http://www.matrix-vision.de/ - -This card has no tuner but supports all 4 composite (1 shared with an -S-VHS input) of the Bt848A. -Very nice card if you only have satellite TV but several tuners connected -to the card via composite. - -Many thanks to Matrix-Vision for giving us 2 cards for free which made -Bt848a/Bt849 single crytal operation support possible!!! - - - -Miro/Pinnacle PCTV ------------------- - -- Bt848 - some (all??) come with 2 crystals for PAL/SECAM and NTSC -- PAL, SECAM or NTSC TV tuner (Philips or TEMIC) -- MSP34xx sound decoder on add on board - decoder is supported but AFAIK does not yet work - (other sound MUX setting in GPIO port needed??? somebody who fixed this???) -- 1 tuner, 1 composite and 1 S-VHS input -- tuner type is autodetected - -http://www.miro.de/ -http://www.miro.com/ - - -Many thanks for the free card which made first NTSC support possible back -in 1997! - - -Hauppauge Win/TV pci --------------------- - -There are many different versions of the Hauppauge cards with different -tuners (TV+Radio ...), teletext decoders. -Note that even cards with same model numbers have (depending on the revision) -different chips on it. - -- Bt848 (and others but always in 2 crystal operation???) - newer cards have a Bt878, I2C support for it is still experimental -- PAL, SECAM, NTSC or tuner with or without Radio support - -e.g.: - PAL: - TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners - TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3 - - NTSC: - TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners - TSA5518: no datasheet available on Philips site -- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip - with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM) - SAA5246 (I2C 0x22) is supported -- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y - with configuration information - I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf) -- 1 tuner, 1 composite and (depending on model) 1 S-VHS input -- 14052B: mux for selection of sound source -- sound decoder: TDA9800, MSP34xx (stereo cards) - - -AverMedia ---------- -... - - -ADS Channel Surfer ------------------- -... - - -Maxi TV Video PCI 2 card ------------------------- -... - - -Image World ConferenceTV ------------------------- -Doesn't work: - - autodetect. Use card=21 - - sound mute. Use the line-in volume of your soundcard - - radio tuner. Since the card doesn't have an antenna, it is quite - understandable ;) However, you can hear some stations if you - ``ln -s /dev/bttv0 /dev/radio'' - =20 diff --git a/Documentation/video4linux/bttv/INSTALL b/Documentation/video4linux/bttv/INSTALL deleted file mode 100644 index d38cc557a..000000000 --- a/Documentation/video4linux/bttv/INSTALL +++ /dev/null @@ -1,82 +0,0 @@ -- Make sure you have a recent 2.0.x kernel (I recommend AT LEAST 2.0.33!) - or a recent 2.1.x kernel. - Older kernels might lead to problems. - -- Do NOT compile videodev into your kernel! - Use the module supplied with bttv. - -- Edit "driver/Makefile": - - - If you do NOT have a Miro card: - Adjust TUNER to a number between 0 and 7. - - This number has the following meaning: - - 0: Temic PAL tuner - 1: Philips PAL_I tuner - 2: Philips NTSC tuner - 3: Philips SECAM tuner - 4: no tuner - 5: Philips PAL tuner - 6: Temic NTSC tuner - 7: Temic PAL tuner - 8: Temic 4036 FY5 NTSC tuner - - The number corresponds to the number (-1) given at the GPIO port of the - Bt848 on Miro cards. - - - - Adjust CARD to one of the numbers below: - - 0: Auto-Detect - 1: Miro - 2: Hauppauge - 3: STB - 4: Intel - 5: Diamond - 6: AVerMedia - 7: Matrix Vision MV-Delta - 8: Fly Video II - 9: TurboTV - 10: Newer Hauppauge (Bt878) - 11: Miro PCTV Pro - 12: ADS Tech Channel Surfer TV (and maybe TV+FM) - 13: AVerMedia TVCapture 98 - 14: Aimslab VHX - 15: Zoltrix TV-Max - - - You may have to adjust BTTV_MAJOR to a different number depending on your - kernel version. The official number 81 does not work on some setups. - But instead of changing it, better update to a newer kernel. - - - If you have a Bt848a or Bt849 on your board you might have to - uncomment: -DUSE_PLL - -- do a "make" in the main directory. - -If you have Hauppauge card read "README.HAUPPAUGE" before proceeding. - -- type "make ins" - - This creates the bttv devices in /dev and installs the bttv module - - Look in the kernel log file (/var/adm/syslog or /var/log/kernel or something - else depending on your /etc/syslogd.conf or just call "dmesg") - and see what bttv reported (lines starting with "bttv:") - If the installation failed and you send e-mail to me always include those - lines! Dumps of the insmod output alone do not help at all. - -- Start X11 in hi or true color mode - 8 bit color is also supported but really ugly! - (If you have an S3 card you might have to start X11 before installing - the module!) - - If you have Motif or LessTif, "xtvscreen" in the "XTV" directory should - have been compiled with the "make" above. - Otherwise use the statically linked version which should be available - on the web site you got bttv from. - Read the documentation in "XTV" and start xtvscreen. - -- make applications by typing "make" in "apps" - - diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options new file mode 100644 index 000000000..838413146 --- /dev/null +++ b/Documentation/video4linux/bttv/Insmod-options @@ -0,0 +1,84 @@ + +bttv.o + the bt848 (grabber chip) driver + + insmod args: + card=n card type, see cardlist for a list. + radio=0/1 card supports radio + pll=0/1/2 pll settings + 0: don't use PLL + 1: 28 MHz crystal installed + 2: 35 MHz crystal installed + triton1=0/1 for Triton1 compatibility + Triton1 is automatically recognized + but this might also help with other chipsets + bigendian=n Set the endianness of the gfx framebuffer. + Default is native endian. + fieldnr=1 Count fields. Some TV descrambling software + needs this, for others it only generates + 50 useless IRQs/sec. + autoload=0/1 autoload helper modules (tuner, audio). + default is 1 (on). + + remap, card, radio and pll accept up to four comma-separated arguments + (for multiple boards). + +msp3400.o + The driver for the msp34xx sound processor chips. If you have a + stereo card, you probably want to insmod this one. + + insmod args: + debug=1/2 print some debug info to the syslog, + 2 is more verbose. + simple=1 Use the "short programming" method. Newer + msp34xx versions support this. You need this + for dbx stereo. + once=1 Don't check the TV-stations Audio mode + every few seconds, but only once after + channel switches. + amsound=1 Audio carrier is AM/NICAM at 6.5 Mhz. This + should improve things for french people, the + carrier autoscan seems to work with FM only... + mixer=n allocate mixer device #n. Default is the + first free slot. + +tea6300.o + The driver for the tea6300 fader chip. If you have a stereo + card and the msp3400.o doesn't work, you might want to try this + one. This chip is seen on most STB TV/FM cards (usually from + Gateway OEM sold surplus on auction sites). + + insmod args: + debug=1 print some debug info to the syslog. + +tda8425.o + The driver for the tda8425 fader chip. This driver used to be + part of bttv.c, so if your sound used to work but does not + anymore, try loading this module. + + insmod args: + debug=1 print some debug info to the syslog. + +tda9855.o + The driver for the tda9855 audio chip. Afaik, only the + Diamond DTV2000 has this chip. + + insmod args: + debug=1 print some debug info to the syslog. + +tuner.o + The tuner driver. You need this unless you want to use only + with a camera or external tuner ... + + insmod args: + debug=1 print some debug info to the syslog + type=n type of the tuner chip. n as follows: + 0: Temic PAL tuner + 1: Philips PAL_I tuner + 2: Philips NTSC tuner + 3: Philips SECAM tuner + 4: no tuner + 5: Philips PAL tuner + 6: Temic NTSC tuner + 7: Temic PAL tuner + diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV new file mode 100644 index 000000000..6c29ba43b --- /dev/null +++ b/Documentation/video4linux/bttv/MAKEDEV @@ -0,0 +1,28 @@ +#!/bin/bash + +function makedev () { + + for dev in 0 1 2 3; do + echo "/dev/$1$dev: char 81 $[ $2 + $dev ]" + rm -f /dev/$1$dev + mknod /dev/$1$dev c 81 $[ $2 + $dev ] + chmod 666 /dev/$1$dev + done + + # symlink for default device + rm -f /dev/$1 + ln -s /dev/${1}0 /dev/$1 +} + +# see http://roadrunner.swansea.uk.linux.org/v4lapi.shtml + +echo "*** new device names ***" +makedev video 0 +makedev radio 64 +makedev vtx 192 +makedev vbi 224 + +#echo "*** old device names (for compatibility only) ***" +#makedev bttv 0 +#makedev bttv-fm 64 +#makedev bttv-vbi 224 diff --git a/Documentation/video4linux/bttv/Modules.conf b/Documentation/video4linux/bttv/Modules.conf new file mode 100644 index 000000000..84c79d659 --- /dev/null +++ b/Documentation/video4linux/bttv/Modules.conf @@ -0,0 +1,15 @@ +# i2c +alias char-major-89 i2c-dev +options i2c-core i2c_debug=1 +options i2c-algo-bit bit_test=1 + +# bttv +alias char-major-81 videodev +alias char-major-81-0 bttv +options bttv card=2 radio=1 +options tuner debug=1 + +# make alsa + msp3400 play nicely +options snd-card-ens snd_index=0 +options msp3400 mixer=1 + diff --git a/Documentation/video4linux/bttv/PROBLEMS b/Documentation/video4linux/bttv/PROBLEMS index 0371d2e74..8e31e9e36 100644 --- a/Documentation/video4linux/bttv/PROBLEMS +++ b/Documentation/video4linux/bttv/PROBLEMS @@ -4,7 +4,7 @@ - The memory of some S3 cards is not recognized right: - First of all, if you are not using Xfree-3.2 or newer, upgrade AT LEAST to + First of all, if you are not using XFree-3.2 or newer, upgrade AT LEAST to XFree-3.2A! This solved the problem for most people. Start up X11 like this: "XF86_S3 -probeonly" and write down where the diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README index 72f4f4b73..00b23c52a 100644 --- a/Documentation/video4linux/bttv/README +++ b/Documentation/video4linux/bttv/README @@ -1,41 +1,90 @@ -bttv - BT848 frame grabber driver - -Copyright (C) 1996,97 Ralph Metzler (rjkm@thp.uni-koeln.de) - & Marcus Metzler (mocm@thp.uni-koeln.de) - according to GNU GPL in file COPYING. - - -Bttv is a device driver for frame grabber cards using the Bt848 family -of video decoder chips. -Among those are the Bt848, Bt848A, Bt849, Bt878 and Bt879. -The only major differences between the cards by different manufacturers -are the types of tuners and extra components on the boards. -E.g., some cards by Hauppauge have an additional Videotext decoder -and/or sound decoder chip. -Also type (Composite or S-VHS) and number of inputs differ. -Other Brooktree chips (e.g. the Bt829) or chips by other manufacturers -(Philips, Zoran, ...) are NOT supported by bttv. - -You can use several cards at the same time. -Interrupts can be shared with other Bt848 cards or any other drivers -which allow it. -The (arbitrary) maximum number of cards is 4 but can be adjusted by -changing BTTV_MAX at the beginning of bttv.c if you need more. -(But which board has more than 4 PCI slots plus 1 for the VGA card?) - -Bttv is a standard component of all newer 2.1.x kernels. -This distribution additionally supports 2.0.x kernels and all other -changes and improvements which did not make it into the kernel version -yet. -It also includes versions of videodev.c, i2.c, tuner.c and others -which are the same as in the latest 2.1.x kernel but with 2.0.x support. -A kernel version >2.0.30 is recommended. - -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -Although bttv is now used and tested by many people it still might crash your -computer! Take all precautions to avoid data loss until you are certain -bttv runs on your setup without problems. -!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - -The latest version of bttv can be found at: -http://www.thp.uni-koeln.de/~rjkm/linux/bttv.html + +Release notes for bttv-0.7.x +============================ + +This version is based on Ralphs 0.6.4 release. There are alot of +changes. Bugfixes, merged patches from other people, merged fixes +from the kernel version, port to the new i2c stack, removed support +for 2.0.x, code cleanups, ... + +To compile this bttv version, you'll the new i2c stack. Kernels +newer than 2.3.34 have this already included. If you have a older +kernel, download it from: + http://www2.lm-sensors.nu/~lm78/download.html + +You'll find Ralphs original (mostly outdated) documentation in the +ralphs-doc subdirectory. + + +Compile bttv +------------ + +If you are compiling the kernel version, just say 'm' if you are asked +for bttv. I /strongly/ suggest to compile bttv as module, because +there are some insmod options for configuring the driver. + +If you downloaded the separate bttv bundle: You need configured kernel +sources to compile the bttv driver. The driver uses some Makefile +magic to compile the modules with your kernel's configuration +(wrt. module-versions, SMP, ...). If you already have compiled the +kernel at least once, you probably don't have do worry about this. If +not, go to /usr/src/linux and run at least "make config". Even +better, compile your own kernel, you'll never become a real hacker +else ;-) + + +Make bttv work with your card +----------------------------- + +Of course you have to load the modules as very first thing. The +separate bttv bundle comes with a script called "update". I use this +one to load a new version while doing driver hacking. You can use it +too, but check the module arguments first. They work for my setup, +and probably do *not* for yours. Another way is to setup your +/etc/modules.conf file and let kmod load the modules. See also: + +Modules.conf: some sample entries for /etc/modules.conf +Insmod-options: list of all insmod options available for bttv and + the helper modules. +MAKEDEV: a script to create the special files for v4l +CARDLIST: List of all supported cards + +Loading just the bttv modules isn't enough for most cards. The +drivers for the i2c tuner/sound chips must also be loaded. bttv tries +to load them automagically by calling request_module() now, but this +obviously works only with kmod enabled. + +The most important insmod option for bttv is "card=n" to select the +correct card type. If you get video but no sound you've very likely +specified the wrong (or no) card type. A list of supported cards is +in CARDLIST. + +If your card isn't listed in CARDLIST, you should read the Sound-FAQ. + + +Still doesn't work? +------------------- + +I do NOT have a lab with 30+ different grabber boards and a +PAL/NTSC/SECAM test signal generator at home, so I often can't +reproduce your problems. This makes debugging very difficult for me. +If you have some knowledge and spare time, please try to fix this +yourself (patches very welcome of course...) You know: The linux +slogan is "Do it yourself". + +There is a mailing list: video4linux-list@redhat.com. If you have +trouble with some specific TV card, try to ask there instead of +mailing me directly. The chance that someone with the same card +listens there is much higher... + + +Finally: If you mail some patches for bttv around the world (to +linux-kernel/Alan/Linus/...), please Cc: me. + + +Have fun with bttv, + + Gerd + +-- +Gerd Knorr <kraxel@goldbach.in-berlin.de> diff --git a/Documentation/video4linux/bttv/README.FIRST b/Documentation/video4linux/bttv/README.FIRST deleted file mode 100644 index 2029ab521..000000000 --- a/Documentation/video4linux/bttv/README.FIRST +++ /dev/null @@ -1,4 +0,0 @@ -o Please direct queries about the in kernel version of this driver to - Alan Cox first not to Ralph, or better yet join the video4linux mailing - list (mail video4linux-list-request@redhat.com with "subscribe") - diff --git a/Documentation/video4linux/bttv/README.Hauppauge b/Documentation/video4linux/bttv/README.Hauppauge deleted file mode 100644 index 0076ed8d8..000000000 --- a/Documentation/video4linux/bttv/README.Hauppauge +++ /dev/null @@ -1,29 +0,0 @@ -The current I2C-Code could by accident overwrite the configuration EEPROM on -Hauppauge boards!!! -(E.g. the videotext driver and the bt848 driver do not know about each other. -This might cause unwanted states on the I2C bus which overwrite the EEPROM) - -Back up this EEPROM before doing anything else by typing: -(do this AFTER installing bttv.o with "make ins" but BEFORE starting the -X application) - -make readee -readee > tvee.h - -If you encounter any problems in Windows95 (like "PNP component not found" ...) -go back into linux, load bttv and type: - -make writeee -writeee - -to write the backed up contents. -If you backed up your EEPROM as described above, this will restore it to its -original state. -A detailed description of the meaning of the EEPROM bytes by -Hauppauge would of course be even more helpful! - -If you have board type 405 and you did not make a backup, my tvee.h file in -mytvee.h might be of help. - -Forget about all of the above if you do not have a Hauppauge board. - diff --git a/Documentation/video4linux/bttv/README.MIRO b/Documentation/video4linux/bttv/README.MIRO deleted file mode 100644 index e74fc4ab6..000000000 --- a/Documentation/video4linux/bttv/README.MIRO +++ /dev/null @@ -1,3 +0,0 @@ -The right tuner type should automatically be detected. -Look in your kernel log files to see which one bttv thinks it is. - diff --git a/Documentation/video4linux/bttv/README.PCI b/Documentation/video4linux/bttv/README.PCI deleted file mode 100644 index 1ae8276f1..000000000 --- a/Documentation/video4linux/bttv/README.PCI +++ /dev/null @@ -1,36 +0,0 @@ -Because some people were asking about the bandwidth the Bt848 might use up -on the PCI bus I did a little benchmark. - -"bonnie -s 200" with a Fireball TM 3.8 Gb using Busmaster DMA on an ASUS P6NP5 - -without capturing: - - -------Sequential Output-------- ---Sequential Input-- --Random-- - -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- -Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU - 200 5353 76.6 5898 16.9 2363 12.1 5889 51.3 6416 10.2 37.8 0.9 - - -while capturing full screen PAL (786x576) with 24bpp: - - -------Sequential Output-------- ---Sequential Input-- --Random-- - -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- -Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU - 200 5619 69.3 5939 16.9 2334 12.0 5859 50.9 6441 10.5 37.9 0.9 - -The differences are small and probably within the normal error margin of -bonnie. -So, one bt848 card does not have much(any?) impact on the normal operation -of a Linux system. -If you have several cards running this will look very differently! -The same is probably true if your Linux box is used as a file server -with 15 (or 30) SCSI drives. - -I tested having 2 Bt848 cards grabbing in 32 bit mode (That's almost 100MB/s!) -while running bonnie. -The xtvscreen windows showed severe pixel errors. -After a while the ide driver failed to use DMA and switched DMA off. -It continued running but the results where bad. - - - diff --git a/Documentation/video4linux/bttv/README.RADIO b/Documentation/video4linux/bttv/README.RADIO deleted file mode 100644 index f22f9c0ca..000000000 --- a/Documentation/video4linux/bttv/README.RADIO +++ /dev/null @@ -1,15 +0,0 @@ -Support is in now: - - Turn on the "big red switch" of the sound processor. - - two ioctls to access (some) registers of the sound processor. - - a function in the TV-Widget which monitors the signal quality - and does the mono/stereo switching. - -So you should have TV with (stereo) sound now. Radio does _not_ work. -It probably does not work with sat receivers. I can't test this and -therefore have not added support for it yet. If someone needs this and -can help testing the sat stuff, drop me a note. - - Gerd - --- -Gerd Knorr <kraxel@cs.tu-berlin.de> diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ new file mode 100644 index 000000000..ce8895700 --- /dev/null +++ b/Documentation/video4linux/bttv/Sound-FAQ @@ -0,0 +1,96 @@ + +bttv and sound mini howto +========================= + +There are alot of different bt848/849/878/879 based boards available. +Making video work often is not a big deal, because this is handled +completely by the bt8xx chip, which is common on all boards. But +sound is handled in slightly different ways on each board. + +To handle the grabber boards correctly, there is a array tvcards[] in +bttv.c, which holds the informations required for each board. Sound +will work only, if the correct entry is used (for video it often makes +no difference). The bttv driver prints a line to the kernel log, +telling which card type is used. Like this one: + + bttv0: model: BT848(Hauppauge old) + +You should verify this is correct. If it is'nt, you have to pass the +correct board type as insmod argument, "insmod bttv card=2" for +example. The file CARDLIST has a list of valid arguments for card. +If your card is'nt listed there, you might check the source code for +new entries which are not listed yet. If there is'nt one for your +card, you can check if one of the existing entries does work for you +(just trial and error...). + +Some boards have an extra processor for sound to do stereo decoding +and other nice features. The msp34xx chips are used by Hauppauge for +example. If your board has one, you might have to load a helper +module like msp3400.o to make sound work. If there is'nt one for the +chip used on your board: Bad luck. Start writing a new one. Well, +you might want to check the video4linux mailing list archive first... + +Of course you need a correctly installed soundcard unless you have the +speakers connected directly to the grabber board. Hint: check the +mixer settings too... + + +How sound works in detail +========================= + +Still doesn't work? Looks like some driver hacking is required. +Below is a do-it-yourself description for you. + +The bt8xx chips have 32 general purpose pins, and registers to control +these pins. One register is the output enable register +(BT848_GPIO_OUT_EN), it says which pins are actively driven by the +bt848 chip. Another one is the data register (BT848_GPIO_DATA), where +you can get/set the status if these pins. They can be used for input +and output. + +All grabber board vendors use these pins to control an external chip +which does the sound routing. But every board is a little different. +These pins are also used by some companies to drive remote control +receiver chips. + +As mentioned above, there is a array which holds the required +informations for each known board. You basically have to create a new +line for your board. What is in there: + +struct tvcard +{ + char *name; + int inputs; /* number of video inputs */ + int tuner; /* which of them is the tuner */ + int svhs; /* which of them is the svhs input */ + u32 gpiomask; + u32 muxsel[8]; /* video mux */ + u32 audiomux[6]; /* audio mux: Tuner, Radio, external, internal, mute, stereo */ + u32 gpiomask2; /* GPIO MUX mask (this is video) */ +}; + +gpiomask has all bits set which are used to control the audio mux. +This value basically goes to the gpio output enable register. It is +also used to mask bits when switching the audio mux (which is done by +read-modify-write on the gpio data register). + +What you have to do is figure out the correct values for gpiomask and +the audiomux array. If you have Windows and the drivers four your +card installed, you might to check out if you can read these registers +values used by the windows driver. A tool to do this is available +from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil. There is +some #ifdef'ed code in bttv.c (search for "new card") which prints +these values before board initialization, this might help too: boot +win, start tv app, softboot (loadlin) into linux and load bttv with +this enabled. If you hav'nt Windows installed, this is a trial and +error game... + +Good luck, + + Gerd + + +PS: If you have a new working entry, mail it to me. + +-- +Gerd Knorr <kraxel@goldbach.in-berlin.de> diff --git a/Documentation/video4linux/radiotrack.txt b/Documentation/video4linux/radiotrack.txt index fe942e8a9..a3f2347f0 100644 --- a/Documentation/video4linux/radiotrack.txt +++ b/Documentation/video4linux/radiotrack.txt @@ -10,7 +10,7 @@ This document was made based on 'C' code for Linux from Gideon le Grange (legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from experiments that the author performed on his own setup, so your mileage may -vary... I make no guarantees, claims or warrantees to the suitability or +vary... I make no guarantees, claims or warranties to the suitability or validity of this information. No other documentation on the AIMS Lab (http://www.aimslab.com/) RadioTrack card was made available to the author. This document is offered in the hopes that it might help users who diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt index a028f2b54..54e46326a 100644 --- a/Documentation/video4linux/zr36120.txt +++ b/Documentation/video4linux/zr36120.txt @@ -31,20 +31,20 @@ After some testing, I discovered that the carddesigner messed up on the I2C interface. The Zoran chip includes 2 lines SDA and SCL which (s)he connected reversely. So we have to clock on the SDA and r/w data on the SCL pin. Life is fun... Each cardtype now has -a bit which signifies if you have a card with the same deficiancy. +a bit which signifies if you have a card with the same deficiency. -Oh, for the completness of this story I must mention that my +Oh, for the completeness of this story I must mention that my card delivers the VSYNC pulse of the SAA chip to GIRQ1, not -GIRQ0 as some other cards have. This is also incorperated in +GIRQ0 as some other cards have. This is also incorporated in the driver be clearing/setting the 'useirq1' bit in the tvcard description. -Another problems of contingious capturing data with a Zoran chip +Another problems of continuous capturing data with a Zoran chip is something nasty inside the chip. It effectively halves the fps we ought to get... Here is the scenario: capturing frames to memory is done in the so-called snapshot mode. In this mode the Zoran stops after capturing a frame worth of data and wait -till the application set GRAB bit to indicate readyness for the +till the application set GRAB bit to indicate readiness for the next frame. After detecting a set bit, the chip neetly waits till the start of a frame, captures it and it goes back to off. Smart ppl will notice the problem here. Its the waiting on the @@ -101,7 +101,7 @@ After making the modules check if you have the much needed mknod /dev/video3 c 81 3 mknod /dev/video4 c 81 4 -After makeing/checking the devices do: +After making/checking the devices do: modprobe i2c modprobe videodev modprobe saa7110 (optional) |