Initial revision

15 files changed, 855 insertions, 173 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 09d482dac..63466ffd5 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -26,6 +26,8 @@ devices.txt
 	- plain ASCII listing of all the nodes in /dev/ with major minor #'s
 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.
 exception.txt
 	- how linux v2.1 handles exceptions without verify_area etc.
 ez.txt
diff --git a/Documentation/Changes b/Documentation/Changes
index 3b1fed283..0b840fee6 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -29,7 +29,7 @@ English-language HTML version.
    Also, don't forget http://www.linuxhq.com/ for all your Linux kernel
 needs.
 
-Last updated: April 17, 1997.
+Last updated: May 12, 1997.
 Current Author: Chris Ricker (gt1355b@prism.gatech.edu).
 
 Current Minimal Requirements
@@ -40,16 +40,16 @@ encountered a bug!
 
 - Kernel modules	 modutils-2.1.34
 - Gnu C 		 2.7.2.1
-- Binutils		 2.7.0.9
+- Binutils		 2.8.0.3
 - Linux C Library	 5.4.23
 - Dynamic Linker (ld.so) 1.8.5
 - Linux C++ Library	 2.7.2.1
 - Procps		 1.01
-- Mount                  2.6e
-- Net-tools              1.32-alpha
+- Mount                  2.6g
+- Net-tools              1.41
 - Loadlin                1.6a
 - Sh-utils               1.16
-- Autofs                 970409
+- Autofs                 0.3.0
 - NFS                    0.4.21
 
 Upgrade notes
@@ -131,6 +131,9 @@ presence.
    To run bootpd, you'll need to issue the following command:   echo 1
 >/proc/sys/net/ipv4/ip_boot_agent
 
+   For support for new features like IPv6, upgrade to the latest
+net-tools.
+
 Mount and network file systems
 ==============================
 
@@ -179,8 +182,7 @@ How to know the version of the installed programs
 *************************************************
 
    There are some simple methods useful to know the version of the
-installed programs and libraries.  The SysVinit version display
-requires that you be logged in as root.
+installed programs and libraries.
 
 Binutils: ld -v
 Gnu C: gcc -v or gcc --version
@@ -190,6 +192,7 @@ Libc: ls -l /lib/libc.so.*
 Libc++: ls -l /usr/lib/libg++.so.*
 Modutils: insmod -V
 Mount: mount --version
+Net-tools:  hostname -V
 Procps: ps --version
 RPM:  rpm --version
 Sh-utils:  expr --v
@@ -200,12 +203,12 @@ Where to get the files
 Binutils
 ========
 
-The 2.7.0.9 release:
-ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.7.0.9.bin.tar.gz
-ftp://sunsite.unc.edu/pub/Linux/GCC/binutils-2.7.0.9.bin.tar.gz
+The 2.8.0.3 release:
+ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.0.3.bin.tar.gz
+ftp://sunsite.unc.edu/pub/Linux/GCC/binutils-2.8.0.3.bin.tar.gz
 Installation notes:
-ftp://tsx-11.mit.edu/pub/linux/packages/GCC/release.binutils-2.7.0.9
-ftp://sunsite.unc.edu/pub/Linux/GCC/release.binutils-2.7.0.9
+ftp://tsx-11.mit.edu/pub/linux/packages/GCC/release.binutils-2.8.0.3
+ftp://sunsite.unc.edu/pub/Linux/GCC/release.binutils-2.8.0.3
 
 Gnu C
 =====
@@ -295,14 +298,14 @@ ftp://prep.ai.mit.edu/pub/gnu/sh-utils-1.16.tar.gz
 Mount
 =====
 
-The 2.6e release:
-ftp://ftp.win.tue.nl/pub/linux/util/mount-2.6e.tar.gz
+The 2.6g release:
+ftp://ftp.win.tue.nl/pub/linux/util/mount-2.6g.tar.gz
 
 Autofs
 ======
 
-The 970409 release:
-ftp://ftp.kernel.org/pub/linux/daemons/autofs/autofs-970409.tar.gz
+The 0.3.0 release:
+ftp://ftp.kernel.org/pub/linux/daemons/autofs/autofs-0.3.0.tar.gz
 
 NFS
 ===
@@ -311,6 +314,13 @@ The 0.4.21 release:
 ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/linux-nfs-0.4.21.tar.gz
 ftp://linux.nrao.edu/pub/people/okir/linux-nfs-0.4.21.tar.gz
 
+Net-tools
+=========
+
+The 0.41 release:
+ftp://ftp.london.uk.eu.org/pub/ipv6/net-tools-1.41.tar.gz
+ftp://ftp.cs-ipv6.lancs.ac.uk/pub/Code/Linux/Net_Tools/net-tools-1.41.tar.gz
+
 Other Info
 ==========
 
diff --git a/Documentation/Configure.help b/Documentation/Configure.help
index 469fb2e02..746b2c534 100644
--- a/Documentation/Configure.help
+++ b/Documentation/Configure.help
@@ -2072,6 +2072,20 @@ CONFIG_SCSI_NCR53C406A
   and read Documentation/modules.txt. The module will be called
   NCR53c406.o.
 
+Tekram DC390W/U/F (T) SCSI support
+CONFIG_SCSI_DC390W
+  This driver supports the Tekram DC390W/U/F (T) PCI SCSI host adapters with
+  the NCR/Symbios 53c825/875 chips. If you have a DC390 (T) adaptor with the 
+  Am53C974A chip use the DC390(T) driver.
+
+Tekram DC390(T) (AMD PCscsi) SCSI support
+CONFIG_SCSI_DC390T
+  This driver supports the Tekram DC390(T) PCI SCSI Hostadapter with
+  the Am53C974A chip, and perhaps other cards using the same chip.
+  
+  This driver does _not_ support the DC390W/U/F adaptor with the 
+  NCR/Symbios chips.
+
 AM53/79C974 PCI SCSI support
 CONFIG_SCSI_AM53C974
   This is support for the AM53/79C974 SCSI host adapters. Please read
@@ -4036,6 +4050,16 @@ CONFIG_SERIAL_CONSOLE
   N here so that they can use the serial port for modem, mouse or some
   other device.
 
+Digi Intl. epca support
+CONFIG_DIGIEPCA
+  This is a driver for Digi Internationals Xx, Xeve, and Xem 
+  series of cards.  This driver supports the original PC (ISA) boards as
+  well as PCI, and EISA.  If you have a card like this, say Y here and read
+  the file Documentation/digiepca.txt.  NOTE: This driver is seperate from
+  the driver written and copyrighted by Troy De Jongh.  Because they both
+  attempt (In some cases) to access the same hardware only one of these
+  drivers (CONFIG_DIGIEPCA or CONFIG_DIGI) should be selected.
+
 Digiboard PC/Xx Support
 CONFIG_DIGI
   This is a driver for the Digiboard PC/Xe, PC/Xi, and PC/Xeve cards
@@ -4626,6 +4650,40 @@ CONFIG_ACI_MIXER
   also controls the radio tuner on this card, however this is not
   yet supported in this software.
 
+Gallant's Audio Excel DSP 16 support (SC-6000 and SC-6600)
+CONFIG_AEDSP16
+  Answer Y if you have a Gallant's Audio Excel DSP 16 card. This card
+  emulate an SBPro or a Microsoft Sound System card.
+  You must select one of the Sound Blaster or Microsoft Sound System
+  drivers before select this menu item.
+  Read the drivers/sound/lowlevel/README.aedsp16 file and the head of
+  drivers/sound/lowlevel/aedsp16.c to have more informations about
+  this driver and its configuration.
+
+  If you are changing the card configuration, please, undefine all
+  the old Audio Excel parameters because leaving it defined while
+  selecting the alternate emulation, may screw up your .config file.
+
+  !!!NOTE!!!
+  The driver supports Audio Excel DSP 16 but not the III version of
+  this card. Read drivers/sound/lowlevel/Readme.aedsp16 if you want
+  to know something more on how to use the III version with this sound
+  driver.
+
+SC-6600 based audio cards (new Audio Excel DSP 16)
+CONFIG_SC6600
+  The SC6600 is the new version of DSP mounted on the Audio Excel DSP 16
+  cards. Check the FCC ID of your audio card and answer Y if you have an
+  SC6600 DSP.
+
+Audio Excel DSP 16 (MSS emulation)
+CONFIG_AEDSP16_MSS
+  Answer Y if you want your audio card emulate Microsoft Sound System.
+
+Audio Excel DSP 16 (SBPro emulation)
+CONFIG_AEDSP16_SBPRO
+  Answer Y if you want your audio card emulate Sound Blaster Pro.
+
 Kernel profiling support
 CONFIG_PROFILE
   This is for kernel hackers who want to know how much time the kernel
