Look Ma' what I found on my harddisk ...

 o New faster syscalls for 2.1.x, too
 o Upgrade to 2.1.89.

Don't try to run this.  It's flaky as hell.  But feel free to debug ...

2 files changed, 91 insertions, 88 deletions

diff --git a/Documentation/m68k/framebuffer.txt b/Documentation/m68k/framebuffer.txt
index 490a33793..b533f0202 100644
--- a/Documentation/m68k/framebuffer.txt
+++ b/Documentation/m68k/framebuffer.txt
@@ -3,7 +3,7 @@
 		----------------------------------
 
 Maintained by Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
-Last revised: March 23, 1997
+Last revised: January 24, 1998
 
 
 0. Introduction
@@ -23,85 +23,47 @@ The device is accessed through special device nodes, usually located in the
 --------------------------
 
 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.
+other device in /dev. It's a character device using major 29; the minor
+specifies the frame buffer number.
 
 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                                 
+      0 = /dev/fb0	First frame buffer
+     32 = /dev/fb1	Second frame buffer
+	  ...
+    224 = /dev/fb7	8th frame buffer
 
-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.
+For backwards compatibility, you may want to create the following symbolic
+links:
 
-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.
+    /dev/fb0current -> fb0
+    /dev/fb1current -> fb1
 
-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.
+and so on...
 
 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
+  cp /dev/fb0 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.
+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):
+use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
+an alternative frame buffer device 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
+    export FRAMEBUFFER=/dev/fb1
 
 or (for csh users):
 
-    setenv FRAMEBUFFER /dev/fb0multiscan
+    setenv FRAMEBUFFER /dev/fb1
 
-After this the X server will use the multiscan video mode.
+After this the X server will use the second frame buffer.
 
 
 2. Programmer's View of /dev/fb*
@@ -152,23 +114,20 @@ much trouble...
 --------------------------------------
 
 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.
