diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/00-INDEX | 4 | ||||
| -rw-r--r-- | Documentation/Configure.help | 242 | ||||
| -rw-r--r-- | Documentation/acpi.txt | 125 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/Brutus | 7 | ||||
| -rw-r--r-- | Documentation/arm/nwfpe/README | 2 | ||||
| -rw-r--r-- | Documentation/filesystems/bfs.txt | 26 | ||||
| -rw-r--r-- | Documentation/i2c/i2c-protocol | 22 | ||||
| -rw-r--r-- | Documentation/ia64/README | 76 | ||||
| -rw-r--r-- | Documentation/networking/atm.txt (renamed from Documentation/atm.txt) | 0 | ||||
| -rw-r--r-- | Documentation/networking/decnet.txt | 27 | ||||
| -rw-r--r-- | Documentation/networking/iphase.txt | 158 | ||||
| -rw-r--r-- | Documentation/networking/tlan.txt | 79 | ||||
| -rw-r--r-- | Documentation/pci.txt | 178 | ||||
| -rw-r--r-- | Documentation/pm.txt | 166 | ||||
| -rw-r--r-- | Documentation/sound/CMI8330 | 80 | ||||
| -rw-r--r-- | Documentation/usb/ibmcam.txt | 38 | ||||
| -rw-r--r-- | Documentation/usb/ov511.txt | 9 |
17 files changed, 956 insertions, 283 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 20599cac7..93386cb2e 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -23,8 +23,6 @@ README.DAC960 - info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux VGA-softcursor.txt - how to change your VGA cursor from a blinking underscore. -acpi.txt - - info on ACPI Driver Interface arm/ - directory with info about Linux on the ARM architecture. atm.txt @@ -125,6 +123,8 @@ pci.txt - info on the PCI subsystem for device driver authors pcwd-watchdog.txt - info and sample code for using with the PC Watchdog reset card. +pm.txt + - info on Linux power management support powerpc/ - directory with info on using Linux with the PowerPC. proc_usb_info.txt diff --git a/Documentation/Configure.help b/Documentation/Configure.help index 52b6a3981..32debb7ea 100644 --- a/Documentation/Configure.help +++ b/Documentation/Configure.help @@ -557,6 +557,13 @@ CONFIG_BLK_DEV_RZ1000 People with SCSI-only systems should say N here. If unsure, say Y. +Cyrix CS5530 MediaGX chipset support +CONFIG_BLK_DEV_CS5530 + Include support for UDMA on the Cyrix MediaGX 5530 chipset. This + will automatically be detected and configured if found. + + It is safe to say Y to this question. + Generic PCI IDE chipset support CONFIG_BLK_DEV_IDEPCI Say Y here for PCI systems which use IDE drive(s). @@ -583,7 +590,7 @@ CONFIG_BLK_DEV_IDEDMA_PCI It is safe to say Y to this question. Good-Bad DMA Model-Firmware (EXPERIMENTAL) -IDEDMA_NEW_DRIVE_LISTINGS +CONFIG_IDEDMA_NEW_DRIVE_LISTINGS If you say Y here, the model and firmware revision of your drive will be compared against a blacklist of buggy drives that claim to be (U)DMA capable but aren't. This is a blanket on/off test with no @@ -711,12 +718,12 @@ CONFIG_BLK_DEV_HPT366 Please read the comments at the top of drivers/block/hpt366.c HPT366 Fast Interrupt support (EXPERIMENTAL) (WIP) -HPT366_FAST_IRQ_PREDICTION +CONFIG_HPT366_FAST_IRQ_PREDICTION If unsure, say N. HPT366 mode three unsupported (EXPERIMENTAL) (WIP) -HPT366_MODE3 +CONFIG_HPT366_MODE3 This is an undocumented mode that the HA366 can default to in many cases. If unsure, say N. @@ -785,7 +792,7 @@ CONFIG_BLK_DEV_PDC202XX If unsure, say N. Special UDMA Feature -PDC202XX_FORCE_BURST_BIT +CONFIG_PDC202XX_FORCE_BURST_BIT For PDC20246 and PDC20262 Ultra DMA chipsets. Designed originally for PDC20246/Ultra33 that has BIOS setup failures when using 3 or more cards. @@ -795,7 +802,7 @@ PDC202XX_FORCE_BURST_BIT If unsure, say N. Special Mode Feature (EXPERIMENTAL) -PDC202XX_FORCE_MASTER_MODE +CONFIG_PDC202XX_FORCE_MASTER_MODE For PDC20246 and PDC20262 Ultra DMA chipsets. This is reserved for possible Hardware RAID 0,1 for the FastTrak Series. @@ -2265,7 +2272,8 @@ CONFIG_FB Acorn VIDC support CONFIG_FB_ACORN This is the frame buffer device driver for the Acorn VIDC graphics - chipset. + hardware found in Acorn RISC PCs and other ARM-based machines. If + unsure, say N. Apollo frame buffer device CONFIG_FB_APOLLO @@ -2306,6 +2314,13 @@ CONFIG_FB_CYBER kernel. Please note that this driver DOES NOT support the Cybervision 64 3D card, as they use incompatible video chips. +CyberPro 20x0 support +CONFIG_FB_CYBER2000 + This enables support for the Integraphics CyberPro 20x0 and 5000 + VGA chips used in the Rebel.com Netwinder and other machines. + Say Y if you have a NetWinder or a graphics card containing this + device, otherwise say N. + Amiga CyberVision3D support (EXPERIMENTAL) CONFIG_FB_VIRGE This enables support for the Cybervision 64/3D graphics card from @@ -2426,6 +2441,14 @@ CONFIG_FB_VESA You will get a boot time penguin logo at no additional cost. Please read Documentation/fb/vesafb.txt. If unsure, say Y. +VGA 16-color planar support +CONFIG_FBCON_VGA_PLANES + This low level frame buffer console driver enable the kernel to use + the 16-color planar modes of the old VGA cards where the bits of each + pixel are separated into 4 plans. + Only answer Y here if you have an (very old) VGA card that isn't + VESA 2 compatible. + VGA 16-color graphics console CONFIG_FB_VGA16 This is the frame buffer device driver for VGA 16 color graphic @@ -2436,6 +2459,25 @@ CONFIG_FB_VGA16 running kernel whenever you want), say M here and read Documentation/modules.txt. The module will be called vga16fb.o. +VGA 8x16 font +CONFIG_FONT_8x16 + This is the "high resolution" font for the VGA frame buffer (the one + provided by the text console 80x25 mode. + +Support only 8 pixels wide fonts +CONFIG_FBCON_FONTWIDTH8_ONLY + Answer Y here will make the kernel provide only the 8x8 fonts (these + are the less readable). + +VGA 8x8 font +CONFIG_FONT_8x8 + This is the "high resolution" font for the VGA frame buffer (the one + provided by the text console 80x50 (and higher) modes. + Note this is a poor quality font. The VGA 8x16 font is quite a lot + more readable. + Given the resolution provided by the frame buffer device, anwser N + here is safe. + Backward compatibility mode for Xpmac CONFIG_FB_COMPAT_XPMAC If you use the Xpmac X server (common with mklinux), you'll need to @@ -2729,6 +2771,12 @@ CONFIG_PARPORT_AX Ultra/AX machines. This code is also available as a module (say M), called parport_ax.o. If in doubt, saying N is the safe plan. +Support IEEE1284 status readback +CONFIG_PRINTER_READBACK + If you have a device on your parrallel port that support this protocol, + this option'll enable it to report its status. + It is safe to say Y. + IEEE1284 transfer modes CONFIG_PARPORT_1284 If you have a printer that supports status readback or device ID, or @@ -3933,7 +3981,8 @@ CONFIG_ATM of your ATM card below. Note that you need a set of user-space programs to actually make use - of ATM. See the file Documentation/atm.txt for further details. + of ATM. See the file Documentation/networking/atm.txt for further + details. Classical IP over ATM CONFIG_ATM_CLIP @@ -4075,12 +4124,30 @@ CONFIG_ATM_ZATM_EXACT_TS overhead for timer synchronization and also per-packet overhead for time conversion. -IDT 77201 (NICStAR) +IDT 77201/11 (NICStAR) (ForeRunnerLE) CONFIG_ATM_NICSTAR The NICStAR chipset family is used in a large number of ATM NICs for 25 and for 155 Mbps, including IDT cards and the Fore ForeRunnerLE series. +ForeRunner LE155 PHYsical layer +CONFIG_ATM_NICSTAR_USE_SUNI + Support for the S-UNI and compatible PHYsical layer chips. These are + found in most 155Mbps NICStAR based ATM cards, namely in the + ForeRunner LE155 cards. This driver provides detection of cable + removal and reinsertion and provides some statistics. This driver + doesn't have removal capability when compiled as a module, so if you + need that capability don't include S-UNI support (it's not needed to + make the card work). + +ForeRunner LE25 PHYsical layer +CONFIG_ATM_NICSTAR_USE_IDT77105 + Support for the PHYsical layer chip in ForeRunner LE25 cards. In + addition to cable removal/reinsertion detection, this driver allows + you to control the loopback mode of the chip via a dedicated IOCTL. + This driver is required for proper handling of temporary carrier + loss, so if you have a 25Mbps NICStAR based ATM card you must say Y. + Madge Ambassador (Collage PCI 155 Server) CONFIG_ATM_AMBASSADOR This is a driver for ATMizer based ATM card produced by Madge @@ -4119,6 +4186,33 @@ CONFIG_ATM_HORIZON_DEBUG speed of the driver, and the size of your syslog files! When inactive, they will have only a modest impact on performance. +Interphase ATM PCI x575/x525/x531 +CONFIG_ATM_IA + This is a driver for the Interphase (i)ChipSAR adapter cards + which include a variety of variants in term of the size of the + control memory (128K-1KVC, 512K-4KVC), the size of the packet + memory (128K, 512K, 1M), and the PHY type (Single/Multi mode OC3, + UTP155, UTP25, DS3 and E3). Go to: + www.iphase.com/products/ClassSheet.cfm?ClassID=ATM + for more info about the cards. Say Y (or M to compile as a module + named iphase.o) here if you have one of these cards. + + See the file Documentation/networking/iphase.txt for further + details. + +Enable debugging messages +CONFIG_ATM_IA_DEBUG + Somewhat useful debugging messages are available. The choice of + messages is controlled by a bitmap. This may be specified as a + module argument (kernel command line argument as well?), changed + dynamically using an ioctl (Get the debug utility, iadbg, from + ftp.iphase.com/pub/atm/pci). See the file drivers/atm/iphase.h + for the meanings of the bits in the mask. + + When active, these messages can have a significant impact on the + speed of the driver, and the size of your syslog files! When + inactive, they will have only a modest impact on performance. + SCSI support? CONFIG_SCSI If you want to use a SCSI hard disk, SCSI tape drive, SCSI CDROM or @@ -4161,6 +4255,18 @@ CONFIG_BLK_DEV_SD on a SCSI disk. In this case, do not compile the driver for your SCSI host adapter (below) as a module either. +Extra SCSI Disks +CONFIG_SD_EXTRA_DEVS + This controls the amount of additional space allocated in tables for + drivers that are loaded as modules after the kernel is booted. In + the event that the SCSI core itself was loaded as a module, this this + value is the number of additional disks that can be loaded after the + first host driver is loaded. + + Admittedly this isn't pretty, but there are tons of race conditions + involved with resizing the internal arrays on the fly. Someday this + flag will go away, and everything will work automatically. + SCSI tape support CONFIG_CHR_DEV_ST If you want to use a SCSI tape drive under Linux, say Y and read the @@ -4175,6 +4281,18 @@ CONFIG_CHR_DEV_ST module, say M here and read Documentation/modules.txt and Documentation/scsi.txt . +Extra SCSI Tapes +CONFIG_ST_EXTRA_DEVS + This controls the amount of additional space allocated in tables for + drivers that are loaded as modules after the kernel is booted. In the + event that the SCSI core itself was loaded as a module, this this value + is the number of additional tape devices that can be loaded after the + first host driver is loaded. + + Admittedly this isn't pretty, but there are tons of race conditions + involved with resizing the internal arrays on the fly. Someday this + flag will go away, and everything will work automatically. + SCSI CDROM support CONFIG_BLK_DEV_SR If you want to use a SCSI CDROM under Linux, say Y and read the @@ -4188,6 +4306,18 @@ CONFIG_BLK_DEV_SR module, say M here and read Documentation/modules.txt and Documentation/scsi.txt . +Extra SCSI CDROMs +CONFIG_SR_EXTRA_DEVS + This controls the amount of additional space allocated in tables for + drivers that are loaded as modules after the kernel is booted. In the + event that the SCSI core itself was loaded as a module, this this value + is the number of additional CDROMs that can be loaded after the first + host driver is loaded. + + Admittedly this isn't pretty, but there are tons of race conditions + involved with resizing the internal arrays on the fly. Someday this + flag will go away, and everything will work automatically. + Enable vendor-specific extensions (for SCSI CDROM) CONFIG_BLK_DEV_SR_VENDOR This enables the usage of vendor specific SCSI commands. This is @@ -7359,7 +7489,7 @@ CONFIG_DE4X5 Documentation/networking/net-modules.txt. DECchip Tulip (dc21x4x) PCI support -CONFIG_DEC_ELCP +CONFIG_TULIP This driver is developed for the SMC EtherPower series Ethernet cards and also works with cards based on the DECchip 21040/21041/21140 (Tulip series) chips. Some LinkSys PCI cards are @@ -9492,9 +9622,9 @@ CONFIG_NLS_ISO8859_14 from the Microsoft fat filesystem family or from JOLIET CDROMs correctly on the screen, you need to include the appropriate input/output character sets. Say Y here for the Latin 8 character - set, which adds the last accented vowels for Welsh (and Manx Gaelic) - that were missing in Latin 1. http://linux.speech.cymru.org/ - has further information. + set, which adds the last accented vowels for Welsh (aka Cymraeg) + (and Manx Gaelic) hat were missing in Latin 1. + http://linux.speech.cymru.org/ has further information. nls iso8859-15 CONFIG_NLS_ISO8859_15 @@ -10451,6 +10581,11 @@ CONFIG_APPLICOM If unsure, say N. +Enter S1 for sleep (EXPERIMENTAL) +CONFIG_ACPI_S1_SLEEP + This enable ACPI compliant devices to enter level 1 of ACPI saving + power levels. Basically, this will let them entering in sleep mode. + Advanced Power Management CONFIG_APM APM is a BIOS specification for saving power using several different @@ -13062,7 +13197,84 @@ CONFIG_PHONE_IXJ If you do not have any Quicknet telephony cards, you can safely ignore this option. - + +/dev/agpgart (AGP Support) (EXPERIMENTAL) +CONFIG_AGP + The agpgart kernel module is necessary to use the AGP features + of your 3D rendering video card. It acts as a sort of "AGP + driver" for the motherboard's chipset. + Loading this module into the kernel will allow the glx module to + program the GART (graphics aperture relocation table) registers + with appropriate values to transfer commands to the card. + + If you need more texture memory than you can get with the AGP GART + (theoretically up to 256 megs, but in practice usually 64 or 128 + megs due to kernel allocation issues), you could use PCI accesses + and have up to a couple gigs of texture space. + + Note that this is the only meas to have get XFree4/GLX use + write-combining with MTRR support on AGP bus. Without, OpenGL + direct rendering will be a lot slower but still faster than PIO. + + For the moment, most people should say no, unless you want to + test the GLX component which can be downloaded from + http://glx.on.openprojects.net/ + + or need to use the 810 Xserver in XFree 3.3.6 + +Intel 440LX/BX/GX support +CONFIG_AGP_INTEL + This option give you AGP support for the GLX component of the + "soon to be released" XFree86-4 on Intel 440LX/BX/GX chipsets. + + For the moment, most people should say no, unless you want to + test the GLX component which can be downloaded from + http://glx.on.openprojects.net/ + +Intel I810/I810 DC100/I810e support +CONFIG_AGP_I810 + This option give you AGP support for the Xserver for the intel + 810 chipset boards. This is required to do any useful video + modes. + +VIA VP3/MVP3/Apollo Pro support +CONFIG_AGP_VIA + This option give you AGP support for the GLX component of the + "soon to be released" XFree86-4 on VIA MPV3/Apollo Pro chipsets. + + For the moment, most people should say no, unless you want to + test the GLX component which can be downloaded from + http://glx.on.openprojects.net/ + +AMD Irongate support +CONFIG_AGP_AMD + This option give you AGP support for the GLX component of the + "soon to be released" XFree86-4 on Intel AMD Irongate chipset. + + For the moment, most people should say no, unless you want to + test the GLX component which can be downloaded from + http://glx.on.openprojects.net/ + +Generic SiS support +CONFIG_AGP_SIS + This option give you AGP support for the GLX component of the + "soon to be released" XFree86-4 on Silicon Integrated Systems [SiS] + chipsets. + + Note than 5591/5592 AGP chipsets are NOT supported. + + For the moment, most people should say no, unless you want to + test the GLX component which can be downloaded from + http://glx.on.openprojects.net/ + +ALI M1541 support +CONFIG_AGP_ALI + This option give you AGP support for the GLX component of the + "soon to be released" XFree86-4 on ALI M1541 chipset. + + For the moment, most people should say no, unless you want to + test the GLX component which can be downloaded from + http://glx.on.openprojects.net/ # # ARM options @@ -13591,7 +13803,6 @@ 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 @@ -13644,6 +13855,7 @@ CONFIG_I2C_CHARDEV 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, # Intel, IRQ, Linux, MSDOS, NetWare, NetWinder, NFS, @@ -13905,4 +14117,4 @@ CONFIG_I2C_CHARDEV # 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 OV511 ov511 +# LocalWords: LOGIBUSMOUSE OV511 ov511 Integraphics diff --git a/Documentation/acpi.txt b/Documentation/acpi.txt deleted file mode 100644 index 9629eb29e..000000000 --- a/Documentation/acpi.txt +++ /dev/null @@ -1,125 +0,0 @@ -ACPI Driver Interface ---------------------- - -Overview: -1) Register each instance of a device with "acpi_register" -2) Call "acpi_access" before accessing the hardware. - (this will ensure that the hardware is awake and ready) -3) "acpi_transition" callback is called before entering D1-D3 - or after entering D0 -4) Call "acpi_dev_idle" when the device is not being used - (not required by will improve idle detection) -5) When unloaded, unregister the device with "acpi_unregister" - -/* - * Description: Register a device with the ACPI subsystem - * - * Parameters: - * info - static device information - * type - device type - * hid - PnP identifier (or 0 if unknown) - * trans - device state transition callback - * adr - bus number and address or unique id - * - * Returns: Registered ACPI device or NULL on error - * - * Details: The device type, bus number, and bus address should be - * enough information to reconstruct the device tree and - * identify device dependencies - * - * Examples: - * struct acpi_dev_info info = {ACPI_SYS_DEV, ACPI_VGA_HID, vga_trans}; - * dev = acpi_register(&info, 0); - * - * struct pci_dev *pci_dev = pci_find_dev(...); - * struct acpi_dev_info info = {ACPI_PCI_DEV, 0, trans}; - * dev = acpi_register(&info, ACPI_PCI_ADR(pci_dev)); - */ -struct acpi_dev *acpi_register(struct acpi_dev_info *info, unsigned long adr); - -/* - * Description: Unregister a device with ACPI - * - * Parameters: - * dev - ACPI device previously returned from acpi_register - */ -void acpi_unregister(struct acpi_dev *dev); - -/* - * Device idle/use detection - * - * In general, drivers for all devices should call "acpi_access" - * before accessing the hardware (ie. before reading or modifying - * a hardware register). Request or packet-driven drivers should - * additionally call "acpi_idle" when a device is not being used. - * - * Examples: - * 1) A keyboard driver would call acpi_access whenever a key is pressed - * 2) A network driver would call acpi_access before submitting - * a packet for transmit or receive and acpi_idle when its - * transfer and receive queues are empty. - * 3) A VGA driver would call acpi_access before it accesses any - * of the video controller registers - * - * Ultimately, the ACPI policy manager uses the access and idle - * information to decide when to transition devices between - * device states. - */ - -/* - * Description: Update device access time and wake up device, if necessary - * - * Parameters: - * dev - ACPI device previously returned from acpi_register - * - * Details: If called from an interrupt handler acpi_access updates - * access time but should never need to wake up the device - * (if device is generating interrupts, it should be awake - * already) This is important as we can not wake up - * devices (run AML, etc.) from an interrupt handler. - */ -void acpi_access(struct acpi_dev *dev); - -/* - * Description: Identify device as currently being idle - * - * Parameters: - * dev - ACPI device previously returned from acpi_register - * - * Details: A call to acpi_idle might signal to the policy manager - * to put a device to sleep. If a new device request arrives - * between the call to acpi_idle and the acpi_transition - * callback, the driver should fail the acpi_transition request. - */ -void acpi_dev_idle(struct acpi_dev *dev); - -/* - * Transition function - * - * Parameters: - * dev - ACPI device previously returned from acpi_register - * state - the device state being entered - * - * Returns: 0 if the state transition is possible and context saved - * EINVAL if the requested device state is not supported - * EBUSY if the device is now busy and can not transition - * ENOMEM if the device was unable to save context (out of memory) - * - * Details: The device state transition function will be called - * before the device is transitioned into the D1-D3 states - * or after the device is transitioned into the D0 state. - * The device driver should save (D1-D3) or restore (D0) - * device context when the transition function is called. - * - * For system devices, the ACPI subsystem will perform - * the actual hardware state transition itself. For bus - * devices, after the driver's acpi_transition function - * is called, the bus driver's acpi_transition function - * is called to perform the actual hardware state transition. - * - * Once a driver returns 0 (success) from a transition - * to D1-3 request, it should not process any further - * requests or access the device hardware until a - * call to "acpi_access" is made. - */ -typedef int (*acpi_transition)(struct acpi_dev *dev, acpi_dstate_t state); diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus index b01ba4b29..798f18999 100644 --- a/Documentation/arm/SA1100/Brutus +++ b/Documentation/arm/SA1100/Brutus @@ -16,7 +16,8 @@ must be loaded at 0xc0008000 in Brutus's memory and execution started at 0xc0008000 as well. But prior to execute the kernel, a ramdisk image must also be loaded in -memory. Use memory address 0x00800000 for this. +memory. Use memory address 0xd8000000 for this. Note that the file +containing the (compressed) ramdisk image must not exceed 4 MB. Currently supported: - RS232 serial ports @@ -24,6 +25,10 @@ Currently supported: - LCD screen - keyboard (needs to be cleaned up badly... any volunteer?) +The actual Brutus support may not be complete without extra patches. +If such patches exist, they should be found from +ftp.netwinder.org/users/n/nico. + A full PCMCIA support is still missing, although it's possible to hack some drivers in order to drive already inserted cards at boot time with little modifications. diff --git a/Documentation/arm/nwfpe/README b/Documentation/arm/nwfpe/README index 884fc5a50..253cea48c 100644 --- a/Documentation/arm/nwfpe/README +++ b/Documentation/arm/nwfpe/README @@ -35,7 +35,7 @@ so far in the emulator. The file TODO contains a information on what remains to be done, and other ideas for the emulator. Bug reports, comments, suggestions should be directed to me at -<scottb@netwinder.com>. General reports of "this program doesn't +<scottb@netwinder.org>. General reports of "this program doesn't work correctly when your emulator is installed" are useful for determining that bugs still exist; but are virtually useless when attempting to isolate the problem. Please report them, but don't diff --git a/Documentation/filesystems/bfs.txt b/Documentation/filesystems/bfs.txt index a6179cad9..892fb5137 100644 --- a/Documentation/filesystems/bfs.txt +++ b/Documentation/filesystems/bfs.txt @@ -1,13 +1,9 @@ -The BFS filesystem is used on SCO UnixWare machines for /stand slice. -By default, if you attempt to mount it read-write it will be automatically -mounted read-only. If you want to enable (limited) write support, you need -to select "BFS write support" when configuring the kernel. The write support -at this stage is limited to the blocks preallocated for a given inode. -This means that writes beyond the value of inode->iu_eblock will fail with EIO. -In particular, this means you can create empty files but not write data to them -or you can write data to the existing files and increase their size but not the -number of blocks allocated to them. I am currently working on removing this -limitation, i.e. ability to migrate inodes within BFS filesystem. +BFS FILESYSTEM FOR LINUX +======================== + +The BFS filesystem is used by SCO UnixWare OS for the /stand slice, which +usually contains the kernel image and a few other files required for the +boot process. In order to access /stand partition under Linux you obviously need to know the partition number and the kernel must support UnixWare disk slices @@ -29,7 +25,9 @@ You can simplify mounting by just typing: # mount -t bfs -o loop stand.img /mnt/stand this will allocate the first available loopback device (and load loop.o -kernel module if necessary) automatically. Beware that umount will not +kernel module if necessary) automatically. If the loopback driver is not +loaded automatically, make sure that your kernel is compiled with kmod +support (CONFIG_KMOD) enabled. Beware that umount will not deallocate /dev/loopN device if /etc/mtab file on your system is a symbolic link to /proc/mounts. You will need to do it manually using "-d" switch of losetup(8). Read losetup(8) manpage for more info. @@ -51,9 +49,9 @@ the magic number: # od -Ad -tx4 stand.img | more -The first 4 bytes should be 0x1BADFACE. +The first 4 bytes should be 0x1badface. -If you have any questions or suggestions regarding this BFS implementation -please contact me: +If you have any patches, questions or suggestions regarding this BFS +implementation please contact the author: Tigran A. Aivazian <tigran@ocston.org>. diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol index 16ba77b7a..d8cfdc77b 100644 --- a/Documentation/i2c/i2c-protocol +++ b/Documentation/i2c/i2c-protocol @@ -44,3 +44,25 @@ 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 + + +Modified transactions +===================== + +We have found some I2C devices that needs the following modifications: + + Flag I2C_M_NOSTART: + In a combined transaction, no 'S Addr' is generated at some point. + For example, setting I2C_M_NOSTART on the second partial message + generateds something like: + S Addr Rd [A] [Data] NA Wr [A] Data [A] P + If you set the I2C_M_NOSTART variable for the first partial message, + we do not generate Addr, but we do generate the startbit S. This will + probably confuse all other clients on your bus, so don't try this. + + Flags I2C_M_REV_DIR_ADDR + This toggles the Rd/Wr flag. That is, if you want to do a write, but + need to emit an Rd instead of a Wr, or vice versa, you set this + flag. For example: + S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P + diff --git a/Documentation/ia64/README b/Documentation/ia64/README new file mode 100644 index 000000000..5bb41f96f --- /dev/null +++ b/Documentation/ia64/README @@ -0,0 +1,76 @@ + Linux kernel release 2.3.xx for the IA-64 Platform + + These are the release notes for Linux version 2.3 for IA-64 + platform. This document provides information specific to IA-64 + ONLY, to get additional information about the Linux kernel also + read the original Linux README provided with the kernel. + +INSTALLING the kernel: + + - IA-64 kernel installation is the same as the other platforms, see + original README for details. + + +SOFTWARE REQUIREMENTS + + Compiling and running this kernel requires an IA-64 compliant GCC + compiler. And various software packages also compiled with an + IA-64 compliant GCC compiler. + + +CONFIGURING the kernel: + + Configuration is the same, see original README for details. + + +COMPILING the kernel: + + - Compiling this kernel doesn't differ from other platform so read + the original README for details BUT make sure you have an IA-64 + compliant GCC compiler. + +IA-64 SPECIFICS + + - Security related issues: + + o mmap needs to check whether mapping would overlap with the + address-space hole in a region or whether the mapping would be + across regions. In both cases, mmap should fail. + + o ptrace is a huge security hole right now as it does not reject + writing to security sensitive bits (such as the PSR!). + + - General issues: + + o Kernel modules aren't supported yet. + + o For non-RT signals, siginfo isn't passed through from the kernel + to the point where the signal is actually delivered. Also, we + should make sure the siginfo data is compliant with the UNIX + ABI. + + o Hardly any performance tuning has been done. Obvious targets + include the library routines (memcpy, IP checksum, etc.). Less + obvious targets include making sure we don't flush the TLB + needlessly, etc. Also, the TLB handlers should probably try to + do a speculative load from the virtually mapped linear page + table and only if that fails fall back on walking the page table + tree. + + o Discontigous large memory support; memory above 4GB will be + discontigous since the 4GB-64MB is reserved for firmware and I/O + space. + + o Correct mapping for PAL runtime code; PAL code needs to be + mapped by a TR. + + o Make current IRQ/IOSAPIC handling closer to IA32 such as, + disable/enable interrupts, use of INPROGRESS flag etc. + + o clone system call implementation; needs to setup proper backing + store + + o SMP locks cleanup/optimization + + o IA32 support. Currently experimental. It mostly works but + there are problems with some dynamically loaded programs. diff --git a/Documentation/atm.txt b/Documentation/networking/atm.txt index 2fc1b5a60..2fc1b5a60 100644 --- a/Documentation/atm.txt +++ b/Documentation/networking/atm.txt diff --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt index 09ae1d978..ca2f16fc6 100644 --- a/Documentation/networking/decnet.txt +++ b/Documentation/networking/decnet.txt @@ -27,8 +27,8 @@ Be sure to turn on the following options: CONFIG_PROCFS (to see what's going on) CONFIG_SYSCTL (for easy configuration) -if you want to try out router support (not properly debugged and not -complete yet), you'll need the following options as well... +if you want to try out router support (not properly debugged yet) +you'll need the following options as well... CONFIG_DECNET_RAW (to receive routing packets) CONFIG_DECNET_ROUTER (to be able to add/delete routes) @@ -39,26 +39,26 @@ complete yet), you'll need the following options as well... The kernel command line takes options looking like the following: - decnet=1,2,1 + decnet=1,2 -the first two numbers are the node address 1,2 = 1.2 For 2.2.xx kernels +the two numbers are the node address 1,2 = 1.2 For 2.2.xx kernels and early 2.3.xx kernels, you must use a comma when specifying the DECnet address like this. For more recent 2.3.xx kernels, you may use almost charecter except space, although a `.` would be the most obvious choice :-) -The third number is the level number for routers and is optional. In fact -this option may go away shortly in favour if settings for each interface -seperately. It is probably a good idea to set the DECnet address and type -on boot like this rather than trying to do it later. +There used to be a third number specifying the node type. This option +has gone away in favour of a per interface node type. This is now set +using /proc/sys/net/decnet/conf/<dev>/forwarding. This file can be +set with a single digit, 0=EndNode, 1=L1 Router and 2=L2 Router. -There are also equivalent options for modules. The node address and type can +There are also equivalent options for modules. The node address can also be set through the /proc/sys/net/decnet/ files, as can other system parameters. -Currently the only supported device is ethernet. You'll have to set the -ethernet address of your ethernet card according to the DECnet address -of the node in order for it to be recognised (and thus appear in +Currently the only supported devices are ethernet and ip_gre. The +ethernet address of your ethernet card has to be set according to the DECnet +address of the node in order for it to be recognised (and thus appear in /proc/net/decnet_dev). There is a utility available at the above FTP sites called dn2ethaddr which can compute the correct ethernet address to use. The address can be set by ifconfig either before at @@ -101,7 +101,8 @@ Here is a quick guide of what to look for in order to know if your DECnet kernel subsystem is working. - Is the node address set (see /proc/sys/net/decnet/node_address) - - Is the node of the correct type (see /proc/sys/net/decnet/node_type) + - Is the node of the correct type + (see /proc/sys/net/decnet/conf/<dev>/forwarding) - Is the Ethernet MAC address of each Ethernet card set to match the DECnet address. If in doubt use the dn2ethaddr utility available at the ftp archive. diff --git a/Documentation/networking/iphase.txt b/Documentation/networking/iphase.txt new file mode 100644 index 000000000..94356d67d --- /dev/null +++ b/Documentation/networking/iphase.txt @@ -0,0 +1,158 @@ + + READ ME FISRT + ATM (i)Chip IA Linux Driver Source +-------------------------------------------------------------------------------- + Read This Before You Begin! +-------------------------------------------------------------------------------- + +Description +----------- + +This is the README file for the Interphase PCI ATM (i)Chip IA Linux driver +source release. + +The features and limitations of this driver are as follows: + - A single VPI (VPI value of 0) is supported. + - Supports 4K VCs for the server board (with 512K control memory) and 1K + VCs for the client board (with 128K control memory). + - UBR, ABR and CBR service categories are supported. + - Only AAL5 is supported. + - Supports setting of PCR on the VCs. + - Multiple adapters in a system are supported. + - All variants of Interphase ATM PCI (i)Chip adapter cards are supported, + including x575 (OC3, control memory 128K , 512K and packet memory 128K, + 512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See + http://www.iphase.com/products/ClassSheet.cfm?ClassID=ATM + for details. + - Only x86 platforms are supported. + - SMP is supported. + + +Before You Start +---------------- + + +Installation +------------ + +1. Installing the adapters in the system + To install the ATM adapters in the system, follow the steps below. + a. Login as root. + b. Shut down the system and power off the system. + c. Install one or more ATM adapters in the system. + d. Connect each adapter to a port on an ATM switch. The green 'Link' + LED on the front panel of the adapter will be on if the adapter is + connected to the switch properly when the system is powered up. + e. Power on and boot the system. + +2. [ Removed ] + +3. Rebuild kernel with ABR support + [ a. and b. removed ] + c. Reconfigure the kernel, choose the Interphase ia driver through "make + menuconfig" or "make xconfig". + d. Rebuild the kernel, loadable modules and the atm tools. + e. Install the new built kernel and modules and reboot. + +4. Load the adapter hardware driver (ia driver) if it is built as a module + a. Login as root. + b. Change directory to /lib/modules/<kernel-version>/atm. + c. Run "insmod suni.o;insmod iphase.o" + The yellow 'status' LED on the front panel of the adapter will blink + while the driver is loaded in the system. + d. To verify that the 'ia' driver is loaded successfully, run the + following command: + + cat /proc/atm/devices + + If the driver is loaded successfully, the output of the command will + be similar to the following lines: + + Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ... + 0 ia xxxxxxxxx 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 ) + + You can also check the system log file /var/log/messages for messages + related to the ATM driver. + +5. Ia Driver Configuration + +5.1 Configuration of adapter buffers + The (i)Chip boards have 3 different packet RAM size variants: 128K, 512K and + 1M. The RAM size decides the number of buffers and buffer size. The default + size and number of buffers are set as following: + + Totol Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf + RAM size size size size size cnt cnt + -------- ------ ------ ------ ------ ------ ------ + 128K 64K 64K 10K 10K 6 6 + 512K 256K 256K 10K 10K 25 25 + 1M 512K 512K 10K 10K 51 51 + + These setting should work well in most environments, but can be + changed by typing the following command: + + insmod <IA_DIR>/ia.o IA_RX_BUF=<RX_CNT> IA_RX_BUF_SZ=<RX_SIZE> \ + IA_TX_BUF=<TX_CNT> IA_TX_BUF_SZ=<TX_SIZE> + Where: + RX_CNT = number of receive buffers in the range (1-128) + RX_SIZE = size of receive buffers in the range (48-64K) + TX_CNT = number of transmit buffers in the range (1-128) + TX_SIZE = size of transmit buffers in the range (48-64K) + + 1. Transmit and receive buffer size must be a multiple of 4. + 2. Care should be taken so that the memory required for the + transmit and receive buffers is less than or equal to the + total adapter packet memory. + +5.2 Turn on ia debug trace + + When the ia driver is built with the CONFIG_ATM_IA_DEBUG flag, the driver + can provide more debug trace if needed. There is a bit mask variable, + IADebugFlag, which controls the output of the traces. You can find the bit + map of the IADebugFlag in iphase.h. + The debug trace can be turn on through the insmod command line option, for + example, "insmod iphase.o IADebugFlag=0xffffffff" can turn on all the debug + traces together with loading the driver. + +6. Ia Driver Test Using ttcp_atm and PVC + + For the PVC setup, the test machines can either be connected back-to-back or + through a switch. If connected through the switch, the switch must be + configured for the PVC(s). + + a. For UBR test: + At the test machine intended to receive data, type: + ttcp_atm -r -a -s 0.100 + At the other test machine, type: + ttcp_atm -t -a -s 0.100 -n 10000 + Run "ttcp_atm -h" to display more options of the ttcp_atm tool. + b. For ABR test: + It is the same as the UBR testing, but with an extra command option: + -Pabr:max_pcr=<xxx> + where: + xxx = the maximum peak cell rate, from 170 - 353207. + This option must be set on both the machines. + c. For CBR test: + It is the same as the UBR testing, but with an extra command option: + -Pcbr:max_pcr=<xxx> + where: + xxx = the maximum peak cell rate, from 170 - 353207. + This option may only be set on the trasmit machine. + + +OUTSTANDING ISSUES +------------------ + + + +Contact Information +------------------- + + Customer Support: + United States: Telephone: (214) 654-5555 + Fax: (214) 654-5500 + E-Mail: intouch@iphase.com + Europe: Telephone: 33 (0)1 41 15 44 00 + Fax: 33 (0)1 41 15 12 13 + World Wide Web: http://www.iphase.com + Anonymous FTP: ftp.iphase.com diff --git a/Documentation/networking/tlan.txt b/Documentation/networking/tlan.txt index 4114be27a..4e1347395 100644 --- a/Documentation/networking/tlan.txt +++ b/Documentation/networking/tlan.txt @@ -1,25 +1,8 @@ +(C) 1997-1998 Caldera, Inc. +(C) 1998 James Banks +(C) 1999-2000 Torben Mathiasen <torben.mathiasen@compaq.com> - -I haven't had any time to do anything for a long time, and this isn't -likely to change. So there's a driver here for anyone looking to -carry forward a project :) - -For those who are looking for help, I can't. I haven't looked at -a kernel since the early 2.0 series, so I won't know what's going on. -Your best chance at help would be joining the TLAN mailing list and -posting your question there. - -You can join by sending "subscribe tlan" in the body of an email to -majordomo@vuser.vu.union.edu. - -Thanks to those who have (and who will ;) put work in to keep the TLAN -driver working as the kernel moves on. - -James -james@sovereign.org - - -TLAN driver for Linux, version 1.0 +TLAN driver for Linux, version 1.3 README @@ -57,43 +40,7 @@ I. Supported Devices. but I do not expect any problems. -II. Building the Driver. - - The TLAN driver may be compiled into the kernel, or it may be compiled - as a module separately, or in the kernel. A patch is included for - 2.0.29 (which also works for 2.0.30, 2.0.31, and 2.0.32). - - To compile it as part of the kernel: - 1. Download and untar the TLAN driver package. - 2. If your kernel is 2.1.45 or later, you do not need to patch the - kernel sources. Copy the tlan.c and tlan.h to drivers/net in - the kernel source tree. - 3. Otherwise, apply the appropriate patch for your kernel. For - example: - - cd /usr/src/linux - patch -p1 < kernel.2.0.29 - - 4. Copy the files tlan.c and tlan.h from the TLAN package to the - directory drivers/net in the Linux kernel source tree. - 5. Configure your kernel for the TLAN driver. Answer 'Y' when - prompted to ask about experimental code (the first question). - Then answer 'Y' when prompted if to include TI ThunderLAN - support. If you want the driver compiled as a module, answer 'M' - instead of 'Y'. - 6. Make the kernel and, if necessary, the modules. - - To compile the TLAN driver independently: - 1. Download and untar the TLAN driver package. - 2. Change to the tlan directory. - 3. If you are NOT using a versioned kernel (ie, want an non- - versioned module), edit the Makefile, and comment out the - line: - MODVERSIONS = -DMODVERSIONS - 4. Run 'make'. - - -III. Driver Options +II. Driver Options 1. You can append debug=x to the end of the insmod line to get debug messages, where x is a bit field where the bits mean the following: @@ -110,18 +57,20 @@ III. Driver Options device that does not have an AUI/BNC connector will probably cause it to not function correctly.) - 4. You can set duplex=1 to force half duplex, and duplex=2 to + 3. You can set duplex=1 to force half duplex, and duplex=2 to force full duplex. - 5. You can set speed=10 to force 10Mbs operation, and speed=100Mbs + 4. You can set speed=10 to force 10Mbs operation, and speed=100 to force 100Mbs operation. (I'm not sure what will happen if a card which only supports 10Mbs is forced into 100Mbs mode.) - 3. If the driver is built into the kernel, you can use the 3rd + 5. If the driver is built into the kernel, you can use the 3rd and 4th parameters to set aui and debug respectively. For example: +/* kernel-parameters are currently not supported. I will fix this asap. */ + ether=0,0,0x1,0x7,eth0 This sets aui to 0x1 and debug to 0x7, assuming eth0 is a @@ -130,19 +79,17 @@ III. Driver Options The bits in the third byte are assigned as follows: 0x01 = aui - 0x02 = use SA_INTERRUPT flag when reserving the irq. 0x04 = use half duplex 0x08 = use full duplex 0x10 = use 10BaseT 0x20 = use 100BaseTx -IV. Things to try if you have problems. +III. Things to try if you have problems. 1. Make sure your card's PCI id is among those listed in section I, above. - 1. Make sure routing is correct. - 2. If you are using a 2.1.x kernel, try to duplicate the - problem on a 2.0.x (preferably 2.0.29 or 2.0.30) kernel. + 2. Make sure routing is correct. + 3. Try forcing different speed/duplex settings There is also a tlan mailing list which you can join by sending "subscribe tlan" diff --git a/Documentation/pci.txt b/Documentation/pci.txt index e74477fd4..d1211c512 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -1,52 +1,130 @@ - Few Notes About The PCI Subsystem + How To Write Linux PCI Drivers - or - - "What should you avoid when writing PCI drivers" - - by Martin Mares <mj@suse.cz> on 21-Nov-1999 + by Martin Mares <mj@suse.cz> on 07-Feb-2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The world of PCI is vast and it's full of (mostly unpleasant) surprises. +Different PCI devices have different requirements and different bugs -- +because of this, the PCI support layer in Linux kernel is not as trivial +as one would wish. This short pamphlet tries to help all potential driver +authors to find their way through the deep forests of PCI handling. + 0. Structure of PCI drivers ~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Aa typical PCI device driver needs to perform the following actions: - - 1. Find PCI devices it's able to handle - 2. Enable them - 3. Access their configuration space - 4. Discover addresses and IRQ numbers - -1. How to find PCI devices -~~~~~~~~~~~~~~~~~~~~~~~~~~ - In case your driver wants to search for all devices with given vendor/device -ID, it should use: - - struct pci_dev *dev = NULL; - while (dev = pci_find_device(VENDOR_ID, DEVICE_ID, dev)) - configure_device(dev); - - For class-based search, use pci_find_class(CLASS_ID, dev). - - If you need to match by subsystem vendor/device ID, use -pci_find_subsys(VENDOR_ID, DEVICE_ID, SUBSYS_VENDOR_ID, SUBSYS_DEVICE_ID, dev). +There exist two kinds of PCI drivers: new-style ones (which leave most of +probing for devices to the PCI layer and support online insertion and removal +of devices [thus supporting PCI, hot-pluggable PCI and CardBus in single +driver]) and old-style ones which just do all the probing themselves. Unless +you have a very good reason to do so, please don't use the old way of probing +in any new code. After the driver finds the devices it wishes to operate +on (either the old or the new way), it needs to perform the following steps: + + Enable the device + Access device configuration space + Discover resources (addresses and IRQ numbers) provided by the device + Allocate these resources + Communicate with the device + +Most of these topics are covered by the following sections, for the rest +look at <linux/pci.h>, it's hopefully well commented. + +If the PCI subsystem is not configured (CONFIG_PCI is not set), most of +the functions described below are defined as inline functions either completely +empty or just returning an appropriate error codes to avoid lots of ifdefs +in the drivers. + + +1. New-style drivers +~~~~~~~~~~~~~~~~~~~~ +The new-style drivers just call pci_register_driver during their initialization +with a pointer to a structure describing the driver (struct pci_driver) which +contains: + + name Name of the driver + id_table Pointer to table of device ID's the driver is + interested in + probe Pointer to a probing function which gets called (during + execution of pci_register_driver for already existing + devices or later if a new device gets inserted) for all + PCI devices which match the ID table and are not handled + by the other drivers yet. This function gets passed a pointer + to the pci_dev structure representing the device and also + which entry in the ID table did the device match. It returns + zero when the driver has accepted the device or an error + code (negative number) otherwise. This function always gets + called from process context, so it can sleep. + remove Pointer to a function which gets called whenever a device + being handled by this driver is removed (either during + deregistration of the driver or when it's manually pulled + out of a hot-pluggable slot). This function can be called + from interrupt context. + suspend, Power management hooks (currently used only for CardBus + resume cards) -- called when the device goes to sleep or is + resumed. + +The ID table is an array of struct pci_device_id ending with a all-zero entry. +Each entry consists of: + + vendor, device Vendor and device ID to match (or PCI_ANY_ID) + subvendor, Subsystem vendor and device ID to match (or PCI_ANY_ID) + subdevice + class, Device class to match. The class_mask tells which bits + class_mask of the class are honored during the comparison. + driver_data Data private to the driver. + +When the driver exits, it just calls pci_deregister_driver() and the PCI layer +automatically calls the remove hook for all devices handled by the driver. + +Please mark the initialization and cleanup functions where appropriate +(the corresponding macros are defined in <linux/init.h>): + + __init Initialization code. Thrown away after the driver + initializes. + __exit Exit code. Ignored for non-modular drivers. + __devinit Device initialization code. Identical to __init if + the kernel is not compiled with CONFIG_HOTPLUG, normal + function otherwise. + __devexit The same for __exit. + + +2. How to find PCI devices manually (the old style) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +PCI drivers not using the pci_register_driver() interface search +for PCI devices manually using the following constructs: + +Searching by vendor and device ID: + + struct pci_dev *dev = NULL; + while (dev = pci_find_device(VENDOR_ID, DEVICE_ID, dev)) + configure_device(dev); + +Searching by class ID (iterate in a similar way): + + pci_find_class(CLASS_ID, dev) + +Searching by both vendor/device and subsystem vendor/device ID: + + pci_find_subsys(VENDOR_ID, DEVICE_ID, SUBSYS_VENDOR_ID, SUBSYS_DEVICE_ID, dev). You can use the constant PCI_ANY_ID as a wildcard replacement for 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, you can walk the list of all -known PCI devices: + In case you need to decide according to some more complex criteria, +you can walk the list of all known PCI devices yourself: + + struct pci_dev *dev; + pci_for_each_dev(dev) { + ... do anything you want with dev ... + } - struct pci_dev *dev; - pci_for_each_dev(dev) { - ... do anything you want with dev ... - } +For compatibility with device ordering in older kernels, you can also +use pci_for_each_dev_reverse(dev) for walking the list in the opposite +direction. - The `struct pci_dev *' pointer serves as an identification of a PCI device -and is passed to all other functions operating on PCI devices. -2. Enabling devices +3. Enabling devices ~~~~~~~~~~~~~~~~~~~ Before you do anything with the device you've found, you need to enable it by calling pci_enable_device() which enables I/O and memory regions of @@ -57,7 +135,8 @@ if it was in suspended state. Please note that this function can fail. which enables the bus master bit in PCI_COMMAND register and also fixes the latency timer value if it's set to something bogus by the BIOS. -3. How to access PCI config space + +4. How to access PCI config space ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can use pci_(read|write)_config_(byte|word|dword) to access the config space of a device represented by struct pci_dev *. All these functions return 0 @@ -72,7 +151,8 @@ use symbolic names of locations and bits declared in <linux/pci.h>. pci_find_capability() for the particular capability and it will find the corresponding register block for you. -4. Addresses and interrupts + +5. Addresses and interrupts ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Memory and port addresses and interrupt numbers should NOT be read from the config space. You should use the values in the pci_dev structure as they might @@ -86,13 +166,33 @@ for memory regions to make sure nobody else is using the same device. All interrupt handlers should be registered with SA_SHIRQ and use the devid to map IRQs to devices (remember that all PCI interrupts are shared). -5. Other interesting functions + +6. Other interesting functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ pci_find_slot() Find pci_dev corresponding to given bus and slot numbers. pci_set_power_state() Set PCI Power Management state (0=D0 ... 3=D3) +pci_find_capability() Find specified capability in device's capability + list. + + +7. Miscellaneous hints +~~~~~~~~~~~~~~~~~~~~~~ +When displaying PCI slot names to the user (for example when a driver wants +to tell the user what card has it found), please use pci_dev->slot_name +for this purpose. + +Always refer to the PCI devices by a pointer to the pci_dev structure. +All PCI layer functions use this identification and it's the only +reasonable one. Don't use bus/slot/function numbers except for very +special purposes -- on systems with multiple primary buses their semantics +can be pretty complex. + +If you're going to use PCI bus mastering DMA, take a look at +Documentation/DMA-mapping.txt. + -6. Obsolete functions +8. Obsolete functions ~~~~~~~~~~~~~~~~~~~~~ There are several functions kept only for compatibility with old drivers not updated to the new PCI interface. Please don't use them in new code. diff --git a/Documentation/pm.txt b/Documentation/pm.txt new file mode 100644 index 000000000..eb7a819b6 --- /dev/null +++ b/Documentation/pm.txt @@ -0,0 +1,166 @@ + Linux Power Management Support + +This document briefly describes how to use power management with your +Linux system and how to add power management support to Linux drivers. + +APM or ACPI? +------------ +If you have a relatively recent x86 mobile, desktop, or server system, +odds are it supports either Advanced Power Management (APM) or +Advanced Configuration and Power Interface (ACPI). ACPI is the newer +of the two technologies and puts power management in the hands of the +operating system, allowing for more intelligent power management than +is possible with BIOS controlled APM. + +The best way to determine which, if either, your system supports is to +build a kernel with both ACPI and APM enabled (as of 2.3.x ACPI is +enabled by default). If a working ACPI implementation is found, the +ACPI driver will override and disable APM, otherwise the APM driver +will be used. + +No sorry, you can not have both ACPI and APM enabled and running at +once. Some people with broken ACPI or broken APM implementations +would like to use both to get a full set of working features, but you +simply can not mix and match the two. Only one power management +interface can be in control of the machine at once. Think about it.. + +User-space Daemons +------------------ +Both APM and ACPI rely on user-space daemons, apmd and acpid +respectively, to be completely functional. Obtain both of these +daemons from your Linux distribution or from the Internet (see below) +and be sure that they are started sometime in the system boot process. +Go ahead and start both. If ACPI or APM is not available on your +system the associated daemon will exit gracefully. + + apmd: http://linuxcare.com.au/apm/ + acpid: http://phobos.fs.tum.de/acpi/ + +Driver Interface +---------------- +If you are writing a new driver or maintaining an old driver, it +should include power management support. Without power management +support, a single driver may prevent a system with power management +capabilities from ever being able to suspend (safely). + +Overview: +1) Register each instance of a device with "pm_register" +2) Call "pm_access" before accessing the hardware. + (this will ensure that the hardware is awake and ready) +3) Your "pm_callback" is called before going into a + suspend state (ACPI D1-D3) or after resuming (ACPI D0) + from a suspend. +4) Call "pm_dev_idle" when the device is not being used + (optional but will improve device idle detection) +5) When unloaded, unregister the device with "pm_unregister" + +/* + * Description: Register a device with the power-management subsystem + * + * Parameters: + * type - device type (PCI device, system device, ...) + * id - instance number or unique identifier + * cback - request handler callback (suspend, resume, ...) + * + * Returns: Registered PM device or NULL on error + * + * Examples: + * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback); + * + * struct pci_dev *pci_dev = pci_find_dev(...); + * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback); + */ +struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback); + +/* + * Description: Unregister a device with the power management subsystem + * + * Parameters: + * dev - PM device previously returned from pm_register + */ +void pm_unregister(struct pm_dev *dev); + +/* + * Description: Unregister all devices with a matching callback function + * + * Parameters: + * cback - previously registered request callback + * + * Notes: Provided for easier porting from old APM interface + */ +void pm_unregister_all(pm_callback cback); + +/* + * Device idle/use detection + * + * In general, drivers for all devices should call "pm_access" + * before accessing the hardware (ie. before reading or modifying + * a hardware register). Request or packet-driven drivers should + * additionally call "pm_dev_idle" when a device is not being used. + * + * Examples: + * 1) A keyboard driver would call pm_access whenever a key is pressed + * 2) A network driver would call pm_access before submitting + * a packet for transmit or receive and pm_dev_idle when its + * transfer and receive queues are empty. + * 3) A VGA driver would call pm_access before it accesses any + * of the video controller registers + * + * Ultimately, the PM policy manager uses the access and idle + * information to decide when to suspend individual devices + * or when to suspend the entire system + */ + +/* + * Description: Update device access time and wake up device, if necessary + * + * Parameters: + * dev - PM device previously returned from pm_register + * + * Details: If called from an interrupt handler pm_access updates + * access time but should never need to wake up the device + * (if device is generating interrupts, it should be awake + * already) This is important as we can not wake up + * devices from an interrupt handler. + */ +void pm_access(struct pm_dev *dev); + +/* + * Description: Identify device as currently being idle + * + * Parameters: + * dev - PM device previously returned from pm_register + * + * Details: A call to pm_dev_idle might signal to the policy manager + * to put a device to sleep. If a new device request arrives + * between the call to pm_dev_idle and the pm_callback + * callback, the driver should fail the pm_callback request. + */ +void pm_dev_idle(struct pm_dev *dev); + +/* + * Power management request callback + * + * Parameters: + * dev - PM device previously returned from pm_register + * rqst - request type + * data - data, if any, associated with the request + * + * Returns: 0 if the request is successful + * EINVAL if the request is not supported + * EBUSY if the device is now busy and can not handle the request + * ENOMEM if the device was unable to handle the request due to memory + * + * Details: The device request callback will be called before the + * device/system enters a suspend state (ACPI D1-D3) or + * or after the device/system resumes from suspend (ACPI D0). + * For PM_SUSPEND, the ACPI D-state being entered is passed + * as the "data" argument to the callback. The device + * driver should save (PM_SUSPEND) or restore (PM_RESUME) + * device context when the request callback is called. + * + * Once a driver returns 0 (success) from a suspend + * request, it should not process any further requests or + * access the device hardware until a call to "pm_access" is made. + */ +typedef int (*pm_callback)(struct pm_dev *dev, pm_request_t rqst, void *data); diff --git a/Documentation/sound/CMI8330 b/Documentation/sound/CMI8330 index a12bed1d2..0ca5af70f 100644 --- a/Documentation/sound/CMI8330 +++ b/Documentation/sound/CMI8330 @@ -1,3 +1,83 @@ +Documentation for CMI 8330 (SoundPRO) +------------------------------------- +Alessandro Zummo <azummo@ita.flashnet.it> + +This adapter is now directly supported by the sb driver. + + The only thing you have to do is to compile the kernel sound +support as a module and to enable kernel ISAPnP support, +as shown below. + + +CONFIG_SOUND=m +CONFIG_SOUND_SB=m + +CONFIG_PNP=y +CONFIG_ISAPNP=y + + +and optionally: + + +CONFIG_SOUND_MPU401=m + + for MPU401 support. + + +CONFIG_SOUND_YM3812=m + + for OPL3 support. Please note that there are better ways to play midi files, like + timidity or the softoss2 module. + + +CONFIG_JOYSTICK=y + + to activate the joystick port. + + +(I suggest you to use "make menuconfig" or "make xconfig" + for a more comfortable configuration editing) + + + +Then you can do + + modprobe sb + +and everything will be (hopefully) configured. + +You should get something similar in syslog: + +sb: CMI8330 detected. +sb: CMI8330 sb base located at 0x220 +sb: CMI8330 mpu base located at 0x330 +sb: CMI8330 gameport base located at 0x200 +sb: CMI8330 opl3 base located at 0x388 +sb: CMI8330 mail reports to Alessandro Zummo <azummo@ita.flashnet.it> +sb: ISAPnP reports CMI 8330 SoundPRO at i/o 0x220, irq 7, dma 1,5 + + + + +To activate the OPL3 support, you need these lines in /etc/modules.conf +or in a file in /etc/modutils + +alias synth0 opl3 +options opl3 io=0x388 + +and then you can do: + + modprobe opl3 + + + + + + +The old documentation file follows for reference +purposes. + + How to enable CMI 8330 (SOUNDPRO) soundchip on Linux ------------------------------------------ Stefan Laudat <Stefan.Laudat@asit.ro> diff --git a/Documentation/usb/ibmcam.txt b/Documentation/usb/ibmcam.txt index 4d7ab56eb..6880ed334 100644 --- a/Documentation/usb/ibmcam.txt +++ b/Documentation/usb/ibmcam.txt @@ -23,11 +23,30 @@ SUPPORTED CAMERAS: IBM "C-It" camera, also known as "Xirlink PC Camera" The device uses proprietary ASIC (and compression method); -it is manufactured by Xirlink. See http://www.xirlink.com +it is manufactured by Xirlink. See http://www.xirlink.com/ +or http://www.c-itnow.com/ for details and pictures. + +The Linux driver was developed with camera with following +model number (or FCC ID): KSX-XVP510. This camera has three +interfaces, each with one endpoint (control, iso, iso). + +It appears that Xirlink made some changes in their cameras recently. +In particular, following models [FCC ID] are suspect; one with +with FCC ID KSX-X9903 is known to be one of them: + +XVP300 [KSX-X9903] +XVP600 [KSX-X9902] +XVP610 [KSX-X9902] + +(see http://www.xirlink.com/ibmpccamera/ for updates, they refer +to these new cameras by Windows driver dated 12-27-99, v3005 BETA) +These cameras have two interfaces, one endpoint in each (iso, bulk). +Attempts to remotely debug one of these cameras weren't successful. +I'd need to have a camera to figure out how to use it. WHAT YOU NEED: -- An IBM C-it camera +- A supported IBM PC (C-it) camera (see above) - A Linux box with USB support (2.3/2.4 or 2.2 w/backport) @@ -73,6 +92,7 @@ Name Type Range [default] Example debug Integer 0-9 [0] debug=1 flags Integer 0-0xFF [0] flags=0x0d framerate Integer 0-6 [2] framerate=1 +hue_correction Integer 0-255 [128] hue_correction=115 init_brightness Integer 0-255 [128] init_brightness=100 init_contrast Integer 0-255 [192] init_contrast=200 init_color Integer 0-255 [128] init_color=130 @@ -108,6 +128,16 @@ framerate This setting controls frame rate of the camera. This is Beware - fast settings are very demanding and may not work well with all video sizes. Be conservative. +hue_correction This highly optional setting allows to adjust the + hue of the image in a way slightly different from + what usual "hue" control does. Both controls affect + YUV colorspace: regular "hue" control adjusts only + U component, and this "hue_correction" option similarly + adjusts only V component. However usually it is enough + to tweak only U or V to compensate for colored light or + color temperature; this option simply allows more + complicated correction when and if it is necessary. + init_brightness These settings specify _initial_ values which will be init_contrast used to set up the camera. If your V4L application has init_color its own controls to adjust the picture then these @@ -143,8 +173,8 @@ videosize This setting chooses one if three image sizes that are WHAT NEEDS TO BE DONE: -- The box freezes if working camera (with xawtv) is unplugged (OHCI). - Workaround: don't do that :) End the V4L application first. +- The box freezes if camera is unplugged after being used (OHCI). + Workaround: don't do that :) - Some USB frames are lost on high frame rates, though they shouldn't - ViCE compression (Xirlink proprietary) may improve frame rate - On occasion camera does not start properly; xawtv reports errors. diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt index fe84f11df..c13fc4c52 100644 --- a/Documentation/usb/ov511.txt +++ b/Documentation/usb/ov511.txt @@ -15,12 +15,13 @@ SUPPORTED CAMERAS: ________________________________________________________ Manufacturer | Model | Custom ID | Status -----------------+----------------+-----------+--------- -MediaForte | MV300 | 0 | Untested +MediaForte | MV300 | 0 | Working D-Link | DSB-C300 | 3 | Working +Puretek | PT-6007 | 5 | Untested Creative Labs | WebCam 3 | 21 | Working Lifeview | RoboCam | 100 | Untested AverMedia | InterCam Elite | 102 | Working -MediaForte | MV300 | 112 | Untested +MediaForte | MV300 | 112 | Working -------------------------------------------------------- Any camera using the OV511 and the OV7610 CCD should work with this driver. The @@ -78,7 +79,9 @@ directory: make make install -Now you should be able to run xawtv. Right click for the options dialog. +Now you should be able to run xawtv. Right click for the options dialog. If +you get a scrambled image it is likely that you made a mistake in Xawtv.ad. +Try setting the size to 320x240 if all else fails. WORKING FEATURES: o Color streaming/capture at 640x480 and 320x240 |