@@ -4918,9 +4976,13 @@ CONFIG_RMW_INSNS
 Amiga AutoConfig Identification
 CONFIG_ZORRO
   This enables support for automatic identification of Amiga expansion
-  cards that obey the AutoConfig(tm) specification.  You should say Y
-  to this question unless you have no expansion cards and no intention
-  of getting any.
+  cards that obey the AutoConfig(tm) specification.
+  Say Y if you want your expansion cards to be identified on bootup;
+  it will enlarge your kernel by about 10KB. The identification
+  information is also available through /proc/zorro (say Y to
+  "/proc filesystem support"!).
+  Note that even if you say N here, you can still use your expansion
+  cards. If in doubt, say Y.
 
 Amiga OCS chipset support
 CONFIG_AMIFB_OCS
@@ -4948,6 +5010,8 @@ CONFIG_FB_CYBER
   Please note that its use is not all that intuitive (i.e. if you have
   any questions, be sure to ask!).  Say N unless you have a Cybervision
   64 or plan to get one before you next recompile the kernel.
+  Please note that this driver DOES NOT support the Cybervision 64 3D
+  card at present, as they use incompatible video chips.
 
 Amiga GSP (TMS340x0) support
 CONFIG_AMIGA_GSP
@@ -5188,6 +5252,16 @@ CONFIG_ATARI_MIDI
   want). If you want to compile it as a module, say M here and read
   Documentation/modules.txt.
 
+Atari DSP56k Digital Signal Processor support
+CONFIG_ATARI_DSP56K
+  If you want to be able to use the DSP56001 in Falcons, say Y.
+  This driver is still experimental, and if you don't know what it is,
+  or if you don't have this processor, just say N.
+  This driver is also available as a module ( = code which can be inserted
+  in and removed from the running kernel whenever you want). If you
+  want to compile it as a module, say M here and read
+  Documentation/modules.txt.
+
 Amiga builtin serial support
 CONFIG_AMIGA_BUILTIN_SERIAL
   If you want to use your Amiga's built-in serial port in Linux, say
@@ -5317,7 +5391,7 @@ CONFIG_MSDOS_PARTITION
 # LocalWords:  mgetty sendfax gert greenie muc lowlevel Lasermate LanManager io
 # LocalWords:  OOPSes trackball binghamton mobileip ncr IOMAPPED settags ns ser
 # LocalWords:  setsync NEGO MPARITY autotuning prefetch PIIX cdwrite utils rc
-# LocalWords:  PCWATCHDOG berkprod bitgate boldt ucsb jf kyoto jp euc Tetsuyasu
+# LocalWords:  PCWATCHDOG berkprod bitgate boldt ucsb jf kyoto jp euc Tetsuyasu 
 # LocalWords:  YAMADA tetsu cauchy nslab ntt nevod perm su doc kaf kheops wsc
 # LocalWords:  traduc Bourgin dbourgin helptext menuconfig kfill READMEs HOWTOs
 # LocalWords:  IDEDISK IDEFLOPPY EIDE firewalls QMAGIC ZMAGIC LocalWords opti
diff --git a/Documentation/devices.tex b/Documentation/devices.tex
index 80dc0f9de..f20ca8c39 100644
--- a/Documentation/devices.tex
+++ b/Documentation/devices.tex
@@ -15,6 +15,7 @@
 %
 \begin{document}
 \newcommand{\file}{\tt}			% Style to use for a filename
+\newcommand{\url}{\it}		        % Style to use for an URL
 \newcommand{\hex}{\tt}			% Style to use for a hex number
 \newcommand{\ud}{(Under development)}	% Abbreviation
 \newcommand{\1}{\({}^1\)}
@@ -46,7 +47,7 @@ foo \kill}%
 %
 \title{{\bf Linux Allocated Devices}}
 \author{Maintained by H. Peter Anvin $<$hpa@zytor.com$>$}
-\date{Last revised: April 7, 1997}
+\date{Last revised: May 20, 1997}
 \maketitle
 %
 \noindent
@@ -60,17 +61,19 @@ sources in \LaTeX\ and ASCII form.  In case of discrepancy, the
 \LaTeX\ version is authoritative.
 
 This document is included by reference into the Linux Filesystem
-Standard (FSSTND).  The FSSTND is available via FTP from
-tsx-11.mit.edu in the directory {\file
-/pub/linux/docs/linux-standards/fsstnd}.
+Standard (FSSTND).  The FSSTND is available from
+{\url ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/}.
 
 To have a major number allocated, or a minor number in situations
 where that applies (e.g.\ busmice), please contact me with the
-appropriate device information.  Also, if you have additional
-information regarding any of the devices listed below, or if I have
-made a mistake, I would greatly appreciate a note.  When sending me
-mail, {\em please\/} include the word ``device'' in the subject so
-your mail won't accidentally get buried!
+appropriate device information.  I *very* much appreciate if you send
+me a device description in the same format as the ones already in this
+file.  Also, if you have additional information regarding any of the
+devices listed below, or if I have made a mistake, I would greatly
+appreciate a note.
+
+NOTE: When sending me mail, {\em please\/} include the word ``device''
+in the subject so your mail won't accidentally get buried!
 
 Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga
 platform only.  Allocations marked (68k/Atari) apply to Linux/68k on
