diff options
| author | Ralf Baechle <ralf@linux-mips.org> | 2000-11-28 03:58:46 +0000 |
|---|---|---|
| committer | Ralf Baechle <ralf@linux-mips.org> | 2000-11-28 03:58:46 +0000 |
| commit | b63ad0882a16a5d28003e57f2b0b81dee3fb322b (patch) | |
| tree | 0a343ce219e2b8b38a5d702d66032c57b83d9720 /Documentation | |
| parent | a9d7bff9a84dba79609a0002e5321b74c4d64c64 (diff) | |
Merge with 2.4.0-test11.
Diffstat (limited to 'Documentation')
24 files changed, 813 insertions, 585 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 93386cb2e..a7bca2f14 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -43,6 +43,8 @@ digiboard.txt - info on the Digiboard PC/X{i,e,eve} multiport boards. digiepca.txt - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. +dnotify.txt + - info about directory notification in Linux. exception.txt - how Linux v2.2 handles exceptions without verify_area etc. fb/ diff --git a/Documentation/Configure.help b/Documentation/Configure.help index 4927cd8b7..76c55c43c 100644 --- a/Documentation/Configure.help +++ b/Documentation/Configure.help @@ -77,7 +77,7 @@ CONFIG_EXPERIMENTAL in some special cases. Detailed bug reports from people familiar with the kernel internals are usually welcomed by the developers (before submitting bug reports, please read the documents README, - MAINTAINERS, REPORTING_BUGS, Documentation/BUG-HUNTING, and + MAINTAINERS, REPORTING-BUGS, Documentation/BUG-HUNTING, and Documentation/oops-tracing.txt in the kernel source). This option will also make obsoleted drivers available. These are @@ -113,7 +113,7 @@ CONFIG_SMP Management" code will be disabled if you say Y here. See also the files Documentation/smp.tex, Documentation/smp.txt, - Documentation/IO-APIC.txt, Documentation/nmi_watchdog.txt and the + Documentation/i386/IO-APIC.txt, Documentation/nmi_watchdog.txt and the SMP-FAQ on the WWW at http://www.irisa.fr/prive/mentre/smp-faq/ . If you don't know what to do here, say N. @@ -2069,6 +2069,23 @@ CONFIG_IP_NF_COMPAT_IPFWADM If you want to compile it as a module, say M here and read Documentation/modules.txt. If unsure, say `N'. +TCP Explicit Congestion Notification support +CONFIG_INET_ECN + Explicit Congestion Notification (ECN) allows routers to notify + clients about network congestion, resulting in fewer dropped packets + and increased network performance. This option adds ECN support to the + Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which + allows ECN support to be disabled at runtime. + + Note that, on the Internet, there are many broken firewalls which + refuse connections from ECN-enabled machines, and it may be a while + before these firewalls are fixed. Until then, to access a site behind + such a firewall (some of which are major sites, at the time of this + writing) you will have to disable this option, either by saying N now + or by using the sysctl. + + If in doubt, say N. + SYN flood protection CONFIG_SYN_COOKIES Normal TCP/IP networking is open to an attack known as "SYN @@ -2355,7 +2372,7 @@ CONFIG_AGP Intel 440LX/BX/GX support CONFIG_AGP_INTEL This option gives you AGP support for the GLX component of the - XFree86 4.x on Intel 440LX/BX/GX chipsets. + XFree86 4.x on Intel 440LX/BX/GX, 815, and 840 chipsets. For the moment, you should probably say N, unless you want to test the GLX component for XFree86 3.3.6, which can be downloaded from @@ -2363,9 +2380,9 @@ CONFIG_AGP_INTEL Intel I810/I810 DC100/I810e support CONFIG_AGP_I810 - This option gives you AGP support for the Xserver for the Intel - 810 chipset boards. This is required to do any useful video - modes. + This option gives you AGP support for the Xserver on the Intel 810 + and 815 chipset boards for their on-board integrated graphics. This + is required to do any useful video modes with these boards. VIA chipset support CONFIG_AGP_VIA @@ -2482,6 +2499,20 @@ CONFIG_MCA Documentation/mca.txt (and especially the web page given there) before attempting to build an MCA bus kernel. +EISA support +CONFIG_EISA + The Extended Industry Standard Architecture (EISA) bus was + developed as an open alternative to the IBM MicroChannel bus. + + The EISA bus provided some of the features of the IBM MicroChannel + bus while maintaining backward compatibility with cards made for + the older ISA bus. The EISA bus saw limited use between 1988 and 1995 + when it was made obsolete by the PCI bus. + + Say Y here if you are building a kernel for an EISA-based machine. + + Otherwise, say N. + SGI Visual Workstation support CONFIG_VISWS The SGI Visual Workstation series is an IA32-based workstation @@ -2855,6 +2886,7 @@ CONFIG_M386 - "Pentium-MMX" for the Intel Pentium MMX. - "Pentium-Pro" for the Intel Pentium Pro/Celeron/Pentium II. - "Pentium-III" for the Intel Pentium III. + - "Pentium-4" for the Intel Pentium 4 - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D). - "Athlon" for the AMD Athlon (K7). - "Crusoe" for the Transmeta Crusoe series. @@ -3488,7 +3520,7 @@ CONFIG_PARPORT The module will be called parport.o. If you have more than one parallel port and want to specify which port and IRQ to be used by this driver at module load time, take a look at - Documentation/networking/parport.txt. + Documentation/parport.txt. If unsure, say Y. @@ -3631,7 +3663,7 @@ CONFIG_INET "Sysctl support" below, you can change various aspects of the behavior of the TCP/IP code by writing to the (virtual) files in /proc/sys/net/ipv4/*; the options are explained in the file - Documentation/Networking/ip-sysctl.txt. + Documentation/networking/ip-sysctl.txt. Short answer: say Y. @@ -5012,7 +5044,7 @@ Compaq Smart Array support CONFIG_BLK_CPQ_CISS_DA This is the driver for Compaq Smart Array controllers. Everyone using these boards should say Y here. - See "linux/Documentation/cciss.txt" for the current list of + See Documentation/cciss.txt for the current list of boards supported by this driver, and for further information on the use of this driver. @@ -14012,7 +14044,7 @@ CONFIG_SOUND_MSS SGI Visual Workstation on-board audio CONFIG_SOUND_VWSND Say Y or M if you have an SGI Visual Workstation and you want to - be able to use its on-board audio. Read Documentation/sound/visws + be able to use its on-board audio. Read Documentation/sound/vwsnd for more info on this driver's capabilities. Ensoniq Soundscape support @@ -14045,8 +14077,7 @@ CONFIG_TRIX_BOOT_FILE Support for OPTi MAD16 and/or Mozart based cards CONFIG_SOUND_MAD16 Answer Y if your card has a Mozart (OAK OTI-601) or MAD16 (OPTi - 82C928 or 82C929 or 82C931) audio interface chip. For the 82C931, - please read drivers/sound/README.C931. These chips are currently + 82C928 or 82C929 or 82C931) audio interface chip. These chips are quite common so it's possible that many no-name cards have one of them. In addition the MAD16 chip is used in some cards made by known manufacturers such as Turtle Beach (Tropez), Reveal (some models) diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt index 952dbc652..5201a2f54 100644 --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt @@ -305,19 +305,23 @@ Here is the new interface: If D-cache aliasing is not an issue, this routine may simply be defined as a nop on that architecture. - TODO: If we set aside a few bits in page->flags as - "architecture private", these interfaces could - be implemented much more efficiently. This would - allow one to "defer" (perhaps indefinitely) the - actual flush if there are currently no user processes - mapping this page. - - The idea is, first at flush_dcache_page() time, if - page->mapping->i_mmap is an empty list, just mark - one of the architecture private page flag bits. - Later, in update_mmu_cache(), a check could be made - of this flag bit, and if set the flush is done - and the flag bit is cleared. + There is a bit set aside in page->flags (PG_arch_1) as + "architecture private". The kernel guarentees that, + for pagecache pages, it will clear this bit when such + a page first enters the pagecache. + + This allows these interfaces to be implemented much more + efficiently. It allows one to "defer" (perhaps indefinitely) + the actual flush if there are currently no user processes + mapping this page. See sparc64's flush_dcache_page and + update_mmu_cache implementations for an example of how to go + about doing this. + + The idea is, first at flush_dcache_page() time, if + page->mapping->i_mmap{,_shared} are empty lists, just mark the + architecture private page flag bit. Later, in + update_mmu_cache(), a check is made of this flag bit, and if + set the flush is done and the flag bit is cleared. XXX Not documented: flush_icache_page(), need to talk to Paul Mackerras, David Mosberger-Tang, et al. diff --git a/Documentation/dnotify.txt b/Documentation/dnotify.txt new file mode 100644 index 000000000..9f8611803 --- /dev/null +++ b/Documentation/dnotify.txt @@ -0,0 +1,92 @@ + Linux Directory Notification + ============================ + + Stephen Rothwell <sfr@linuxcare.com.au> + +The intention of directory notification is to allow user applications +to be notified when a directory, or any of the files in it, are changed. +The basic mechanism involves the application registering for notification +on a directory using a fcntl(2) call and the notifications themselves +being delivered using signals. + +The application decides which "events" it wants to be notified about. +The currently defined events are: + + DN_ACCESS A file in the directory was accessed (read) + DN_MODIFY A file in the directory was modified (write,truncate) + DN_CREATE A file was created in the directory + DN_DELETE A file was unlinked from directory + DN_RENAME A file in the directory was renamed + DN_ATTRIB A file in the directory had its attributes + changed (chmod,chown) + +Usually, the application must reregister after each notification, but +if DN_MULTISHOT is or'ed with the event mask, then the registration will +remain until explicitly removed (by registering for no events). + +By default, SIGIO will be delivered to the process and no other useful +information. However, if the F_SETSIG fcntl(2) call is used to let the +kernel know which signal to deliver, a siginfo structure will be passed to +the signal handler and the si_fd member of that structure will contain the +file descriptor associated with the direcory in which the event occured. + +Preferably the application will choose one of the real time signals +(SIGRTMIN + <n>) so that the notifications may be queued. This is +especially important if DN_MULTISHOT is specified. + +Implementation expectations (features and bugs :-)) +--------------------------- + +The notification should work for any local access to files even if the +actual file system is on a remote server. This implies that remote +access to files served by local user mode servers should be notified. +Also, remote accesses to files served by a local kernel NFS server should +be notified. + +In order to make the impact on the file system code as small as possible, +the problem of hard links to files has been ignored. So if a file (x) +exists in two directories (a and b) then a change to the file using the +name "a/x" should be notified to a program expecting notifications on +directory "a", but will not be notified to one expecting notifications on +directory "b". + +Also, files that are unlinked, will still cause notifications in the +last directory that they were linked to. + +Example +------- + + #define _GNU_SOURCE /* needed to get the defines */ + #include <fcntl.h> /* in glibc 2.2 this has the needed + values defined */ + #include <signal.h> + #include <stdio.h> + #include <unistd.h> + + static volatile int event_fd; + + static void handler(int sig, siginfo_t *si, void *data) + { + event_fd = si->si_fd; + } + + int main(void) + { + struct sigaction act; + int fd; + + act.sa_sigaction = handler; + sigemptyset(&act.sa_mask); + act.sa_flags = SA_SIGINFO; + sigaction(SIGRTMIN, &act, NULL); + + fd = open(".", O_RDONLY); + fcntl(fd, F_SETSIG, SIGRTMIN); + fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT); + /* we will now be notified if any of the files + in "." is modified or new files are created */ + while (1) { + pause(); + printf("Got event on fd=%d\n", event_fd); + } + } diff --git a/Documentation/fb/matroxfb.txt b/Documentation/fb/matroxfb.txt index 0b8068dc5..a3bbe6b92 100644 --- a/Documentation/fb/matroxfb.txt +++ b/Documentation/fb/matroxfb.txt @@ -253,7 +253,7 @@ depth:X - Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on `vesa'. If you know capabilities of your monitor, you can specify some (or all) of -`pixclk', `fh' and `fv'. In this case, `pixclock' is computed so that +`maxclk', `fh' and `fv'. In this case, `pixclock' is computed so that pixclock <= maxclk, real_fh <= fh and real_fv <= fv. maxclk:X - maximum dotclock. X can be specified in MHz, kHz or Hz. Default is diff --git a/Documentation/isdn/README.act2000 b/Documentation/isdn/README.act2000 index 0846d96b3..ce7115e7f 100644 --- a/Documentation/isdn/README.act2000 +++ b/Documentation/isdn/README.act2000 @@ -1,4 +1,4 @@ -$Id: README.act2000,v 1.2 1998/04/29 19:49:06 he Exp $ +$Id: README.act2000,v 1.3 2000/08/06 09:22:51 armin Exp $ This document describes the ACT2000 driver for the IBM Active 2000 ISDN card. diff --git a/Documentation/isdn/README.eicon b/Documentation/isdn/README.eicon index a77542a67..16dd09eb9 100644 --- a/Documentation/isdn/README.eicon +++ b/Documentation/isdn/README.eicon @@ -1,4 +1,4 @@ -$Id: README.eicon,v 1.9 2000/06/08 08:50:25 armin Exp $ +$Id: README.eicon,v 1.10 2000/08/13 12:19:15 armin Exp $ (c) 1999,2000 Armin Schindler (mac@melware.de) (c) 1999,2000 Cytronics & Melware (info@melware.de) diff --git a/Documentation/isdn/README.icn b/Documentation/isdn/README.icn index 37aa7f3d0..a5f55eadb 100644 --- a/Documentation/isdn/README.icn +++ b/Documentation/isdn/README.icn @@ -1,4 +1,4 @@ -$Id: README.icn,v 1.6 1998/04/29 19:49:08 he Exp $ +$Id: README.icn,v 1.7 2000/08/06 09:22:51 armin Exp $ You can get the ICN-ISDN-card from: diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 13a663e3e..1b63892c6 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -640,6 +640,12 @@ The public interface of Rules.make consists of the following variables: but then you will notice a lot of extra compiles when you edit any source file. Blame CONFIG_MODVERSIONS for this.] + Data that is passed to other objects via registration functions + (e.g. pci_register_driver, pm_register) does not need to be marked + as EXPORT_SYMBOL. The objects that pass data via registration + functions do not need to be marked as OX_OBJS, unless they also have + exported symbols. + Rules.make compiles all the $(O_OBJS) and $(OX_OBJS) files. It then calls "$(LD) -r" to merge these files into one .o file with the name $(O_TARGET). This $(O_TARGET) name also appears diff --git a/Documentation/networking/bridge.txt b/Documentation/networking/bridge.txt index 043a14b16..66ffb4c1f 100644 --- a/Documentation/networking/bridge.txt +++ b/Documentation/networking/bridge.txt @@ -1,11 +1,11 @@ In order to use the ethernet bridging functionality you'll need the -userspace tools available at ftp://openrock.net/bridge. The tarball -available there contains extensive documentation, but if you still have -questions, don't hesitate to post to the mailing list (more info at -http://openrock.net/mailman/listinfo/bridge). You can also mail me at -buytenh@openrock.net. +userspace tools available at http://www.math.leidenuniv.nl/~buytenh/bridge. +The tarball available there contains extensive documentation, but if you +still have questions, don't hesitate to post to the mailing list (more info +at http://www.math.leidenuniv.nl/mailman/listinfo/bridge). You can also +mail me at buytenh@gnu.org. Lennert Buytenhek -<buytenh@openrock.net> +<buytenh@gnu.org> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index aade6928c..419906891 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -203,7 +203,7 @@ tcp_fack - BOOLEAN tcp_dsack - BOOLEAN Allows TCP to send "duplicate" SACKs. -tcp_ecn - BOOLEN +tcp_ecn - BOOLEAN Enable Explicit Congestion Notification in TCP. tcp_reordering - INTEGER @@ -376,4 +376,4 @@ kuznet@ms2.inr.ac.ru Updated by: Andi Kleen ak@muc.de -$Id: ip-sysctl.txt,v 1.16 2000/08/13 18:24:11 davem Exp $ +$Id: ip-sysctl.txt,v 1.17 2000/11/06 07:15:36 davem Exp $ diff --git a/Documentation/networking/lapb-module.txt b/Documentation/networking/lapb-module.txt index 28a000838..d4fc8f221 100644 --- a/Documentation/networking/lapb-module.txt +++ b/Documentation/networking/lapb-module.txt @@ -2,6 +2,8 @@ Jonathan Naylor 29.12.96 +Changed (Henner Eisen, 2000-10-29): int return value for data_indication() + The LAPB module will be a separately compiled module for use by any parts of the Linux operating system that require a LAPB service. This document defines the interfaces to, and the services provided by this module. The @@ -37,7 +39,7 @@ struct lapb_register_struct { void (*connect_indication)(int token, int reason); void (*disconnect_confirmation)(int token, int reason); void (*disconnect_indication)(int token, int reason); - void (*data_indication)(int token, struct sk_buff *skb); + int (*data_indication)(int token, struct sk_buff *skb); void (*data_transmit)(int token, struct sk_buff *skb); }; @@ -240,7 +242,7 @@ LAPB_TIMEDOUT No response was received in N2 tries from the remote system. -void (*data_indication)(void *token, struct sk_buff *skb); +int (*data_indication)(void *token, struct sk_buff *skb); This is called by the LAPB module when data has been received from the remote system that should be passed onto the next layer in the protocol @@ -248,6 +250,10 @@ stack. The skbuff becomes the property of the device driver and the LAPB module will not perform any more actions on it. The skb->data pointer will be pointing to the first byte of data after the LAPB header. +This method should return NET_RX_DROP (as defined in the header +file include/linux/netdevice.h) if and only if the frame was dropped +before it could be delivered to the upper layer. + void (*data_transmit)(void *token, struct sk_buff *skb); diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt new file mode 100644 index 000000000..8769040b3 --- /dev/null +++ b/Documentation/networking/netdevices.txt @@ -0,0 +1,42 @@ + +Network Devices, the Kernel, and You! + + +Introduction +============ +The following is a random collection of documentation regarding +network devices. + + + +struct net_device synchronization rules +======================================= +dev->open: + Locking: Inside rtnl_lock() semaphore. + Sleeping: OK + +dev->stop: + Locking: Inside rtnl_lock() semaphore. + Sleeping: OK + +dev->do_ioctl: + Locking: Inside rtnl_lock() semaphore. + Sleeping: OK + +dev->get_stats: + Locking: Inside dev_base_lock spinlock. + Sleeping: NO + +dev->hard_start_xmit: + Locking: Inside dev->xmit_lock spinlock. + Sleeping: NO + +dev->tx_timeout: + Locking: Inside dev->xmit_lock spinlock. + Sleeping: NO + +dev->set_multicast_list: + Locking: Inside dev->xmit_lock spinlock. + Sleeping: NO + + diff --git a/Documentation/networking/sis900.txt b/Documentation/networking/sis900.txt index 6c26c9927..b6de27947 100644 --- a/Documentation/networking/sis900.txt +++ b/Documentation/networking/sis900.txt @@ -1,468 +1,245 @@ - SiS 900/7016 Fast Ethernet Device Driver - by Ollie Lho (ollie@sis.com.tw) - November 4, 1999. Document Revision: 0.2 - - This document gives some information on installation and usage of SiS - 900/7016 device driver under Linux. - ______________________________________________________________________ - - Table of Contents - - - 1. Introduction - - 2. License - - 3. Changes - - 4. Tested Environment - - 5. Files in This Package - - 6. Installation - - 6.1 Kernel version later than 2.2.11 and 2.3.15 - 6.1.1 Building the driver as loadable module - 6.1.2 Building the driver into kernel - 6.2 Earlier Kernel Version in 2.2.x and 2.3.x Series - - 7. Known Problems and Bugs - - 8. Revision History - - 9. Acknowledgements - - - - ______________________________________________________________________ - - 1. Introduction - - This document describes the revision 1.06 of SiS 900/7016 Fast - Ethernet device driver under Linux. The driver is developed by Silicon - Integrated System Corp. and distributed freely under the GNU General - Public License (GPL). The driver can be compiled as a loadable module - and used under Linux kernel version 2.2.x. With minimal changes, the - driver can also be used under 2.3.x kernel, please see section - ``Installation''. If you are intended to use the driver for earlier - kernels, you are on your own. - - The driver is tested with usual TCP/IP applications including FTP, - Telnet, Netscape etc. and is used constantly by the developers. - - Please send all comments/fixes/questions to Ollie Lho. - - - 2. License - - - - - - - - - - - Copyright (C) 1999 Silicon Integrated System Corp. - - 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 - - - - - - 3. Changes - - Changes made in Revision 1.06 - - 1. Separation of sis900.c and sis900.h in order to move most constant - definition to sis900.h (many of those constants were corrected) - - 2. Clean up PCI detection, the pci-scan from Donald Becker were not - used, just simple pci_find_*. - - 3. MII detection is modified to support multiple mii transceiver. - - 4. Bugs in read_eeprom, mdio_* were removed. - - 5. Lot of sis900 irrelevant comments were removed/changed and more - comments were added to reflect the real situation. - - 6. Clean up of physical/virtual address space mess in buffer - descriptors. - - 7. Better transmit/receive error handling. - - 8. The driver now uses zero-copy single buffer management scheme to - improve performance. - - 9. Names of variables were changed to be more consistent. - - 10. - Clean up of auo-negotiation and timer code. - - 11. - Automatic detection and change of PHY on the fly. - - - 4. Tested Environment - - This driver is developed on the following hardware - - o Intel Celeron 336 with SiS 620 (rev 02) chipset - - o SiS 900 (rev 01) and SiS 7016/7014 Fast Ethernet Card - - and tested with these software environments - - o Red Hat Linux version 6.0 - - o Linux kernel version 2.2.13 - - o Netscape version 4.6 - - o NcFTP 3.0.0 beta 18 - - o Samba version 2.0.3 - - - 5. Files in This Package - - In the package you can find these files: - - - sis900-2.2.x.c - Driver source for kernel 2.2.x - - sis900-2.3.x.c - Driver source for kernel 2.3.x - - sis900.h - Header file for both 2.2.x and 2.3.x kernel - - sis900.sgml - Linux-Doc SGML source of the document - - - 6. Installation - - Silicon Integrated System Corp. is cooperating closely with core Linux - Kernel developers. The revisions of SiS 900 driver are distributed by - the usual 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. - - - 6.1. Kernel version later than 2.2.11 and 2.3.15 - - The driver is bundled in release later than 2.2.11 and 2.3.15 so this - is the most easy case. Be sure you have the appropriate packages for - compiling kernel source. Those packages are listed in - Document/Changes in kernel source distribution. There are two - alternative ways to install the driver - - - 6.1.1. Building the driver as loadable module - - To build the driver as a loadable kernel module you have to - reconfigure the kernel to activate network support by - - - - make config - - - - - Choose "Network Device Support" to "Y" and "Ethernet Support" to "Y". - Then you have to choose "SiS 900 Fast Ethernet Adapter Support" to - "M". - - After reconfiguring the kernel, you can make the driver module by - - - make modules - - - - - The driver should be compiled with no errors. After compiling the - driver, the driver can be installed to proper place by - - - - make modules_install - - - - - Load the driver into kernel by - - - - insmod sis900 - - - - - When loading the driver into memory, some information message can be - view by - - - - dmesg - - - - - or - - - cat /var/log/message - - - - - If the driver is loaded properly you will have messages similar to - this: - - - - 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 - - - - - showing the version of the driver and the results of probing routine. - - Once the driver is loaded, network can be brought up by - - - - /sbin/ifconfig eth0 IPADDR broadcast BROADCAST netmask NETMASK - - - - - - where IPADDR, BROADCAST, NETMASK are your IP address, broadcast - address and netmask respectively. For more information on how to - configure network interface, please refer to Networking HOWTO. - - The link status is also shown by kernel messages. For example, after - the network interface is activated, you may have the message: - - - - eth0: Media Link On 100mbps full-duplex - - - - - If you try to unplug the twist pair (TP) cable you will get - - - - eth0: Media Link Off - - - - - indicating that the link is failed. - - - 6.1.2. Building the driver into kernel - - If you want to make the driver into kernel, choose "Y" rather than "M" - on "SiS 900 Fast Ethernet Adapter Support" when configuring the - kernel. Build the kernel image in the usual way - - - - make dep - - make clean - - make bzlilo - - - - - Next time the system reboot, you have the driver in memory. - - - 6.2. Earlier Kernel Version in 2.2.x and 2.3.x Series - - Installing the driver for earlier kernels in 2.2.x and 2.3.x series - requires a little bit more work. First you have to copy sis900-2.x.x.c - to /usr/src/linux/drivers/net/ and you have to modify some files - manually (sorry !! no patch available !!) - - in Space.c, add - - - extern int sis900_probe(struct device *dev); - - ... - - #ifdef CONFIG_SIS900 - {sis900_probe,0}, - #endif - - - in Config.in add - - - if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - ... //other adapter drivers - tristate 'SiS 900 PCI Fast Ethernet Adapter Support' CONFIG_SIS900 - ... //other adapter drivers - fi - - - - - in Makefile add - - - ifeq ($(CONFIG_SIS900),y) - L_OBJS += sis900.o - else - ifeq ($(CONFIG_SIS900),m) - M_OBJS += sis900.o - endif - endif - - - - - After modifying these files, the driver can be build as described in - the previous section. - - - 7. Known Problems and Bugs - - There are some known problems and bugs. If you find any other bugs - please mail to ollie@sis.com.tw - - 1. AM79C901 HomePNA PHY is not thoroughly tested, there may be some - bugs in the "on the fly" change of transceiver. - - 2. A bug is hidden somewhere in the receive buffer management code, - the bug causes NULL pointer reference in the kernel. This fault is - caught before bad things happen and reported with the message: - - - eth0: NULL pointer encountered in Rx ring, skipping - - - - - which can be viewed with dmesg or cat /var/log/message. - - - 8. Revision History - - - o November 4, 1999, Revision 1.06, Second release, lots of clean up - and optimization. - - o August 8, 1999, Revision 1.05, Initial Public Release - - - 9. Acknowledgements - - This driver was originally derived form Donald Becker's pci-skeleton - and rtl8139 drivers. Donald also provided various suggestion regarded - with improvements made in revision 1.06. - - The 1.05 revision was created by Jim Huang, AMD 79c901 support was - added by Chin-Shan Li. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +SiS 900/7016 Fast Ethernet Device Driver + +Ollie Lho + +Lei Chun Chang + + November 16, 2000. Document Revision: 0.3 + + This document gives some information on installation and usage of SiS + 900/7016 device driver under Linux. + _________________________________________________________________ + _________________________________________________________________ + +Introduction + + This document describes the revision 1.06 and 1.07 of SiS 900/7016 + Fast Ethernet device driver under Linux. The driver is developed by + Silicon Integrated System Corp. and distributed freely under the GNU + General Public License (GPL). The driver can be compiled as a loadable + module and used under Linux kernel version 2.2.x. (rev. 1.06) With + minimal changes, the driver can also be used under 2.3.x and 2.4.x + kernel (rev. 1.07), please see the section called Installation. If you + are intended to use the driver for earlier kernels, you are on your + own. + + The driver is tested with usual TCP/IP applications including FTP, + Telnet, Netscape etc. and is used constantly by the developers. + + Please send all comments/fixes/questions to Lei-Chun Chang. + _________________________________________________________________ + +License + + Copyright (C) 1999 Silicon Integrated System Corp. + + 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 U +SA + _________________________________________________________________ + +Changes + + Changes made in Revision 1.07 + + 1. Separation of sis900.c and sis900.h in order to move most constant + definition to sis900.h (many of those constants were corrected) + 2. Clean up PCI detection, the pci-scan from Donald Becker were not + used, just simple pci_find_*. + 3. MII detection is modified to support multiple mii transceiver. + 4. Bugs in read_eeprom, mdio_* were removed. + 5. Lot of sis900 irrelevant comments were removed/changed and more + comments were added to reflect the real situation. + 6. Clean up of physical/virtual address space mess in buffer + descriptors. + 7. Better transmit/receive error handling. + 8. The driver now uses zero-copy single buffer management scheme to + improve performance. + 9. Names of variables were changed to be more consistent. + 10. Clean up of auo-negotiation and timer code. + 11. Automatic detection and change of PHY on the fly. + 12. Bug in mac probing fixed. + 13. Fix 630E equalier problem by modifying the equalizer workaround + rule. + 14. Support for ICS1893 10/100 Interated PHYceiver. + 15. Support for media select by ifconfig. + _________________________________________________________________ + +Tested Environment + + This driver is developed on the following hardware + + * Intel Celeron 500 with SiS 630 (rev 02) chipset + * SiS 900 (rev 01) and SiS 7016/7014 Fast Ethernet Card + + and tested with these software environments + + * Red Hat Linux version 6.2 + * Linux kernel version 2.4.0 + * Netscape version 4.6 + * NcFTP 3.0.0 beta 18 + * Samba version 2.0.3 + _________________________________________________________________ + +Files in This Package + + In the package you can find these files: + + sis900.c + Driver source file in C + + sis900.h + Header file for sis900.c + + sis900.sgml + DocBook SGML source of the document + + sis900.txt + Driver document in plain text + _________________________________________________________________ + +Installation + + 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 and its mirrors. The 1.06 + revision can be found in kernel version later than 2.3.15 and + pre-2.2.14, and 1.07 revision can be found in kernel version 2.4.0. If + you have no prior experience in networking under Linux, please read + Ethernet HOWTO and Networking HOWTO available from Linux Documentation + Project (LDP). + + The driver is bundled in release later than 2.2.11 and 2.3.15 so this + is the most easy case. Be sure you have the appropriate packages for + compiling kernel source. Those packages are listed in Document/Changes + in kernel source distribution. If you have to install the driver other + than those bundled in kernel release, you should have your driver file + sis900.c and sis900.h copied into /usr/src/linux/drivers/net/ first. + There are two alternative ways to install the driver + _________________________________________________________________ + +Building the driver as loadable module + + To build the driver as a loadable kernel module you have to + reconfigure the kernel to activate network support by + +make menuconfig + + Choose "Loadable module support --->", then select "Enable loadable + module support". + + Choose "Network Device Support --->", select "Ethernet (10 or + 100Mbit)". Then select "EISA, VLB, PCI and on board controllers", and + choose "SiS 900/7016 PCI Fast Ethernet Adapter support" to "M". + + After reconfiguring the kernel, you can make the driver module by + +make modules + + The driver should be compiled with no errors. After compiling the + driver, the driver can be installed to proper place by + +make modules_install + + Load the driver into kernel by + +insmod sis900 + + When loading the driver into memory, some information message can be + view by + +dmesg + + or +cat /var/log/message + + If the driver is loaded properly you will have messages similar to + this: + +sis900.c: v1.07.06 11/07/2000 +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 + + showing the version of the driver and the results of probing routine. + + Once the driver is loaded, network can be brought up by + +/sbin/ifconfig eth0 IPADDR broadcast BROADCAST netmask NETMASK + + where IPADDR, BROADCAST, NETMASK are your IP address, broadcast + address and netmask respectively. For more information on how to + configure network interface, please refer to Networking HOWTO. + + The link status is also shown by kernel messages. For example, after + the network interface is activated, you may have the message: + +eth0: Media Link On 100mbps full-duplex + + If you try to unplug the twist pair (TP) cable you will get + +eth0: Media Link Off + + indicating that the link is failed. + _________________________________________________________________ + +Building the driver into kernel + + If you want to make the driver into kernel, choose "Y" rather than "M" + on "SiS 900/7016 PCI Fast Ethernet Adapter support" when configuring + the kernel. Build the kernel image in the usual way + +make dep + +make clean + +make bzlilo + + Next time the system reboot, you have the driver in memory. + _________________________________________________________________ + +Known Problems and Bugs + + There are some known problems and bugs. If you find any other bugs + please mail to lcchang@sis.com.tw + + 1. AM79C901 HomePNA PHY is not thoroughly tested, there may be some + bugs in the "on the fly" change of transceiver. + 2. A bug is hidden somewhere in the receive buffer management code, + the bug causes NULL pointer reference in the kernel. This fault is + caught before bad things happen and reported with the message: + eth0: NULL pointer encountered in Rx ring, skipping which can be + viewed with dmesg or cat /var/log/message. + _________________________________________________________________ + +Revision History + + * November 13, 2000, Revision 1.07, seventh release, 630E problem + fixed and furthur clean up. + * November 4, 1999, Revision 1.06, Second release, lots of clean up + and optimization. + * August 8, 1999, Revision 1.05, Initial Public Release + _________________________________________________________________ + +Acknowledgements + + This driver was originally derived form Donald Becker's pci-skeleton + and rtl8139 drivers. Donald also provided various suggestion regarded + with improvements made in revision 1.06. + + The 1.05 revision was created by Jim Huang, AMD 79c901 support was + added by Chin-Shan Li. diff --git a/Documentation/networking/tulip.txt b/Documentation/networking/tulip.txt index 5363811cb..bd104e11d 100644 --- a/Documentation/networking/tulip.txt +++ b/Documentation/networking/tulip.txt @@ -1,20 +1,26 @@ Tulip Ethernet Card Driver Maintained by Jeff Garzik <jgarzik@mandrakesoft.com> -The Tulip driver is developed by Donald Becker and changed by +The Tulip driver was developed by Donald Becker and changed by Takashi Manabe and a cast of thousands. +For 2.4.x and later kernels, the Linux Tulip driver is available at +http://sourceforge.net/projects/tulip/ + This driver is for the Digital "Tulip" Ethernet adapter interface. It should work with most DEC 21*4*-based chips/ethercards, as well as with work-alike chips from Lite-On (PNIC) and Macronix (MXIC) and ASIX. - The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O + The author may be reached as becker@scyld.com, or C/O Center of Excellence in Space Data and Information Sciences Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771 - Additional information available at - http://cesdis.gsfc.nasa.gov/linux/drivers/tulip.html - + Additional information on Donald Becker's tulip.c + is available at http://www.scyld.com/network/tulip.html + + + + Theory of Operation Board Compatibility @@ -24,7 +30,7 @@ This device driver is designed for the DECchip "Tulip", Digital's single-chip ethernet controllers for PCI. Supported members of the family are the 21040, 21041, 21140, 21140A, 21142, and 21143. Similar work-alike chips from Lite-On, Macronics, ASIX, Compex and other listed below are also -supported. +supported. These chips are used on at least 140 unique PCI board designs. The great number of chips and board designs supported is the reason for the @@ -43,7 +49,7 @@ Some boards have EEPROMs tables with default media entry. The factory default is usually "autoselect". This should only be overridden when using transceiver connections without link beat e.g. 10base2 or AUI, or (rarely!) for forcing full-duplex when used with old link partners that do not do -autonegotiation. +autonegotiation. Driver operation ================ @@ -142,6 +148,15 @@ tulip_core.c - Driver core (a.k.a. where "everything else" goes) Version history =============== +0.9.11 (November 3, 2000): +* Eliminate extra bus accesses when sharing interrupts (prumpf) +* Barrier following ownership descriptor bit flip (prumpf) +* Endianness fixes for >14 addresses in setup frames (prumpf) +* Report link beat to kernel/userspace via netif_carrier_*. (kuznet) +* Better spinlocking in set_rx_mode. +* Fix I/O resource request failure error messages (DaveM catch) +* Handle DMA allocation failure. + 0.9.10 (September 6, 2000): * Simple interrupt mitigation (via jamal) * More PCI ids diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt index 14af1b886..975cc87eb 100644 --- a/Documentation/networking/x25-iface.txt +++ b/Documentation/networking/x25-iface.txt @@ -62,3 +62,62 @@ link disconnect_confirmation and a disconnect_indication. First Byte = 0x03 LAPB parameters. To be defined. + + + +Possible Problems +================= + +(Henner Eisen, 2000-10-28) + +The X.25 packet layer protocol depends on a reliable datalink service. +The LAPB protocol provides such reliable service. But this reliability +is not preserved by the Linux network device driver interface: + +- With Linux 2.4.x (and above) SMP kernels, packet ordering is not + preserved. Even if a device driver calls netif_rx(skb1) and later + netif_rx(skb2), skb2 might be delivered to the network layer + earlier that skb1. +- Data passed upstream by means of netif_rx() might be dropped by the + kernel if the backlog queue is congested. + +The X.25 packet layer protocol will detect this and reset the virtual +call in question. But many upper layer protocols are not designed to +handle such N-Reset events gracefully. And frequent N-Reset events +will always degrade performance. + +Thus, driver authors should make netif_rx() as reliable as possible: + +SMP re-ordering will not occur if the driver's interrupt handler is +always executed on the same CPU. Thus, + +- Driver authors should use irq affinity for the interrupt handler. + +The probability of packet loss due to backlog congestion can be +reduced by the following measures or a combination thereof: + +(1) Drivers for kernel versions 2.4.x and above should always check the + return value of netif_rx(). If it returns NET_RX_DROP, the + driver's LAPB protocol must not confirm reception of the frame + to the peer. + This will reliably suppress packet loss. The LAPB protocol will + automatically cause the peer to re-transmit the dropped packet + later. + The lapb module interface was modified to support this. Its + data_indication() method should now transparently pass the + netif_rx() return value to the (lapb mopdule) caller. +(2) Drivers for kernel versions 2.2.x should always check the global + variable netdev_dropping when a new frame is received. The driver + should only call netif_rx() if netdev_dropping is zero. Otherwise + the driver should not confirm delivery of the frame and drop it. + Alternatively, the driver can queue the frame internally and call + netif_rx() later when netif_dropping is 0 again. In that case, delivery + confirmation should also be deferred such that the internal queue + cannot grow to much. + This will not reliably avoid packet loss, but the probability + of packet loss in netif_rx() path will be significantly reduced. +(3) Additionally, driver authors might consider to support + CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up + when a previously congested backlog queue becomes empty again. + The driver could uses this for flow-controlling the peer by means + of the LAPB protocol's flow-control service. diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt new file mode 100644 index 000000000..a526ffc67 --- /dev/null +++ b/Documentation/usb/hotplug.txt @@ -0,0 +1,124 @@ +USB HOTPLUGGING + +In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices +into the bus with power on. In most cases, users expect the devices to become +immediately usable. That means the system must do many things, including: + + - Find a driver that can handle the device. That may involve + loading a kernel module; newer drivers can use modutils to + publish their device (and class) support to user utilities. + + - Bind a driver to that device. That's done using the USB + device driver's probe() routine. + + - Tell other subsystems to configure the new device. Print + queues may need to be enabled, networks brought up, disk + partitions mounted, and so on. In some cases these will + be driver-specific actions. + +This involves a mix of kernel mode and user mode actions. Making devices +be immediately usable means that any user mode actions can't wait for an +administrator to do them: the kernel must trigger them, either passively +(triggering some monitoring daemon to invoke a helper program) or +actively (calling such a user mode helper program directly). + +Those triggered actions must support a system's administrative policies; +such programs are called "policy agents" here. Typically they involve +shell scripts that dispatch to more familiar administration tools. + + +KERNEL HOTPLUG HELPER (/sbin/hotplug) + +When you compile with CONFIG_HOTPLUG, you get a new kernel parameter: +/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug". +That parameter names a program which the kernel may invoke at various times. + +The /sbin/hotplug program can be invoked by any subsystem as part of its +reaction to a configuration change, from a thread in that subsystem. +Only one parameter is required: the name of a subsystem being notified of +some kernel event. That name is used as the first key for further event +dispatch; any other argument and environment parameters are specified by +the subsystem making that invocation. + +A reference implementation of a /sbin/hotplug script is available at the +http://www.linux-usb.org website, which works USB for but also knows how to +delegate to any /etc/hotplug/$TYPE.agent policy agent present. + + +USB POLICY AGENT + +The USB subsystem currently invokes /sbin/hotplug when USB devices +are added or removed from system. The invocation is done by the kernel +hub daemon thread [khubd], or else as part of root hub initialization +(done by init, modprobe, kapmd, etc). Its single command line parameter +is the string "usb", and it passes these environment variables: + + ACTION ... "add", "remove" + PRODUCT ... USB vendor, product, and version codes (hex) + TYPE ... device class codes (decimal) + INTERFACE ... interface 0 class codes (decimal) + +If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is +the pathname of the device, and is useful for devices with multiple and/or +alternate interfaces that complicate driver selection. + +Currently available policy agent implementations can load drivers for +modules, and can invoke driver-specific setup scripts. The newest ones +leverage USB modutils support. Later agents might unload drivers. + + +USB MODUTILS SUPPORT + +Current versions of modutils will create a "modules.usbmap" file which +contains the entries from each driver's MODULE_DEVICE_TABLE. Such files +can be used by various user mode policy agents to make sure all the right +driver modules get loaded, either at boot time or later. + +See <linux/usb.h> for full information about such table entries; or look +at existing drivers. Each table entry describes one or more criteria to +be used when matching a driver to a device or class of devices. + +A short example, for a driver that supports several specific USB devices +and their quirks, might have a MODULE_DEVICE_TABLE like this: + + static const struct usb_device_id mydriver_id_table = { + { idVendor: 0x9999, idProduct 0xaaaa, driver_info: QUIRK_X }, + { idVendor: 0xbbbb, idProduct 0x8888, driver_info: QUIRK_Y|QUIRK_Z }, + ... + { } /* end with an all-zeroes entry */ + } + MODULE_DEVICE_TABLE (usb, mydriver_id_table); + +Most USB device drivers should pass these tables to the USB subsystem as +well as to the module management subsystem. Not all, though: some driver +frameworks connect using interfaces layered over USB, and so they won't +need such a "struct usb_driver". + +Drivers that connect directly to the USB subsystem should be declared +something like this: + + static struct usb_driver mydriver = { + name: "mydriver", + id_table: mydriver_id_table, + probe: my_probe, + disconnect: my_disconnect, + + /* + if using the usb chardev framework: + minor: MY_USB_MINOR_START, + fops: my_file_ops, + if exposing any operations through usbdevfs: + ioctl: my_ioctl, + */ + } + +When the USB subsystem knows about a driver's device ID table, it's used when +choosing drivers to probe(). The thread doing new device processing checks +drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and +device descriptors for the device. It will only call probe() if there is a +match, and the third argument to probe() will be the entry that matched. + +If you don't provide an id_table for your driver, then your driver may get +probed for each new device; the third parameter to probe() will be null. + + diff --git a/Documentation/usb/ov511.txt b/Documentation/usb/ov511.txt index 304a1ec90..bc9cad2ab 100644 --- a/Documentation/usb/ov511.txt +++ b/Documentation/usb/ov511.txt @@ -5,22 +5,17 @@ Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC Author: Mark McClelland Homepage: http://alpha.dyndns.org/ov511 -NEW IN THIS VERSION: - o Stability improvements - o Support for hue control - o 160x120 mostly working - o OV6620 color problems fixed - o More WebCam 3 detection improvements - INTRODUCTION: This is a driver for the OV511, a USB-only chip used in many "webcam" devices. Any camera using the OV511/OV511+ and the OV7610/20/20AE CCD should work. It supports streaming and capture of color or monochrome video via the Video4Linux -API. Most V4L apps are compatible with it, but a few videoconferencing programs +API. Most V4L apps are compatible with it, but a few video-conferencing programs do not work yet. The following resolutions are supported: 640x480, 448x336, 384x288, 352x288, and 320x240. +If you need more information, please visit the OV511 homepage at the above URL. + WHAT YOU NEED: - If you want to help with the development, get the chip's specification docs at @@ -81,29 +76,6 @@ 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. -FAQ: -Q: "Why does the picture have noise and look grainy" -A: This is a problem at low light levels, and may be also due to subtle bugs in - the code. The cause is most likely the OV7610 settings we are currently - using. I am looking into this problem. - -Q: "The driver sometimes says `Failed to read OV7610 ID.' What is the deal?" -A: The I2C code that allows the OV511 to communicate with the camera chip is a - bit flaky right now. This message means that the I2C bus never got - initialized properly, and the camera will most likely not work even if you - disable this warning. Try unloading/reloading the driver or unplugging/re- - plugging the camera if this happens. Also try increasing the i2c_detect_tries - parameter (see below). - -Q: "Why do you bother with this phony camera detection crap? It doesn't do - anything useful!" -A: The main purpose of only supporting known camera models is to force people - with new camera models to tell me about them, so I can assemble the list - above, and so the code can know what CCD chip you have. Right now, nearly all - of the cameras use the OV7610 and consequently I have not put support for - other ones in, so the value of the detection code is questionable. Eventually - though, new CCDs might appear and we will be fortunate to have the detection. - MODULE PARAMETERS: You can set these with: insmod ov511 NAME=VALUE @@ -136,7 +108,7 @@ MODULE PARAMETERS: or so lines higher than the red component. This is only apparent in images with white objects on black backgrounds at 640x480. Setting this to 1 will realign the color planes correctly. NOTE: This is still - experimental and very buggy. You will likely need a fast (500 Mhz) CPU. + experimental and very buggy. You will likely need a fast (500 MHz) CPU. NAME: snapshot TYPE: integer (boolean) @@ -203,15 +175,21 @@ MODULE PARAMETERS: DESC: Prevent apps from timing out if frame is not done in time. This is useful if you are having problems with Xawtv getting "stuck" on a frame when your system is under heavy load. - + + NAME: sensor_gbr + TYPE: boolean + DEFAULT: 0 + DESC: This makes the sensor output GBR422 instead of YUV420. This saves the + driver the trouble of converting YUV to RGB, but it currently does not + work very well (the colors are not quite right) + WORKING FEATURES: - o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, 320x240, and - 160x120 - o RGB24, YUV420, YUV422, YUYV, and YUV422P color + o Color streaming/capture at 640x480, 448x336, 384x288, 352x288, and 320x240 + o RGB24, RGB565, YUV420, YUV422, YUYV, and YUV422P color o Monochrome o Setting/getting of saturation, contrast, brightness, and hue (only some of them work the OV7620 and OV7620AE) - o proc status reporting + o /proc status reporting EXPERIMENTAL FEATURES: o fix_rgb_offset: Sometimes works, but other times causes errors with xawtv and @@ -219,6 +197,7 @@ EXPERIMENTAL FEATURES: o Snapshot mode (only works with some read() based apps; see below for more) o OV6620 sensor support o GBR422 parsing + o 160x120 TODO: o Fix the noise / grainy image problem. @@ -227,18 +206,19 @@ TODO: 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. o YUV422 - o Get snapshot mode working with mmap(). o Fix fixFrameRGBoffset(). It is not stable yet with streaming video. - o Get autoadjust disable working o V4L2 support (Probably not until it goes into the kernel) - o Creative WebCam III has problems initializing its sensor. This should be - fixed now, but if you still have problems let me know. o Get rid of the memory management functions (put them in videodev.c??) o Setting of contrast and brightness not working with 7620/7620AE o Driver/camera state save/restore for when USB supports suspend/resume o Unstable on SMP systems o OV7620/OV6620 experience frame corruption with moving objects o OV6620 is too dark + o 176x144 support + o Driver sometimes hangs upon close() with OHCI + o The image should always be written properly to the mmap'ed buffer as long as + the requested image size is at least the minimum size. This will likely + require a rewrite of all the parsing code. HOW TO CONTACT ME: diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 4ffe021a7..a6efeefa5 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -151,6 +151,37 @@ Digi AccelePort Driver driver. +Belkin USB Serial Adapter F5U103 + + Single port DB-9/PS-2 serial adapter from Belkin with firmware by eTEK Labs. + +Current status: + The following have been tested and work: + Baud rate 300-230400 + Data bits 5-8 + Stop bits 1-2 + Parity N,E,O,M,S + Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)* + Break Set and clear + Line contrl Input/Output query and control ** + + * Hardware input flow control is only enabled for firmware + levels above 2.06. Read source code comments describing Belkin + firmware errata. Hardware output flow control is working for all + firmware versions. + ** Queries of inputs (CTS,DSR,CD,RI) show the last + reported state. Queries of outputs (DTR,RTS) show the last + requested state and may not reflect current state as set by + automatic hardware flow control. + +TO DO List: + -- Add true modem contol line query capability. Currently tracks the + states reported by the interrupt and the states requested. + -- Add error reporting back to application for UART error conditions. + -- Add support for flush ioctls. + -- Add everything else that is missing :) + + Generic Serial driver If your device is not one of the above listed devices, compatible with diff --git a/Documentation/video4linux/bttv/CARDLIST b/Documentation/video4linux/bttv/CARDLIST index 0d36761d1..f513ebb48 100644 --- a/Documentation/video4linux/bttv/CARDLIST +++ b/Documentation/video4linux/bttv/CARDLIST @@ -48,6 +48,11 @@ bttv.o card=46 - Zoltrix Genie TV card=47 - Terratec TV/Radio+ card=48 - Dynalink Magic TView + card=49 - GV-BCTV3 + card=50 - Prolink PV-BT878P+4E (PixelView PlayTV PAK) + card=51 - Eagle Wireless Capricorn2 (bt878A) + card=52 - Pinnacle Studio PCTV Pro + card=53 - Typhoon TView RDS tuner.o type=0 - Temic PAL @@ -65,3 +70,4 @@ tuner.o type=12 - Alps TSBE5 type=13 - Alps TSBC5 type=14 - Temic 4006FH5 + type=15 - Alps TSCH6 diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index 68818a532..4cb55586d 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options @@ -23,11 +23,19 @@ bttv.o at the hardware). default is 1. bttv_debug=0/1 debug messages (for capture). default is 0 (off). + irq_debug=0/1 irq handler debug messages. + default is 0 (off). gbuffers=2-64 number of capture buffers for mmap'ed capture. default is 2. gbufsize= size of capture buffers. default and maximum value is 0x208000 (~2MB) + bttv_gpio=0/1 + gpiomask= + audioall= + audiomux= + See Sound-FAQ for a detailed description. + remap, card, radio and pll accept up to four comma-separated arguments (for multiple boards). @@ -54,6 +62,19 @@ tvaudio.o new, experimental module which is supported to provide a single driver for all simple i2c audio control chips (tda/tea*). + insmod args: + tda8425 = 1 enable/disable the support for the + tda9840 = 1 various chips. + tda9850 = 1 The tea6300 can't be autodetected and is + tda9855 = 1 therefore off by default, if you have + tda9873 = 1 this one on your card (STB uses these) + tea6300 = 0 you have to enable it explicitly. + tea6420 = 1 The two tda985x chips use the same i2c + pic16c54 = 1 address and can't be disturgished from + each other, you might have to disable + the wrong one. + debug = 1 print debug messages + msp3400.o The driver for the msp34xx sound processor chips. If you have a stereo card, you probably want to insmod this one. @@ -72,7 +93,7 @@ msp3400.o should improve things for french people, the carrier autoscan seems to work with FM only... -tea6300.o +tea6300.o - OBSOLETE (use tvaudio instead) 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 @@ -81,7 +102,7 @@ tea6300.o insmod args: debug=1 print some debug info to the syslog. -tda8425.o +tda8425.o - OBSOLETE (use tvaudio instead) 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. @@ -89,7 +110,7 @@ tda8425.o insmod args: debug=1 print some debug info to the syslog. -tda985x.o +tda985x.o - OBSOLETE (use tvaudio instead) The driver for the tda9850/55 audio chips. insmod args: diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README index 868feedb9..bce7e55ee 100644 --- a/Documentation/video4linux/bttv/README +++ b/Documentation/video4linux/bttv/README @@ -1,4 +1,8 @@ +IMPORTANT: Don't send me mails with images attached unless I ask you +to do so. Mails with images attached will go to /dev/null unseen. + + Release notes for bttv-0.7.x ============================ @@ -17,7 +21,7 @@ CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m The latest bttv version is available here: - http://me.in-berlin.de/~kraxel/bttv.html + http://www.strusel007.de/linux/bttv/ You'll find Ralphs original (mostly outdated) documentation in the ralphs-doc subdirectory. @@ -38,6 +42,8 @@ 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 ;-) +Note that you have to turn on video4linux support (CONFIG_VIDEO_DEV) +in the kernel to get the videodev.o module which is required by bttv. Make bttv work with your card @@ -66,7 +72,8 @@ 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. +If your card isn't listed in CARDLIST or if you have trouble making +audio work, you should read the Sound-FAQ. Still doesn't work? diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ index ce8895700..64611f497 100644 --- a/Documentation/video4linux/bttv/Sound-FAQ +++ b/Documentation/video4linux/bttv/Sound-FAQ @@ -8,12 +8,12 @@ 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: +bttv-cards.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) + bttv0: model: BT848(Hauppauge old) [autodetected] 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 @@ -32,7 +32,7 @@ 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... +mixer settings too. ALSA for example has everything muted by default. How sound works in detail @@ -48,42 +48,64 @@ 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 +Most 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. +receiver chips. Some boards use the i2c bus instead of the gpio pins +to connect the mux chip. 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: +line for your board. The important fields are these two: 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) */ + u32 audiomux[5]; /* audio mux: tuner, radio, external, internal, mute */ }; -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). +gpiomask specifies which pins are used to control the audio mux chip. +The corresponding bits in the output enable register +(BT848_GPIO_OUT_EN) will be set as these pins must be driven by the +bt848 chip. + +The audiomux[] array holds the data values for the different inputs +(i.e. which pins must be high/low for tuner/mute/...). This will be +written to the data register (BT848_GPIO_DATA) to switch the audio +mux. + 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... +from ftp://telepresence.dmem.strath.ac.uk/pub/bt848/winutil (doesn't +work with bt878 boards according to some reports I received). You +might also dig around in the *.ini files of the Windows applications. +You can have a look at the board to see which of the gpio pins are +connected at all and then start trial-and-error ... + + +Starting with release 0.7.41 bttv has a number of insmod options to +make the gpio debugging easier: + +bttv_gpio=0/1 enable/disable gpio debug messages +gpiomask=n set the gpiomask value +audiomux=i,j,... set the values of the audiomux array +audioall=a set the values of the audiomux array (one + value for all array elements, useful to check + out which effect the particular value has). + +The messages printed with bttv_gpio=1 look like this: + + bttv0: gpio: en=00000027, out=00000024 in=00ffffd8 [audio: off] + +en = output _en_able register (BT848_GPIO_OUT_EN) +out = _out_put bits of the data register (BT848_GPIO_DATA), + i.e. BT848_GPIO_DATA & BT848_GPIO_OUT_EN +in = _in_put bits of the data register, + i.e. BT848_GPIO_DATA & ~BT848_GPIO_OUT_EN Good luck, diff --git a/Documentation/video4linux/bttv/Specs b/Documentation/video4linux/bttv/Specs new file mode 100644 index 000000000..79b9e576f --- /dev/null +++ b/Documentation/video4linux/bttv/Specs @@ -0,0 +1,3 @@ +Philips http://www.Semiconductors.COM/pip/ +Conexant http://www.conexant.com/techinfo/default.asp +Micronas http://www.micronas.de/pages/product_documentation/index.html |