summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorJaroslav Kysela <perex@petra>2005-06-22 12:19:24 +0200
committerJaroslav Kysela <perex@petra>2005-06-22 12:19:24 +0200
commitda04b128cf0d74dd4cab270c53d9264e70f9203e (patch)
tree095355c32dfd709236a85b497d3bd461d7cdfe8a /Documentation
parentfae6ec69c84d71b1d5bda9ede1a262c1681684aa (diff)
parent2a5a68b840cbab31baab2d9b2e1e6de3b289ae1e (diff)
Merge with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/fb/intelfb.txt135
-rw-r--r--Documentation/filesystems/isofs.txt6
-rw-r--r--Documentation/filesystems/tmpfs.txt6
-rw-r--r--Documentation/s390/CommonIO16
-rw-r--r--Documentation/sgi-ioc4.txt45
5 files changed, 197 insertions, 11 deletions
diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt
new file mode 100644
index 00000000000..c12d39a23c3
--- /dev/null
+++ b/Documentation/fb/intelfb.txt
@@ -0,0 +1,135 @@
+Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver
+================================================================
+
+A. Introduction
+ This is a framebuffer driver for various Intel 810/815 compatible
+graphics devices. These would include:
+
+ Intel 830M
+ Intel 810E845G
+ Intel 852GM
+ Intel 855GM
+ Intel 865G
+ Intel 915G
+
+B. List of available options
+
+ a. "video=intelfb"
+ enables the intelfb driver
+
+ Recommendation: required
+
+ b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
+ select mode
+
+ Recommendation: user preference
+ (default = 1024x768-32@70)
+
+ c. "vram=<value>"
+ select amount of system RAM in MB to allocate for the video memory
+ if not enough RAM was already allocated by the BIOS.
+
+ Recommendation: 1 - 4 MB.
+ (default = 4 MB)
+
+ d. "voffset=<value>"
+ select at what offset in MB of the logical memory to allocate the
+ framebuffer memory. The intent is to avoid the memory blocks
+ used by standard graphics applications (XFree86). Depending on your
+ usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
+ for the least amount). Note, an arbitrary setting may conflict
+ with XFree86.
+
+ Recommendation: do not set
+ (default = 48 MB)
+
+ e. "accel"
+ enable text acceleration. This can be enabled/reenabled anytime
+ by using 'fbset -accel true/false'.
+
+ Recommendation: enable
+ (default = set)
+
+ f. "hwcursor"
+ enable cursor acceleration.
+
+ Recommendation: enable
+ (default = set)
+
+ g. "mtrr"
+ enable MTRR. This allows data transfers to the framebuffer memory
+ to occur in bursts which can significantly increase performance.
+ Not very helpful with the intel chips because of 'shared memory'.
+
+ Recommendation: set
+ (default = set)
+
+ h. "fixed"
+ disable mode switching.
+
+ Recommendation: do not set
+ (default = not set)
+
+ The binary parameters can be unset with a "no" prefix, example "noaccel".
+ The default parameter (not named) is the mode.
+
+C. Kernel booting
+
+Separate each option/option-pair by commas (,) and the option from its value
+with an equals sign (=) as in the following:
+
+video=i810fb:option1,option2=value2
+
+Sample Usage
+------------
+
+In /etc/lilo.conf, add the line:
+
+append="video=intelfb:800x600-32@75,accel,hwcursor,vram=8"
+
+This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
+framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
+will be enabled.
+
+D. Module options
+
+ The module parameters are essentially similar to the kernel
+parameters. The main difference is that you need to include a Boolean value
+(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
+
+Example, to enable MTRR, include "mtrr=1".
+
+Sample Usage
+------------
+
+Using the same setup as described above, load the module like this:
+
+ modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
+
+Or just add the following to /etc/modprobe.conf
+
+ options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
+
+and just do a
+
+ modprobe intelfb
+
+
+E. Acknowledgment:
+
+ 1. Geert Uytterhoeven - his excellent howto and the virtual
+ framebuffer driver code made this possible.
+
+ 2. Jeff Hartmann for his agpgart code.
+
+ 3. David Dawes for his original kernel 2.4 code.
+
+ 4. The X developers. Insights were provided just by reading the
+ XFree86 source code.
+
+ 5. Antonino A. Daplas for his inspiring i810fb driver.
+
+ 6. Andrew Morton for his kernel patches maintenance.
+
+###########################
+Sylvain
diff --git a/Documentation/filesystems/isofs.txt b/Documentation/filesystems/isofs.txt
index f64a1050668..424585ff6ea 100644
--- a/Documentation/filesystems/isofs.txt
+++ b/Documentation/filesystems/isofs.txt
@@ -26,7 +26,11 @@ Mount options unique to the isofs filesystem.
mode=xxx Sets the permissions on files to xxx
nojoliet Ignore Joliet extensions if they are present.
norock Ignore Rock Ridge extensions if they are present.
- unhide Show hidden files.
+ hide Completely strip hidden files from the file system.
+ showassoc Show files marked with the 'associated' bit
+ unhide Deprecated; showing hidden files is now default;
+ If given, it is a synonym for 'showassoc' which will
+ recreate previous unhide behavior
session=x Select number of session on multisession CD
sbsector=xxx Session begins from sector xxx
diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt
index 417e3095fe3..0d783c504ea 100644
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt
@@ -71,8 +71,8 @@ can be changed on remount. The size parameter also accepts a suffix %
to limit this tmpfs instance to that percentage of your physical RAM:
the default, when neither size nor nr_blocks is specified, is size=50%
-If both nr_blocks (or size) and nr_inodes are set to 0, neither blocks
-nor inodes will be limited in that instance. It is generally unwise to
+If nr_blocks=0 (or size=0), blocks will not be limited in that instance;
+if nr_inodes=0, inodes will not be limited. It is generally unwise to
mount with such options, since it allows any user with write access to
use up all the memory on the machine; but enhances the scalability of
that instance in a system with many cpus making intensive use of it.
@@ -97,4 +97,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root.
Author:
Christoph Rohland <cr@sap.com>, 1.12.01
Updated:
- Hugh Dickins <hugh@veritas.com>, 01 September 2004
+ Hugh Dickins <hugh@veritas.com>, 13 March 2005
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index a831d9ae5a5..59d1166d41e 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -30,7 +30,7 @@ Command line parameters
device numbers (0xabcd or abcd, for 2.4 backward compatibility).
You can use the 'all' keyword to ignore all devices.
The '!' operator will cause the I/O-layer to _not_ ignore a device.
- The order on the command line is not important.
+ The command line is parsed from left to right.
For example,
cio_ignore=0.0.0023-0.0.0042,0.0.4711
@@ -72,13 +72,14 @@ Command line parameters
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
specified devices.
- Note: Already known devices cannot be ignored.
+ Note: While already known devices can be added to the list of devices to be
+ ignored, there will be no effect on then. However, if such a device
+ disappears and then reappeares, it will then be ignored.
- For example, if device 0.0.abcd is already known and all other devices
- 0.0.a000-0.0.afff are not known,
+ For example,
"echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
- will add 0.0.a000-0.0.abcc, 0.0.abce-0.0.accc and 0.0.af00-0.0.afff to the
- list of ignored devices and skip 0.0.abcd.
+ will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
+ devices.
The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward
compatibilty, by the device number in hexadecimal (0xabcd or abcd).
@@ -98,7 +99,8 @@ Command line parameters
- /proc/s390dbf/cio_trace/hex_ascii
Logs the calling of functions in the common I/O-layer and, if applicable,
- which subchannel they were called for.
+ which subchannel they were called for, as well as dumps of some data
+ structures (like irb in an error case).
The level of logging can be changed to be more or less verbose by piping to
/proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on
diff --git a/Documentation/sgi-ioc4.txt b/Documentation/sgi-ioc4.txt
new file mode 100644
index 00000000000..876c96ae38d
--- /dev/null
+++ b/Documentation/sgi-ioc4.txt
@@ -0,0 +1,45 @@
+The SGI IOC4 PCI device is a bit of a strange beast, so some notes on
+it are in order.
+
+First, even though the IOC4 performs multiple functions, such as an
+IDE controller, a serial controller, a PS/2 keyboard/mouse controller,
+and an external interrupt mechanism, it's not implemented as a
+multifunction device. The consequence of this from a software
+standpoint is that all these functions share a single IRQ, and
+they can't all register to own the same PCI device ID. To make
+matters a bit worse, some of the register blocks (and even registers
+themselves) present in IOC4 are mixed-purpose between these several
+functions, meaning that there's no clear "owning" device driver.
+
+The solution is to organize the IOC4 driver into several independent
+drivers, "ioc4", "sgiioc4", and "ioc4_serial". Note that there is no
+PS/2 controller driver as this functionality has never been wired up
+on a shipping IO card.
+
+ioc4
+====
+This is the core (or shim) driver for IOC4. It is responsible for
+initializing the basic functionality of the chip, and allocating
+the PCI resources that are shared between the IOC4 functions.
+
+This driver also provides registration functions that the other
+IOC4 drivers can call to make their presence known. Each driver
+needs to provide a probe and remove function, which are invoked
+by the core driver at appropriate times. The interface of these
+IOC4 function probe and remove operations isn't precisely the same
+as PCI device probe and remove operations, but is logically the
+same operation.
+
+sgiioc4
+=======
+This is the IDE driver for IOC4. Its name isn't very descriptive
+simply for historical reasons (it used to be the only IOC4 driver
+component). There's not much to say about it other than it hooks
+up to the ioc4 driver via the appropriate registration, probe, and
+remove functions.
+
+ioc4_serial
+===========
+This is the serial driver for IOC4. There's not much to say about it
+other than it hooks up to the ioc4 driver via the appropriate registration,
+probe, and remove functions.