+change the video mode properties of the current resolution. It's main usage is
+to change the current video mode, e.g. during boot up in one of your /etc/rc.*
+or /etc/init.d/* files.
 
 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.
+easily add your own modes and refer to them with a simple identifier.
 
 
 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:
+buffer device. The current X server is part of the XFree86/XFree68 release
+3.3.1 package and has 2 modes:
 
   - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
     file contains a
@@ -347,7 +306,7 @@ applications, please refer to the following documentation:
   - The mighty kernel sources:
       o linux/include/linux/fb.h
       o linux/drivers/char/fbmem.c
-      o linux/arch/m68k/*/*fb.c
+      o linux/drivers/video/*fb.c
 
 
 8. Downloading
diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt
index fded75017..7b611ef55 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -3,8 +3,8 @@
 				  Command Line Options for Linux/m68k
 				  ===================================
 
-Date: Oct 6, 1997
-Linux/m68k version: 2.0.21
+Last Update: Nov 28, 1997
+Linux/m68k version: 2.1.64
 Author: Roman.Hodek@informatik.uni-erlangen.de (Roman Hodek)
 Update: jds@kom.auc.dk (Jes Sorensen)
 
@@ -191,6 +191,7 @@ Devices possible for Atari:
  - "ser2": SCC channel B serial port ("Modem2"); parameters: 9600bps, 8N1
  - "ser" : default serial port
            This is "ser2" for a Falcon, and "ser1" for any other machine
+ - "midi": The MIDI port; parameters: 31250bps, 8N1
  - "par" : parallel port
            The printing routine for this implements a timeout for the
            case there's no printer connected (else the kernel would
@@ -408,19 +409,7 @@ physical start, in bytes.
   Often, extended interval video hardware has to be activated somehow.
 For this, see the "sw_*" options below.
 
-4.1.6) sw_acia, sw_snd6, sw_snd7
---------------------------------
-
-This specifies the method for turning on extended internal video
-hardware, like OverScan. Several methods are in use:
-
-  sw_acia: Set RTS of the keyboard ACIA high
-  sw_snd6: Set bit 6 of the PSG port A
-  sw_snd7: Set bit 7 of the PSG port A
-
-These sub-options are generally only useful together with "internal:".
-
-4.1.7) external:
+4.1.6) external:
 ----------------
 
 Syntax:
@@ -509,13 +498,13 @@ If you're missing a corresponding yres_virtual: the external part is legacy,
 therefore we don't support hardware-dependend functions like hardware-scroll,
 panning or blanking.
 
-4.1.8) eclock:
+4.1.7) eclock:
 --------------
 
 The external pixel clock attached to the Falcon VIDEL shifter. This
 currently works only with the ScreenWonder!
 
-4.1.9) monitorcap:
+4.1.8) monitorcap:
 -------------------
 
 Syntax: monitorcap:<vmin>;<vmax>;<hmin>;<hmax>
@@ -532,7 +521,7 @@ the horizontal frequency, in kHz.
 
   The defaults for TV/SC1224/SC1435 cover both PAL and NTSC standards.
 
-4.1.10) keep
+4.1.9) keep
 ------------
 
 If this option is given, the framebuffer device doesn't do any video
@@ -578,7 +567,7 @@ Syntax: ataflop=<drive type>[,<trackbuffering>[,<steprateA>[,<steprateB>]]]
    type.
 
    The second parameter <trackbuffer> tells the kernel whether to use
-   track buffering (1) or not (0). The default is machine dependant:
+   track buffering (1) or not (0). The default is machine-dependent:
    no for the Medusa and yes for all others.
 
    With the two following parameters, you can change the default
@@ -650,7 +639,62 @@ ignored (other aren't affected).
     can be performed in optimal order. Not all SCSI devices support
     tagged queuing (:-().
 
+4.6 switches=
+-------------
+
+Syntax: switches=<list of switches>
+
+  With this option you can switch some hardware lines that are often
+used to enable/disable certain hardware extensions. Examples are
+OverScan, overclocking, ...
+
+  The <list of switches> is a comma-separated list of the following
+items:
+
+  ikbd: set RTS of the keyboard ACIA high
+  midi: set RTS of the MIDI ACIA high
+  snd6: set bit 6 of the PSG port A
+  snd7: set bit 6 of the PSG port A
+
+It doesn't make sense to mention a switch more than once (no
+difference to only once), but you can give as many switches as you
+want to enable different features. The switch lines are set as early
+as possible during kernel initialization (even before determining the
+present hardware.)
+
+  All of the items can also be prefixed with "ov_", i.e. "ov_ikbd",
+"ov_midi", ... These options are meant for switching on an OverScan
+video extension. The difference to the bare option is that the
+switch-on is done after video initialization, and somehow synchronized
+to the HBLANK. A speciality is that ov_ikbd and ov_midi are switched
+off before rebooting, so that OverScan is disabled and TOS boots
+correctly.
+
+  If you give an option both, with and without the "ov_" prefix, the
+earlier initialization ("ov_"-less) takes precedence. But the
+switching-off on reset still happens in this case.
+
+4.5) stram_swap=
+----------------
 
+Syntax: stram_swap=<do_swap>[,<max_swap>]
+
+  This option is available only if the kernel has been compiled with
+CONFIG_STRAM_SWAP enabled. Normally, the kernel then determines
+dynamically whether to actually use ST-RAM as swap space. (Currently,
+the fraction of ST-RAM must be less or equal 1/3 of total memory to
+enable this swapping.) You can override the kernel's decision by
+specifying this option. 1 for <do_swap> means always enable the swap,
+even if you have less alternate RAM. 0 stands for never swap to
+ST-RAM, even if it's small enough compared to the rest of memory.
+
+  If ST-RAM swapping is enabled, the kernel usually uses all free
+ST-RAM as swap "device". (If the kernel resides in ST-RAM, the region
+allocated by it is obviously never used for swapping :-) You can also
+limit this amount by specifying the second parameter, <max_swap>, if
+you want to use parts of ST-RAM as normal system memory. <max_swap> is
+in kBytes and the number should be a multiple of 4 (otherwise: rounded
+down).
 
 5) Options for Amiga Only:
 ==========================