@@ -207,7 +210,10 @@ reply.
 \major{79}{}{char }{PAM Software's multimodem boards -- alternate devices}
 \major{80}{}{char }{Photometrics AT200 CCD camera}
 \major{81}{}{char }{Brooktree Bt848 frame grabbers}
-\major{82}{--119}{}{Unallocated}
+\major{82}{}{char }{WiNRADiO communications receiver card}
+\major{83}{}{char }{Teletext/videotext interfaces}
+\major{84}{}{char }{Ikon 1011[57] Versatec Greensheet Interface}
+\major{85}{--119}{}{Unallocated}
 \major{120}{--127}{}{Local/experimental use}
 \major{128}{--239}{}{Unallocated}
 \major{240}{--254}{}{Local/experimental use}
@@ -487,6 +493,7 @@ physical disks.
 	\minor{6}{/dev/sunmouse}{Sun mouse}
 	\minor{7}{/dev/amigamouse1}{Second Amiga mouse}
 	\minor{8}{/dev/smouse}{Simple serial mouse driver}
+	\minor{9}{/dev/pc110pad}{IBM PC-110 digitizer pad}
 	\minor{128}{/dev/beep}{Fancy beep device}
 	\minor{129}{/dev/modreq}{Kernel module load request}
 	\minor{130}{/dev/watchdog}{Watchdog timer port}
@@ -1243,7 +1250,7 @@ $<$jth@prosig.demon.co.uk$>$ for information.
 \end{devicelist}
 
 \noindent
-See {\em http://www.coda.cs.cmu.edu\/} for information about Coda.
+See {\url http://www.coda.cs.cmu.edu\/} for information about Coda.
 
 \begin{devicelist}
 \major{68}{}{char }{CAPI 2.0 interface}
@@ -1392,7 +1399,34 @@ Currently for Dolphin Interconnect Solutions' PCI-SCI bridge.
 \end{devicelist}
 
 \begin{devicelist}
-\major{82}{--119}{}{Unallocated}
+\major{82}{}{char }{WiNRADiO communications receiver card}
+	\major{0}{/dev/winradio0}{First WiNRADiO card}
+	\major{1}{/dev/winradio1}{Second WiNRADiO card}
+	\minordots
+\end{devicelist}
+
+\noindent
+The driver and documentation may be obtained from
+{\url http://www.proximity.com.au/~brian/winradio/\/}.
+
+\begin{devicelist}
+\major{83}{}{char }{Teletext/videotext interfaces}
+        \minor{0}{/dev/vtx}{Teletext decoder}
+        \minor{16}{/dev/vttuner}{TV tuner on teletext interface}
+\end{devicelist}
+
+\noindent
+Devices for the driver contained in the VideoteXt package. More information
+on {\url http://home.pages.de/~videotext/\/}.
+
+\begin{devicelist}
+\major{84}{}{char }{Ikon 1011[57] Versatec Greensheet Interface}
+	\minor{0}{/dev/ihcp0}{First Greensheet port}
+	\minor{1}{/dev/ihcp1}{Second Greensheet port}
+\end{devicelist}
+
+\begin{devicelist}
+\major{85}{--119}{}{Unallocated}
 \end{devicelist}
 
 \begin{devicelist}
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 17a99de95..cff94ac65 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -1,7 +1,7 @@
 		       LINUX ALLOCATED DEVICES
 	     Maintained by H. Peter Anvin <hpa@zytor.com>
 
-		     Last revised: April 7, 1997
+		      Last revised: May 20, 1997
 
 This list is the successor to Rick Miller's Linux Device List, which
 he stopped maintaining when he got busy with other things in 1993.  It
@@ -18,11 +18,14 @@ tsx-11.mit.edu in the directory /pub/linux/docs/linux-standards/fsstnd.
 
 To have a major number allocated, or a minor number in situations
 where that applies (e.g. busmice), please contact me with the
-appropriate device information.  Also, if you have additional
-information regarding any of the devices listed below, or if I have
-made a mistake, I would greatly appreciate a note.  When sending me
-mail, *please* include the word "device" in the subject so your mail
-won't accidentally get buried!
+appropriate device information.  I *very* much appreciate if you send
+me a device description in the same format as the ones already in this
+file.  Also, if you have additional information regarding any of the
+devices listed below, or if I have made a mistake, I would greatly
+appreciate a note.
+
+NOTE: When sending me mail, *please* include the word "device" in the
+subject so your mail won't accidentally get buried!
 
 Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga
 platform only.  Allocations marked (68k/Atari) apply to Linux/68k on
@@ -270,6 +273,7 @@ reply.
 		  6 = /dev/sunmouse	Sun mouse
 		  7 = /dev/amigamouse1	Second Amiga mouse
 		  8 = /dev/smouse	Simple serial mouse driver
+		  9 = /dev/pc110pad	IBM PC-110 digitizer pad
 		128 = /dev/beep		Fancy beep device
 		129 = /dev/modreq	Kernel module load request
 		130 = /dev/watchdog	Watchdog timer port
@@ -979,7 +983,26 @@ reply.
 		 33 = /dev/bttv-vbi1	VBI data of second Bt848 card
 		      ...
 
- 82-119		UNALLOCATED
+ 82 char	WiNRADiO communications receiver card
+		  0 = /dev/winradio0	First WiNRADiO card
+		  1 = /dev/winradio1	Second WiNRADiO card
+		      ...
+
+		The driver and documentation may be obtained from
+                http://www.proximity.com.au/~brian/winradio/
+
+ 83 char	Teletext/videotext interfaces
+                  0 = /dev/vtx          Teletext decoder
+                 16 = /dev/vttuner      TV tuner on teletext interface
+
+                Devices for the driver contained in the VideoteXt package.
+                More information on http://home.pages.de/~videotext/
+
+ 84 char	Ikon 1011[57] Versatec Greensheet Interface
+                  0 = /dev/ihcp0        First Greensheet port
+                  1 = /dev/ihcp1        Second Greensheet port
+
+ 85-119		UNALLOCATED
 
 120-127		LOCAL/EXPERIMENTAL USE
 
diff --git a/Documentation/digiepca.txt b/Documentation/digiepca.txt
new file mode 100644
index 000000000..9904afb39
--- /dev/null
+++ b/Documentation/digiepca.txt
@@ -0,0 +1,96 @@
+The Digi Intl. epca driver. 
+----------------------------
+The Digi Intl. epca driver for Linux supports the following boards:
+
+Digi PC/Xem, PC/Xr, PC/Xe, PC/Xi, PC/Xeve 
+Digi EISA/Xem, PCI/Xem, PCI/Xr 
+
+Limitations:
+------------
+Currently the driver only autoprobes for supported PCI boards. 
+
+The Linux MAKEDEV command does not support generating the Digiboard
+Devices.  Users executing digiConfig to setup EISA and PC series cards
+will have their device nodes automaticly constructed (cud?? for ~CLOCAL,
+and ttyD?? for CLOCAL).  Users wishing to boot their board from the LILO
+prompt, or those users booting PCI cards may use buildDIGI to construct 
+the necessary nodes. 
+
+Notes:
+------
+This driver may be configured via LILO.  For users who have already configured
+their driver using digiConfig, configuring from lilo will override previous 
+settings.  Multiple boards may be configured by issuing multiple LILO command 
+lines.  For examples see the bottom of this document.
+
+Device names start at 0 and continue up.  Beware of this as previous Digi 
+drivers started device names with 1.
+
+PCI boards are auto-detected and configured by the driver.  PCI boards will
+be allocated device numbers (internally) begining with the lowest PCI slot
+first.  In other words a PCI card in slot 3 will always have higher device
+nodes than a PCI card in slot 1. 
+
+LILO config examples:
+---------------------
+Using LILO's APPEND command, a string of comma separated identifiers or 
+integers can be used to configure supported boards.  The six values in order 
+are:
+
+   Enable/Disable this card or Override,
+   Type of card: PC/Xe (AccelePort) (0), PC/Xeve (1), PC/Xem or PC/Xr (2), 
+                 EISA/Xem (3), PC/64Xe (4), PC/Xi (5), 
+   Enable/Disable alternate pin arrangement,
+   Number of ports on this card,
+   I/O Port where card is configured (in HEX if using string identifiers),
+   Base of memory window (in HEX if using string identifiers), 
+
+NOTE : PCI boards are auto-detected and configured.  Do not attempt to 
+configure PCI boards with the LILO append comand.  If you wish to override
+previous configuration data (As set by digiConfig), but you do not wish to
+configure any specific card (Example if there are PCI cards in the system) 
+the following override command will accomplish this:
+-> append="digi=2"
+
+Samples:
+   append="digiepca=E,PC/Xe,D,16,200,D0000"
+                  or
+   append="digi=1,0,0,16,512,851968"
+
+Supporting Tools:
+-----------------
+Supporting tools include digiDload, digiConfig, buildPCI, and ditty.  See
+/usr/src/linux/Documentation/README.epca.dir/user.doc for more details.  Note,
+this driver REQUIRES that digiDload be executed prior to it being used. 
+Failure to do this will result in an ENODEV error.
+
+The latest version of the tool package is available at:
+ftp://ftp.dgii.com/drivers/linux/released/async/
+
+Documentation:
+--------------
+Complete documentation for this product may be found in the tool package. 
+
+Sources of information and support:
+-----------------------------------
+Digi Intl. support site for this product:
+-> digilnux@dgii.com 
+
+Related information and information concerning other drivers supporting 
+Digi Intl. products:
+
+-> FTP: ftp://dgii.com
+-> Webpage: http://www.dgii.com
+-> Webpage: http://private.fuller.edu/clameter/digi.html
+-> Mailing List: digiboard@list.fuller.edu  Note write e-mail to subscribe
+   common ListServ commands will not work.
+
+Acknowledgments:
+----------------
+Much of this work (And even text) was derived from a similar document 
+supporting the original public domain DigiBoard driver Copyright (C)
+1994,1995 Troy De Jongh.  Many thanks to Christoph Lameter 
+(clameter@fuller.edu) and Mike McLagan (mike.mclagan@linux.org) who authored 
+and contributed to the original document. 
+
+
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 4e1eba41e..7d86d3168 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -1,5 +1,5 @@
 Ioctl Numbers
-5 Apr 1997
+10 Apr 1997
 Michael Chastain
 <mec@shout.net>
 
@@ -87,6 +87,8 @@ Code	Seq#	Include File		Comments
 'W'	28-2F	linux/iso16-relay.h	in development
 'Y'	all	linux/cyclades.h
 'a'	all	various, see http://lrcwww.epfl.ch/linux-atm/magic.html
+'b'	00-3F	bit3 vme host bridge	in development:
+					<mailto:natalia@nikhefk.nikhef.nl>
 'c'	all	linux/comstats.h
 'f'	all	linux/ext2_fs.h
 'l'	00-3F	linux/tcfs_fs.h		in development:
@@ -94,7 +96,8 @@ Code	Seq#	Include File		Comments
 'm'	all	linux/mtio.h		conflict!
 'm'	all	linux/soundcard.h	conflict!
 'n'	all	linux/ncp_fs.h
-'p'	all	linux/mc146818rtc.h
+'p'	00-3F	linux/mc146818rtc.h
+'p'	40-7F	linux/nvram.h
 'r'	all	linux/msdos_fs.h
 's'	all	linux/cdk.h
 't'	00-7F	linux/if_ppp.h
@@ -108,8 +111,9 @@ Code	Seq#	Include File		Comments
 0x89	F0-FF	linux/sockios.h		SIOCDEVPRIVATE range
 0x8B	all	linux/wireless.h
 0x8C	00-3F	WiNRADiO driver		in development:
-					<mailto:brian@proximity.com.au>
+					<http://www.proximity.com.au/~brian/winradio/>
 0x90	00	linux/sbpcd.h
+0x93	60-7F	linux/auto_fs.h
 0x99	00-0F	537-Addinboard driver	in development:
 					<mailto:b.kohl@ipn-b.comlink.apc.org>
 0xA0	all	Small Device Project	in development:
diff --git a/Documentation/locks.txt b/Documentation/locks.txt
index ea91be8a2..3911417b2 100644
--- a/Documentation/locks.txt
+++ b/Documentation/locks.txt
@@ -2,42 +2,30 @@
 
 		Andy Walker <andy@lysaker.kvaerner.no>
 
-			    21 Sep 1996
+			    12 May 1997
 
 
 1. What's New?
 --------------
 
-1.1 Flock Emulation Warnings
-----------------------------
-Many people will have noticed the ugly messages that the file locking
-code started generating with the release of kernel version 1.3.95. The
-messages look something like this:
+1.1 Broken Flock Emulation
+--------------------------
 
-    fcntl_setlk() called by process XX with broken flock() emulation
+The old flock(2) emulation in the kernel was swapped for proper BSD
+compatible flock(2) support in the 1.3.x series of kernels. With the
+release of the 2.1.x kernel series, support for the old emulation has
+been totally removed, so that we don't need to carry this baggage
+forever.
 
-This is a warning for people using older C libraries that those libraries
-are still calling the pre 1.3.x flock() emulation routines, instead of
-the real flock() system call. The old routines are quite badly broken,
-especially with respect to parent-child lock sharing, and can give bad
-results if, for example, sendmail attempts to use them.
+This should not cause problems for anybody, since everybody using a
+2.1.x kernel should have updated their C library to a suitable version
+anyway (see the file "linux/Documentation/Changes".)
 
-Fixed versions of the C libraries have been on public release for many
-months. The latest versions at the time of writing are 5.3.12 (released)
-or 5.4.6 (testing) for ELF. There is also a 4.7.6 release for people
-using a.out systems.
+1.2 Allow Mixed Locks Again
+---------------------------
 
-With the release of Linux 2.0 Linus decided to be lenient on the
-stragglers and changed the warning message so that the kernel will only
-complain once and then shut up. That should make life more bearable even
-for people who, for some reason, don't want to upgrade their libraries.
-
-
-1.2 Disallow Mixed Locks
-------------------------
-
-1.2.1 Sendmail Problems
----------------------
+1.2.1 Typical Problems - Sendmail
+---------------------------------
 Because sendmail was unable to use the old flock() emulation, many sendmail
 installations use fcntl() instead of flock(). This is true of Slackware 3.0
 for example. This gave rise to some other subtle problems if sendmail was
@@ -50,23 +38,17 @@ to lock solid with deadlocked processes.
 
 1.2.2 The Solution
 ------------------
-I have chosen the rather cruel solution of disallowing mixed locking styles
-on a given file at a given time. Attempts to lock a file with flock() when
-fcntl() locks exist, or vice versa, return with an error status of EBUSY.
-This seemed to be the only way to avoid all possible deadlock conditions,
-as flock() locks do not strictly have one owner process and so can't be
-checked for deadlocking in the usual manner.
-
-The process that created a lock with flock() might have forked multiple
-children and exited. Previously the parent process would have been marked
-as the owner of the lock, but deadlocks could just have easily occurred in
-one or more of the children, which we would not have been able to identify
-and avoid.
-
-Some programs may break (again, groan). In particular the aforementioned
-sendmail may have problems running in 'newaliases' mode. It will no longer
-deadlock though. Recompile sendmail to use flock() and your troubles will
-be over.
+The solution I have chosen, after much experimentation and discussion,
+is to make flock() and fcntl() locks oblivious to each other. Both can
+exists, and neither will have any effect on the other.
+
+I wanted the two lock styles to be cooperative, but there were so many
+race and deadlock conditions that the current solution was the only
+practical one. It puts us in the same position as, for example, SunOS
+4.1.x and serveral other commercial Unices. The only OS's that support
+cooperative flock()/fcntl() are those that emulate flock() using
+fcntl(), with all the problems that implies.
+
 
 1.3 Mandatory Locking As A Mount Option
 ---------------------------------------
diff --git a/Documentation/m68k/00-INDEX b/Documentation/m68k/00-INDEX
new file mode 100644
index 000000000..ae5b93488
--- /dev/null
+++ b/Documentation/m68k/00-INDEX
@@ -0,0 +1,9 @@
+00-INDEX
+	- this file
+amiboot.txt
+	- info and options for the Linux/m68k Amiga bootstrap (Amiboot)
+framebuffer.txt
+	- info about the Linux/m68k frame buffer device
+kernel-options.txt
+	- command line options for Linux/m68k
+
diff --git a/Documentation/m68k/amiboot.README b/Documentation/m68k/amiboot.txt
index 1e25e1d37..c119c6357 100644
--- a/Documentation/m68k/amiboot.README
+++ b/Documentation/m68k/amiboot.txt
@@ -1,7 +1,10 @@
 
-		Linux/m68k Amiga Bootstrap version 5.1
+		Linux/m68k Amiga Bootstrap version 5.5
 		--------------------------------------
 
+Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
+Last revised: March 27, 1997
+
 
 0. Introduction
 ---------------
@@ -10,7 +13,7 @@ Amiboot is used to boot Linux/m68k on Amiga from the CLI/Shell.
 
 Before you try to boot Linux/m68k for the first time, please read the FAQ
 
-    http://www-agrw.informatik.uni-kl.de/~jmayer/linux68k/linux68k-faq
+    http://www.clark.net/pub/lawrencc/linux/faq/faq.html
 
 and the Installation Guide
 
@@ -19,7 +22,7 @@ and the Installation Guide
 first. Although the Installation Guide is getting a bit outdated, it's still a
 good starting point.
 
-Amiboot 5.1 is meant for Linux/m68k 2.0.x, 2.1.x or higher (kernel bootinfo
+Amiboot 5.5 is meant for Linux/m68k 2.0.x, 2.1.x or higher (kernel bootinfo
 interface versions 1.x and 2.x). Please use an older version for older kernels.
 
 
@@ -30,23 +33,27 @@ The Amiboot invocation syntax looks like
 
     amiboot [options] [kernel command line]
 
-Valid options are:
+Basic options:
 
     --help           Display the usage information
 
     --kernel file    Use kernel image `file' (default is `vmlinux')
 
-    --ramdisk file   Use ramdisk image `file'.
+    --ramdisk file   Use ramdisk image `file'
+
+Advanced options:
 
     --debug          Enable debug mode
 
-    --baud           Set the serial port speed (default is 9600)
+    --baud speed     Set the serial port speed (default is 9600 bps)
 
     --memfile file   Use memory file `file'
 
     --keep-video     Don't reset the video mode
 
-    --model id       Set the Amiga model to `id'.
+    --model id       Set the Amiga model to `id'
+
+    --processor cfm  Set the processor type to `cfm'
 
 The kernel command line contains the options you want to pass to the kernel and
 to init, the process that's started first by Linux. Please read
@@ -57,6 +64,10 @@ Linux/m68k kernel image, and --ramdisk if you want to boot from a ramdisk file,
 i.e. a file containing a complete file system, instead of from a hard disk
 partition.
 
+Note that both the kernel image and the ramdisk image can be compressed with
+gzip. Amiboot knows how to deal with gzipped kernel images, and the kernel
+recognizes gzipped ramdisk images.
+
 Example:
 
     amiboot -k vmlinux-2.1.13 root=/dev/hda3 video=font:PEARL8x8
@@ -65,8 +76,8 @@ Amiboot will boot the kernel image `vmlinux-2.1.13' and will pass
 `root=/dev/hda3 video=font:PEARL8x8' to the kernel.
 
 
-The other options are more specialized. Don't use them unless you really have
-to and you know what you're doing.
+The other options are more advanced. Don't use them unless you really have to
+and you know what you're doing.
 
 The --baud option allows you to specify the serial port speed for initial boot
 information and initial kernel messages. Note: this option does not work with
@@ -79,8 +90,9 @@ The --keep-video option is necessary if you want to retain the current graphics
 mode (on a graphics board) under Linux. Currently this is only useful if you
 have a CyberVision 64 graphics board.
 
-Finally, --model allows you to specify your Amiga model, and --debug is for
-debugging purposes.
+Finally, --model and --processor allow you to specify your Amiga model and
+processor type if they are detected incorrectly, and --debug dumps some
+information which simplifies debugging.
 
 
 2. The memory file
@@ -98,7 +110,7 @@ format for the file is:
     ...
 
 For example, if you don't want Linux to use your 2nd meg of chipram, you would
-create a file that looks contains only:
+create a file that contains only:
 
     1048576
 
@@ -149,7 +161,33 @@ Please send me the output of amiboot used with the --debug option if your Amiga
 model is detected incorrectly.
 
 
-4. Abbreviations
+4. Processor types
+------------------
+
+If your processor is detected incorrectly, you can override this using the
+`--processor cfm' option. `cfm' must be a three-digit number with
+
+  - `c' the CPU (Central Processing Unit) type,
+  - 'f' the FPU (Floating Point Unit) type,
+  - 'm' the MMU (Memory Management Unit) type,
+
+from the table below:
+
+     value |  CPU  |  FPU  |  MMU
+    -------+-------+-------+-------
+       0   |   -   |   -   |   -
+       1   | 68020 | 68881 | 68851
+       2   | 68030 | 68882 | 68030
+       3   | 68040 | 68040 | 68040
+       4   | 68060 | 68060 | 68060
+
+e.g. `444' if you have a 68060 and `303' if you have a 68LC040.
+
+Note that normally you don't have to use this option. It's only needed for some
+combinations of an old Kickstart ROM and a new processor (e.g. a 68060).
+
+
+5. Abbreviations
 ----------------
 
 All options also have a shorthand:
@@ -162,9 +200,10 @@ All options also have a shorthand:
     --memfile	    -m
     --keep-video    -v
     --model	    -t
+    --processor	    -p
 
 
-5. Miscellaneous
+6. Miscellaneous
 ----------------
 
 Some expansion boards keep on generating interrupts once they were initialized
@@ -186,7 +225,7 @@ routine for them yet:
 If you write a routine to disable an expansion board, please let me know.
 
 
-6. Troubleshooting
+7. Troubleshooting
 ------------------
 
   - Amiboot says
@@ -222,11 +261,13 @@ If you write a routine to disable an expansion board, please let me know.
 
       o If that doesn't work, remove any expansion devices and retry.
 
+      o Check the detected Amiga model and processor type.
+
       o Look at the characters that are dumped to the serial port during
 	booting.
 
 
-7. Amiga-Lilo
+8. Amiga-Lilo
 -------------
 
 Once you have a stable Linux/m68k installation, you may want to try Amiga-Lilo.
@@ -234,7 +275,7 @@ Amiga-Lilo allows you to boot Linux/m68k without the overhead of booting
 AmigaOS first, and it provides you with a boot menu.
 
 
-8. Credits
+9. Credits
 ----------
 
 This readme was written by Geert Uytterhoeven. A lot of information was taken
diff --git a/Documentation/m68k/framebuffer.txt b/Documentation/m68k/framebuffer.txt
new file mode 100644
index 000000000..490a33793
--- /dev/null
+++ b/Documentation/m68k/framebuffer.txt
@@ -0,0 +1,370 @@
+
+		The Linux/m68k Frame Buffer Device
+		----------------------------------
+
+Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
+Last revised: March 23, 1997
+
+
+0. Introduction
+---------------
+
+The frame buffer device provides an abstraction for the graphics hardware. It
+represents the frame buffer of some video hardware and allows application
+software to access the graphics hardware through a well-defined interface, so
+the software doesn't need to know anything about the low-level (hardware
+register) stuff.
+
+The device is accessed through special device nodes, usually located in the
+/dev directory, i.e. /dev/fb*.
+
+
+1. User's View of /dev/fb*
+--------------------------
+
+From the user's point of view, the frame buffer device looks just like any
+other device in /dev. It's a character device using major 29, the minor is
+divided into a frame buffer number in the upper 3 bits (allowing max. 8 frame
+buffers simultaneously) and a resolution code in the lower 5 bits of the minor.
+
+By convention, the following device nodes are used (numbers indicate the device
+minor numbers):
+
+    First frame buffer
+	 0 = /dev/fb0current		Current resolution
+	 1 = /dev/fb0autodetect		Default resolution
+	 2 = /dev/fb0predefined0	Predefined resolutions (22)
+	     ...
+	23 = /dev/fb0predefined21
+	24 = /dev/fb0user0		User defined resolutions (8)
+	     ...
+	31 = /dev/fb0user7                              
+
+    Second frame buffer
+	32 = /dev/fb1current		Current resolution
+	33 = /dev/fb1autodetect		Default resolution
+	34 = /dev/fb1predefined0	Predefined resolutions (22)
+	     ...
+	55 = /dev/fb1predefined21
+	56 = /dev/fb1user0		User defined resolutions (8)
+	     ...                                          
+	63 = /dev/fb1user7                                 
+
+and so on...
+
+The device with (minor & 31) == 0 (/dev/fb?current) stands for the frame buffer
+together with the currently set video parameters; (minor & 31) == 1
+(/dev/fb?autodetect) is the video mode detected at boot time. Any other minor
+stands for some predefined or user defined video mode.
+
+The predefined entries (/dev/fb?predefined*) usually have a device dependent
+name, e.g. for major 29, minor 5, we have /dev/fb0multiscan on Amiga and
+/dev/fb0ttmid on Atari. These are meant to contain hardware dependent
+resolutions.
+
+The user defined resolutions (/dev/fb?user?) are meant to be filled in by the
+user. This way the user can store his favorite 8 resolutions during boot up.
+
+Note: if you need more than 8 user defined resolutions, you can always override
+the predefined resolutions by storing them in one of the predefined entries.
+But this is not recommended. Similarly, if there are more than 22 predefined
+resolutions, the device writer can decide to store them in the user defined
+entries.
+
+If the device is opened (for writing), the frame buffer driver switches to the
+selected video mode. Thus, you can switch video modes by writing to a frame
+buffer device, e.g.
+
+    > /dev/fb0ttlow
+
+will switch your video to TT low mode. Note: if you specify a resolution which
+contains a value that's not possible on your hardware, the frame buffer device
+will round it up (if possible) or return an error condition.
+
+The frame buffer devices are also `normal' memory devices, this means, you can
+read and write their contents. You can, for example, make a screen snapshot by
+
+  cp /dev/fb0current myfile
+
+There also can be more than one frame buffer at a time, e.g. if you have a
+graphics card in addition to the built-in hardware. The corresponding frame
+buffer devices (/dev/fb0* and /dev/fb1* etc.) work independently.
+
+Application software that uses the frame buffer device (e.g. the X server) will
+use /dev/fb0current by default. You can specify an alternative resolution by
+setting the environment variable $FRAMEBUFFER to the path name of a frame
+buffer device, e.g. (for sh/bash users):
+
+    export FRAMEBUFFER=/dev/fb0multiscan
+
+or (for csh users):
+
+    setenv FRAMEBUFFER /dev/fb0multiscan
+
+After this the X server will use the multiscan video mode.
+
+
+2. Programmer's View of /dev/fb*
+--------------------------------
+
+As you already know, a frame buffer device is a memory device like /dev/mem and
+it has the same features. You can read it, write it, seek to some location in
+it and mmap() it (the main usage). The difference is just that the memory that
+appears in the special file is not the whole memory, but the frame buffer of
+some video hardware.
+
+/dev/fb* also allows several ioctls on it, by which lots of information about
+the hardware can be queried and set. The color map handling works via ioctls,
+too. Look into <linux/fb.h> for more information on what ioctls exist and on
+which data structures they work. Here's just a brief overview:
+
+  - You can request unchangeable information about the hardware, like name,
+    organization of the screen memory (planes, packed pixels, ...) and address
+    and length of the screen memory.
+
+  - You can request and change variable information about the hardware, like
+    visible and virtual geometry, depth, color map format, timing, and so on.
+    If you try to change that informations, the driver maybe will round up some
+    values to meet the hardware's capabilities (or return EINVAL if that isn't
+    possible).
+
+  - You can get and set parts of the color map. Communication is done with 16
+    bit per color part (red, green, blue, transparency) to support all existing
+    hardware. The driver does all the computations needed to bring it into the
+    hardware (round it down to less bits, maybe throw away transparency).
+
+All this hardware abstraction makes the implementation of application programs
+easier and more portable. E.g. the X server works completely on /dev/fb* and
+thus doesn't need to know, for example, how the color registers of the concrete
+hardware are organized. XF68_FBDev is a general X server for bitmapped,
+unaccelerated video hardware. The only thing that has to be built into
+application programs is the screen organization (bitplanes or chunky pixels
+etc.), because it works on the frame buffer image data directly.
+
+For the future it is planned that frame buffer drivers for graphics cards and
+the like can be implemented as kernel modules that are loaded at runtime. Such
+a driver just has to call register_framebuffer() and supply some functions.
+Writing and distributing such drivers independently from the kernel will save
+much trouble...
+
+
+3. Frame Buffer Resolution Maintenance
+--------------------------------------
+
+Frame buffer resolutions are maintained using the utility `fbset'. It allows to
+change the video mode properties of the current or a user defined resolution.
+It's main usage is to tune video modes and to store custom resolutions into one
+of the /dev/fb?user?  entries, e.g. during boot up in one of your /etc/rc.* or
+/etc/init.d/* files, after which those resolutions can be used by applications.
+
+Fbset uses a video mode database stored in a configuration file, so you can
+easily add your own modes and refer to them with a simple identifier. The fbset
+install script also creates the special device nodes for the device dependent
+predefined resolutions.
+
+
+4. The X Server
+---------------
+
+The X server (XF68_FBDev) is the most notable application program for the frame
+buffer device. The current X server is part of the XFree86/XFree68 release 3.2
+package and has 2 modes:
+
+  - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
+    file contains a
+
+	Modes "default"
+
+    line, the X server will use the scheme discussed above, i.e. it will start
+    up in the resolution determined by /dev/fb0current (or $FRAMEBUFFER, if
+    set). This is the default for the configuration file supplied with XFree68
+    3.2. It's the most simple configuration (and the only possible one if you
+    want to have a broadcast compatible display, e.g. PAL or NTSC), but it has
+    some limitations.
+
+  - Therefore it's also possible to specify resolutions in the /etc/XF86Config
+    file. This allows for on-the-fly resolution switching while retaining the
+    same virtual desktop size. The frame buffer device that's used is still
+    /dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
+    defined by /etc/XF86Config now. The disadvantage is that you have to
+    specify the timings in a different format (but `fbset -x' may help) and
+    that you can't have a broadcast compatible display (e.g. no PAL or NTSC).
+
+To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
+work 100% with XF68_FBDev: the reported clock values are always incorrect.
+
+There exists also an accelerated X server for the Cybervision 64 graphics
+board, but that's not discussed here.
+
+
+5. Video Mode Timings
+---------------------
+
+A monitor draws an image on the screen by using an electron beam (3 electron
+beams for most color models, 1 electron beam for Trinitron color monitors and
+monochrone monitors). The front of the screen is covered by a pattern of
+colored phospors (pixels). If a phospor is hit by an electron, it emits a
+photon and thus becomes visible.
+
+The electron beam draws horizontal lines (scanlines) from left to right, and
+from the top to the bottom of the screen. By modifying the intensity of the
+electron beam, pixels with various colors and intensities can be shown.
+
+After each scanline the electron beam has to move back to the left side of the
+screen and to the next line: this is called the horizontal retrace. After the
+whole screen (frame) was painted, the beam moves back to the upper left corner:
+this is called the vertical retrace. During both the horizontal and vertical
+retrace, the electron beam is turned off (blanked).
+
+The speed at which the electron beam paints the pixels is determined by the
+dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
+of cycles per second), each pixel is 35242 ps (picoseconds) long:
+
+    1/(28.37516E6 Hz) = 35.242E-9 s
+
+If the screen resolution is 640x480, it will take
+
+    640*35.242E-9 s = 22.555E-6 s
+
+to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
+also takes time (e.g. 272 `pixels'), so a full scanline takes
+
+    (640+272)*35.242E-9 s = 32.141E-6 s
+
+We'll say that the horizontal scanrate is about 31 kHz:
+
+    1/(32.141E-6 s) = 31.113E3 Hz
+
+A full screen counts 480 (yres) lines, but we have to consider the vertical
+retrace too (e.g. 49 `pixels'). So a full screen will take
+
+    (480+49)*32.141E-6 s = 17.002E-3 s
+
+The vertical scanrate is about 59 Hz:
+
+    1/(17.002E-3 s) = 58.815 Hz
+
+This means the screen data is refreshed about 59 times per second. To have a
+stable picture without visible flicker, VESA recommends a vertical scanrate of
+at least 72 Hz. But the perceived flicker is very human dependent: some people
+can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
+
+Since the monitor doesn't know when a new scanline starts, the graphics board
+will supply a synchronization pulse (horizontal sync or hsync) for each
+scanline.  Similarly it supplies a synchronization pulse (vertical sync or
+vsync) for each new frame. The position of the image on the screen is
+influenced by the moments at which the synchronization pulses occur.
+
+The following picture summarizes all timings. The horizontal retrace time is
+the sum of the left margin, the right margin and the hsync length, while the
+vertical retrace time is the sum of the upper margin, the lower margin and the
+vsync length.
+
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ^                            |          |       |
+  |          |                |upper_margin                |          |       |
+  |          |                ¥                            |          |       |
+  +----------###############################################----------+-------+
+  |          #                ^                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |   left   #                |                            #  right   | hsync |
+  |  margin  #                |       xres                 #  margin  |  len  |
+  |<-------->#<---------------+--------------------------->#<-------->|<----->|
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |yres                        #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                ¥                            #          |       |
+  +----------###############################################----------+-------+
+  |          |                ^                            |          |       |
+  |          |                |lower_margin                |          |       |
+  |          |                ¥                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ^                            |          |       |
+  |          |                |vsync_len                   |          |       |
+  |          |                ¥                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+
+The frame buffer device expects all horizontal timings in number of dotclocks
+(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
+
+
+6. Converting XFree86 timing values info frame buffer device timings
+--------------------------------------------------------------------
+
+An XFree86 mode line consists of the following fields:
+ "800x600"     50      800  856  976 1040    600  637  643  666
+ < name >     DCF       HR  SH1  SH2  HFL     VR  SV1  SV2  VFL
+
+The frame buffer device uses the following fields:
+
+  - pixclock: pixel clock in ps (pico seconds)
+  - left_margin: time from sync to picture
+  - right_margin: time from picture to sync
+  - upper_margin: time from sync to picture
+  - lower_margin: time from picture to sync
+  - hsync_len: length of horizontal sync
+  - vsync_len: length of vertical sync
+
+1) Pixelclock:
+   xfree: in MHz
+   fb: In Picoseconds (ps)
+
+   pixclock = 1000000 / DCF
+
+2) horizontal timings:
+   left_margin = HFL - SH2
+   right_margin = SH1 - HR
+   hsync_len = SH2 - SH1
+
+3) vertical timings:
+   upper_margin = VFL - SV2
+   lower_margin = SV1 - VR
+   vsync_len = SV2 - SV1
+
+Good examples for VESA timings can be found in the XFree86 source tree,
+under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
+
+
+7. References
+-------------
+
+For more specific information about the frame buffer device and its
+applications, please refer to the following documentation:
+
+  - The manual pages for fbset: fbset(8), fb.modes(5)
+  - The manual pages for XFree68: XF68_FBDev(1), XF86Config(4/5)
+  - The mighty kernel sources:
+      o linux/include/linux/fb.h
+      o linux/drivers/char/fbmem.c
+      o linux/arch/m68k/*/*fb.c
+
+
+8. Downloading
+--------------
+
+All necessary files can be found at
+
+    ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
+
+and on its mirrors.
+
+  
+9. Credits                                                       
+----------                                                       
+                
+This readme was written by Geert Uytterhoeven, partly based on the original
+`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
+provided by Frank Neumann.
+
+The frame buffer device abstraction was designed by Martin Schaller.
diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt
index b5878662d..ed0c203d0 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -800,6 +800,18 @@ hostadapters.
   No argument. Used to separate blocks of keywords when there's more
 than one host adapter in the system.
 
+5.3.7) nodma
+------------
+
+Syntax: nodma:x
+
+  If x is 1 (or if the option is just written as "nodma"), the WD33c93
+controller will not use DMA (= direct memory access) to access the
+Amiga's memory.  This is useful for some systems (like A3000's and
+A4000's with the A3640 accelerator, revision 3.0) that have problems
+using DMA to chip memory.  The default is 0, i.e. to use DMA if
+possible.
+
 
 5.4) gvp11=
 -----------
diff --git a/Documentation/networking/net-modules.txt b/Documentation/networking/net-modules.txt
index b83d2bd9f..bdf5a34a1 100644
--- a/Documentation/networking/net-modules.txt
+++ b/Documentation/networking/net-modules.txt
@@ -109,6 +109,10 @@ Card/Module List - Configurable Parameters and Default Values
 8390.c:
 	(No public options, several other modules need this one)
 
+a2065.c:
+	Since this is a Zorro board, it supports full autoprobing, even for
+	multiple boards. (m68k/Amiga)
+
 ac3200.c:
 	io = 0		(Checks 0x1000 to 0x8fff in 0x1000 intervals)
 	irq = 0		(Read from config register)
@@ -133,11 +137,24 @@ arcnet.c:
 		       0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370,
 		0x380, 0x390, 0x3A0,			  0x3E0, 0x3F0  )
 
+ariadne.c:
+	Since this is a Zorro board, it supports full autoprobing, even for
+	multiple boards. (m68k/Amiga)
+
 at1700.c:
 	io = 0x260
 	irq = 0
 	(Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
 
+atari_bionet.c:
+	Supports full autoprobing. (m68k/Atari)
+
+atari_pamsnet.c:
+	Supports full autoprobing. (m68k/Atari)
+
+atarilance.c:
+	Supports full autoprobing. (m68k/Atari)
+
 atp.c: *Not modularized*
 	(Probes ports: 0x378, 0x278, 0x3BC;
 	 fixed IRQs: 5 and 7			)
@@ -212,6 +229,10 @@ hp100.c:
 	 On ISA-bus probes all ports from 0x100 thru to 0x3E0
 	 in increments of 0x020)
 
+hydra.c:
+	Since this is a Zorro board, it supports full autoprobing, even for
+	multiple boards. (m68k/Amiga)
+
 ibmtr.c:
 	io = 0xa20, 0xa24 (autoprobed by default)
 	irq = 0 (driver cannot select irq - read from hardware)
diff --git a/Documentation/serial-console.txt b/Documentation/serial-console.txt
index 22f02e2b7..4d81e4c98 100644
--- a/Documentation/serial-console.txt
+++ b/Documentation/serial-console.txt
@@ -47,7 +47,7 @@ as the serial console. Replace as needed.
    Sysvinit remembers its stty settings in a file in /etc, called
    `/etc/ioctl.save'. REMOVE THIS FILE before using the serial
    console for the first time, because otherwise init will probably
-   set the baudrate to 38400 (bausdrate of the virtual console).
+   set the baudrate to 38400 (baudrate of the virtual console).
 
 5. /dev/console and X
    Programs that want to do something with the virtual console usually
diff --git a/Documentation/svga.txt b/Documentation/svga.txt
index 049f952ef..8239708f3 100644
--- a/Documentation/svga.txt
+++ b/Documentation/svga.txt
@@ -1,5 +1,5 @@
-		       Video Mode Selection Support 2.10
-	      (c) 1995, 1996 Martin Mares, <mj@k332.feld.cvut.cz>
+		       Video Mode Selection Support 2.11
+	      (c) 1995--1997 Martin Mares, <mj@k332.feld.cvut.cz>
 --------------------------------------------------------------------------------
 
 1. Intro
@@ -14,8 +14,9 @@ DESCRIBING YOUR EXPERIENCE WITH IT. BUG REPORTS ARE ALSO WELCOME.
 
    The video mode to be used is selected by a kernel parameter which can be
 specified in the kernel Makefile (the SVGA_MODE=... line) or by the "vga=..."
-option of LILO or by the "vidmode" utility (present in standard Linux utility
-packages). You can use the following settings of this parameter:
+option of LILO (or some other boot loader you use) or by the "vidmode" utility
+(present in standard Linux utility packages). You can use the following values
+of this parameter:
 
    NORMAL_VGA - Standard 80x25 mode available on all display adapters.
 
@@ -39,8 +40,8 @@ packages). You can use the following settings of this parameter:
    The ASK_VGA mode causes the kernel to offer a video mode menu upon
 bootup. It displays a "Press <RETURN> to see video modes available, <SPACE>
 to continue or wait 30 secs" message. If you press <RETURN>, you enter the
-menu, if you press <SPACE> or wait 30 seconds, the kernel will boot up with
-the standard 80x25 mode set.
+menu, if you press <SPACE> or wait 30 seconds, the kernel will boot up in
+the standard 80x25 mode.
 
    The menu looks like:
 
@@ -51,62 +52,70 @@ Mode:    COLSxROWS:
 2  0F02  80x43
 3  0F03  80x26
 ....
-Enter mode number: <flashing-cursor-here>
+Enter mode number or `scan': <flashing-cursor-here>
 
-   <name-of-detected-video-adapter> should contain a name of your video adapter
-or the chip in it or at least whether it's an EGA or VGA or VESA VGA (VGA with
-a VESA-compliant BIOS in it). If it doesn't match your configuration, tell me
-and I'll try to fix it somehow (you know, hardware detection is a real pain
-on PC's).
+   <name-of-detected-video-adapter> tells what video adapter did Linux detect
+-- it's either a generic adapter name (MDA, CGA, HGC, EGA, VGA, VESA VGA [a VGA
+with VESA-compliant BIOS]) or a chipset name (e.g., Trident). Direct detection
+of chipsets is turned off by default (see CONFIG_VIDEO_SVGA in chapter 4 to see
+how to enable it if you really want) as it's inherently unreliable due to
+absolutely insane PC design.
 
    "0  0F00  80x25" tells that the first menu item (the menu items are numbered
 from "0" to "9" and from "a" to "z") is a 80x25 mode with ID=0x0f00 (see the
-next section for a description of the mode ID's).
+next section for a description of mode ID's).
 
    <flashing-cursor-here> encourages you to write the item number or mode ID
 you wish to set and press <RETURN>. If the computer complains something about
 "Unknown mode ID", it tries to explain you that it isn't possible to set such
-a mode. It's also possible to press only <RETURN> which forces the current
-mode to be used.
+a mode. It's also possible to press only <RETURN> which leaves the current mode.
 
-   The mode list may be a bit inaccurate on your machine (it isn't possible
-to autodetect all existing video cards and their mutations). Some of the
-modes may be unsettable, some of them might work incorrectly with Linux
-(the common case is mirroring of first few lines at the bottom of the screen
-because of BIOS bugs) or there can exist modes which are not displayed. If
-you think the list doesn't match your configuration, let me know and I'll try
-to add your configuration to the next version of the mode selector.
+   The mode list usually contains only few basic modes and some VESA modes.  In
+case your chipset has been detected, some chipset-specific modes are shown as
+well (some of these might be missing or unusable on your machine as different
+BIOSes are often shipped with the same card and the mode numbers depend purely
+on the VGA BIOS).
 
    The modes displayed on the menu are partially sorted: The list starts with
 the standard modes (80x25 and 80x50) followed by "special" modes (80x28 and
 80x43), local modes (if the local modes feature is enabled), VESA modes and
 finally SVGA modes for the auto-detected adapter.
 
-   If you enter "scan" instead of item number / mode ID, the program will try
-to scan your video modes in a slightly aggressive, but much more accurate way.
-This should reveal all video modes supported by your BIOS. During this process,
-the screen will flash wildly and strange things will appear. If you are afraid
-this could damage your monitor, don't use this functions. After scanning, the
-mode ordering is a bit different: the auto-detected SVGA modes are not listed
-at all and the modes revealed by the scan are shown before the VESA modes.
+   If you are not happy with the mode list offered (e.g., if you think your card
+is able to do more), you can enter "scan" instead of item number / mode ID.  The
+program will try to ask the BIOS for all possible video mode numbers and test
+what happens then. The screen will be probably flashing wildly for some time and
+strange noises will be heard from inside the monitor and so on and then, really
+all consistent video modes supported by your BIOS will appear (plus maybe some
+`ghost modes'). If you are afraid this could damage your monitor, don't use this
+function.
+
+   After scanning, the mode ordering is a bit different: the auto-detected SVGA
+modes are not listed at all and the modes revealed by `scan' are shown before
+all VESA modes.
 
 3. Mode ID's
 ~~~~~~~~~~~~
    Because of the complexity of all the video stuff, the video mode ID's
 used here are also a bit complex. A video mode ID is a 16-bit number usually
-expressed in a hexadecimal notation (starting with "0x"). The ID numbers
-can be divided to three regions:
+expressed in a hexadecimal notation (starting with "0x"). You can set a mode
+by entering its mode directly if you know it even if it isn't shown on the menu.
+
+The ID numbers can be divided to three regions:
 
-   0x0000 to 0x00ff - menu item references. 0x0000 is the first item.
+   0x0000 to 0x00ff - menu item references. 0x0000 is the first item. Don't use
+	outside the menu as this can change from boot to boot (especially if you
+	have used the `scan' feature).
 
    0x0100 to 0x017f - standard BIOS modes. The ID is a BIOS video mode number
-	(as presented to INT 10, function 00) increased by 0x0100. You can
-	use any mode numbers even if not shown on the menu.
+	(as presented to INT 10, function 00) increased by 0x0100.
 
    0x0200 to 0x08ff - VESA BIOS modes. The ID is a VESA mode ID increased by
 	0x0100. All VESA modes should be autodetected and shown on the menu.
 
    0x0900 to 0x09ff - Video7 special modes. Set by calling INT 0x10, AX=0x6f05.
+	(Usually 940=80x43, 941=132x25, 942=132x44, 943=80x60, 944=100x60,
+	945=132x28 for the standard Video7 BIOS)
 
    0x0f00 to 0x0fff - special modes (they are set by various tricks -- usually
 	by modifying one of the standard modes). Currently available:
@@ -123,7 +132,9 @@ can be divided to three regions:
    0x1000 to 0x7fff - modes specified by resolution. The code has a "0xRRCC"
 	form where RR is a number of rows and CC is a number of columns.
 	E.g., 0x1950 corresponds to a 80x25 mode, 0x2b84 to 132x43 etc.
-	This is the only fully portable way to refer to a non-standard mode.
+	This is the only fully portable way to refer to a non-standard mode,
+	but it relies on the mode being found and displayed on the menu
+	(remember that mode scanning is not done automatically).
 
    0xff00 to 0xffff - aliases for backward compatibility:
 	0xffff	equivalent to 0x0f00 (standard 80x25)
@@ -131,8 +142,9 @@ can be divided to three regions:
 
    If you add 0x8000 to the mode ID, the program will try to recalculate
 vertical display timing according to mode parameters, which can be used to
-eliminate some annoying bugs of certain VGA BIOS'es -- mainly extra lines at
-the end of the display.
+eliminate some annoying bugs of certain VGA BIOS'es (usually those used for
+cards with S3 chipsets and old Cirrus Logic BIOSes) -- mainly extra lines at the
+end of the display.
 
 4. Options
 ~~~~~~~~~~
@@ -140,22 +152,27 @@ the end of the display.
 All of them are simple #define's -- change them to #undef's when you want to
 switch them off. Currently supported:
 
-   CONFIG_VIDEO_SVGA - enables autodetection of SVGA cards. If your card is
-detected incorrectly, you can switch this off.
+   CONFIG_VIDEO_SVGA - enables autodetection of SVGA cards. This is switched
+off by default as it's a bit unreliable due to terribly bad PC design. If you
+really want to have the adapter autodetected (maybe in case the `scan' feature
+doesn't work on your machine), switch this on and don't cry if the results
+are not completely sane. In case you really need this feature, please drop me
+a mail as I think of removing it some day.
 
    CONFIG_VIDEO_VESA - enables autodetection of VESA modes. If it doesn't work
 on your machine (or displays a "Error: Scanning of VESA modes failed" message),
 you can switch it off and report as a bug.
 
-   CONFIG_VIDEO_COMPACT - enables compacting of the video mode list. Duplicate
-entries (those with the same screen size) are deleted except for the first one
-(see the previous section for more information on mode ordering). However,
-it's possible that the first variant doesn't work, while some of the others do
--- in this case turn this switch off to see the rest.
+   CONFIG_VIDEO_COMPACT - enables compacting of the video mode list. If there
+are more modes with the same screen size, only the first one is kept (see above
+for more info on mode ordering). However, in very strange cases it's possible
+that the first "version" of the mode doesn't work although some of the others
+do -- in this case turn this switch off to see the rest.
 
    CONFIG_VIDEO_RETAIN - enables retaining of screen contents when switching
 video modes. Works only with some boot loaders which leave enough room for the
-buffer.
+buffer. (If you have old LILO, you can adjust heap_end_ptr and loadflags
+in setup.S, but it's better to upgrade the boot loader...)
 
    CONFIG_VIDEO_LOCAL - enables inclusion of "local modes" in the list. The
 local modes are added automatically to the beginning of the list not depending
@@ -177,25 +194,7 @@ text screen resolution instead of peeking it from BIOS variables. Don't use
 unless you think you know what you're doing. To activate this setup, use
 mode number 0x0f08 (see section 3).
 
-5. Adding more cards
-~~~~~~~~~~~~~~~~~~~~
-   If you have a card not detected by the driver and you are a good programmer,
-feel free to add it to the source and send me a diff. It's very simple: You
-have to add a new entry to the svga_table consisting of a pointer to your mode
-table and a pointer to your detection routine. The order of entries in the
-svga_table defines the order of probing. Please use only reliable detection
-routines which are known to identify _only_ the card in question.
-
-   The detection routine is called with BP pointing to your mode table and
-ES containing 0xc000. If you want, you may alter BP allowing to select an
-appropriate mode table according to model ID detected. If the detection fails,
-return BP=0.
-
-   The mode table consists of lines containing a (BIOS mode number, rows,
-columns) triple and is finished by single zero byte followed by NUL-terminated
-adapter name.
-
-6. Still doesn't work?
+5. Still doesn't work?
 ~~~~~~~~~~~~~~~~~~~~~~
    When the mode detection doesn't work (e.g., the mode list is incorrect or
 the machine hangs instead of displaying the menu), try to switch off some of
@@ -207,11 +206,11 @@ happens and how do the configuration switches affect the behaviour of the bug.
 
    If you start Linux from the M$-DOS, you might also use some DOS tools for
 video mode setting. In this case, you must specify the 0x0f04 mode ("leave
-current settings") to Linux, because if you use anything other, the 80x25
-mode will be used automatically.
+current settings") to Linux, because if you don't and you use any non-standard
+mode, Linux will switch to 80x25 automatically.
 
-   If you set some SVGA mode and there's one or more extra lines on the
-bottom of the display containing already scrolled-out lines, your VGA BIOS
+   If you set some extended mode and there's one or more extra lines on the
+bottom of the display containing already scrolled-out text, your VGA BIOS
 contains the most common video BIOS bug called "incorrect vertical display
 end setting". Adding 0x8000 to the mode ID might fix the problem. Unfortunately,
 this must be done manually -- no autodetection mechanisms are available.
@@ -220,7 +219,7 @@ this must be done manually -- no autodetection mechanisms are available.
 is probably broken and you need to set the CONFIG_VIDEO_400_HACK switch to
 force setting of the correct mode.
 
-7. History
+6. History
 ~~~~~~~~~~
 1.0 (??-Nov-95)	First version supporting all adapters supported by the old
 		setup.S + Cirrus Logic 54XX. Present in some 1.3.4? kernels
@@ -266,3 +265,8 @@ force setting of the correct mode.
 		- Added the CONFIG_VIDEO_400_HACK switch.
 		- Added the CONFIG_VIDEO_GFX_HACK switch.
 		- Code cleanup.
+2.11 (03-May-97)- Yet another cleanup, now including also the documentation.
+		- Direct testing of SVGA adapters turned off by default, `scan'
+		  offered explicitly on the prompt line.
+		- Removed the doc section describing adding of new probing
+		  functions as I try to get rid of _all_ hardware probing here.