Merge /pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
commit
5c34202b8b
62
CREDITS
62
CREDITS
|
@ -380,7 +380,7 @@ S: FutureTV Labs Ltd
|
||||||
S: Brunswick House, 61-69 Newmarket Rd, Cambridge CB5 8EG
|
S: Brunswick House, 61-69 Newmarket Rd, Cambridge CB5 8EG
|
||||||
S: United Kingdom
|
S: United Kingdom
|
||||||
|
|
||||||
N: Thomas Bogendörfer
|
N: Thomas Bogendörfer
|
||||||
E: tsbogend@alpha.franken.de
|
E: tsbogend@alpha.franken.de
|
||||||
D: PCnet32 driver, SONIC driver, JAZZ_ESP driver
|
D: PCnet32 driver, SONIC driver, JAZZ_ESP driver
|
||||||
D: newport abscon driver, g364 framebuffer driver
|
D: newport abscon driver, g364 framebuffer driver
|
||||||
|
@ -400,7 +400,7 @@ W: http://math-www.uni-paderborn.de/~axel/
|
||||||
D: Configuration help text support
|
D: Configuration help text support
|
||||||
D: Linux CD and Support Giveaway List
|
D: Linux CD and Support Giveaway List
|
||||||
|
|
||||||
N: Erik Inge Bolsø
|
N: Erik Inge Bolsø
|
||||||
E: knan@mo.himolde.no
|
E: knan@mo.himolde.no
|
||||||
D: Misc kernel hacks
|
D: Misc kernel hacks
|
||||||
|
|
||||||
|
@ -428,7 +428,7 @@ D: Various fixes (mostly networking)
|
||||||
S: Montreal, Quebec
|
S: Montreal, Quebec
|
||||||
S: Canada
|
S: Canada
|
||||||
|
|
||||||
N: Zoltán Böszörményi
|
N: Zoltán Böszörményi
|
||||||
E: zboszor@mail.externet.hu
|
E: zboszor@mail.externet.hu
|
||||||
D: MTRR emulation with Cyrix style ARR registers, Athlon MTRR support
|
D: MTRR emulation with Cyrix style ARR registers, Athlon MTRR support
|
||||||
|
|
||||||
|
@ -661,7 +661,7 @@ N: Kees Cook
|
||||||
E: kees@outflux.net
|
E: kees@outflux.net
|
||||||
W: http://outflux.net/
|
W: http://outflux.net/
|
||||||
P: 1024D/17063E6D 9FA3 C49C 23C9 D1BC 2E30 1975 1FFF 4BA9 1706 3E6D
|
P: 1024D/17063E6D 9FA3 C49C 23C9 D1BC 2E30 1975 1FFF 4BA9 1706 3E6D
|
||||||
D: Minor updates to SCSI code for the Communications type
|
D: Minor updates to SCSI types, added /proc/pid/maps protection
|
||||||
S: (ask for current address)
|
S: (ask for current address)
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
|
@ -1029,11 +1029,11 @@ D: Future Domain TMC-16x0 SCSI driver (author)
|
||||||
D: APM driver (early port)
|
D: APM driver (early port)
|
||||||
D: DRM drivers (author of several)
|
D: DRM drivers (author of several)
|
||||||
|
|
||||||
N: János Farkas
|
N: János Farkas
|
||||||
E: chexum@shadow.banki.hu
|
E: chexum@shadow.banki.hu
|
||||||
D: romfs, various (mostly networking) fixes
|
D: romfs, various (mostly networking) fixes
|
||||||
P: 1024/F81FB2E1 41 B7 E4 E6 3E D4 A6 71 6D 9C F3 9F F2 BF DF 6E
|
P: 1024/F81FB2E1 41 B7 E4 E6 3E D4 A6 71 6D 9C F3 9F F2 BF DF 6E
|
||||||
S: Madarász Viktor utca 25
|
S: Madarász Viktor utca 25
|
||||||
S: 1131 Budapest
|
S: 1131 Budapest
|
||||||
S: Hungary
|
S: Hungary
|
||||||
|
|
||||||
|
@ -1044,10 +1044,10 @@ D: UDF filesystem
|
||||||
S: (ask for current address)
|
S: (ask for current address)
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Jürgen Fischer
|
N: Jürgen Fischer
|
||||||
E: fischer@norbit.de (=?iso-8859-1?q?J=FCrgen?= Fischer)
|
E: fischer@norbit.de
|
||||||
D: Author of Adaptec AHA-152x SCSI driver
|
D: Author of Adaptec AHA-152x SCSI driver
|
||||||
S: Schulstraße 18
|
S: Schulstraße 18
|
||||||
S: 26506 Norden
|
S: 26506 Norden
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
||||||
|
@ -1113,7 +1113,7 @@ E: fuganti@netbank.com.br
|
||||||
D: random kernel hacker, ZF MachZ Watchdog driver
|
D: random kernel hacker, ZF MachZ Watchdog driver
|
||||||
S: Conectiva S.A.
|
S: Conectiva S.A.
|
||||||
S: R. Tocantins, 89 - Cristo Rei
|
S: R. Tocantins, 89 - Cristo Rei
|
||||||
S: 80050-430 - Curitiba - Paraná
|
S: 80050-430 - Curitiba - Paraná
|
||||||
S: Brazil
|
S: Brazil
|
||||||
|
|
||||||
N: Kumar Gala
|
N: Kumar Gala
|
||||||
|
@ -1258,12 +1258,12 @@ S: 44 St. Joseph Street, Suite 506
|
||||||
S: Toronto, Ontario, M4Y 2W4
|
S: Toronto, Ontario, M4Y 2W4
|
||||||
S: Canada
|
S: Canada
|
||||||
|
|
||||||
N: Richard Günther
|
N: Richard Günther
|
||||||
E: rguenth@tat.physik.uni-tuebingen.de
|
E: rguenth@tat.physik.uni-tuebingen.de
|
||||||
W: http://www.tat.physik.uni-tuebingen.de/~rguenth
|
W: http://www.tat.physik.uni-tuebingen.de/~rguenth
|
||||||
P: 2048/2E829319 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
|
P: 2048/2E829319 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
|
||||||
D: binfmt_misc
|
D: binfmt_misc
|
||||||
S: 72074 Tübingen
|
S: 72074 Tübingen
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
||||||
N: Justin Guyett
|
N: Justin Guyett
|
||||||
|
@ -1287,7 +1287,7 @@ N: Bruno Haible
|
||||||
E: haible@ma2s2.mathematik.uni-karlsruhe.de
|
E: haible@ma2s2.mathematik.uni-karlsruhe.de
|
||||||
D: SysV FS, shm swapping, memory management fixes
|
D: SysV FS, shm swapping, memory management fixes
|
||||||
S: 17 rue Danton
|
S: 17 rue Danton
|
||||||
S: F - 94270 Le Kremlin-Bicêtre
|
S: F - 94270 Le Kremlin-Bicêtre
|
||||||
S: France
|
S: France
|
||||||
|
|
||||||
N: Greg Hankins
|
N: Greg Hankins
|
||||||
|
@ -1701,7 +1701,7 @@ S: Czech Republic
|
||||||
N: Jakob Kemi
|
N: Jakob Kemi
|
||||||
E: jakob.kemi@telia.com
|
E: jakob.kemi@telia.com
|
||||||
D: V4L W9966 Webcam driver
|
D: V4L W9966 Webcam driver
|
||||||
S: Forsbyvägen 33
|
S: Forsbyvägen 33
|
||||||
S: 74143 Knivsta
|
S: 74143 Knivsta
|
||||||
S: Sweden
|
S: Sweden
|
||||||
|
|
||||||
|
@ -1745,8 +1745,9 @@ S: D-64295
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
||||||
N: Andi Kleen
|
N: Andi Kleen
|
||||||
E: ak@muc.de
|
E: andi@firstfloor.org
|
||||||
D: network hacker, syncookies
|
U: http://www.halobates.de
|
||||||
|
D: network, x86, NUMA, various hacks
|
||||||
S: Schwalbenstr. 96
|
S: Schwalbenstr. 96
|
||||||
S: 85551 Ottobrunn
|
S: 85551 Ottobrunn
|
||||||
S: Germany
|
S: Germany
|
||||||
|
@ -2064,7 +2065,7 @@ D: misc. kernel hacking and debugging
|
||||||
S: Cambridge, MA 02139
|
S: Cambridge, MA 02139
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Martin von Löwis
|
N: Martin von Löwis
|
||||||
E: loewis@informatik.hu-berlin.de
|
E: loewis@informatik.hu-berlin.de
|
||||||
D: script binary format
|
D: script binary format
|
||||||
D: NTFS driver
|
D: NTFS driver
|
||||||
|
@ -2141,7 +2142,7 @@ S: PO BOX 220, HFX. CENTRAL
|
||||||
S: Halifax, Nova Scotia
|
S: Halifax, Nova Scotia
|
||||||
S: Canada B3J 3C8
|
S: Canada B3J 3C8
|
||||||
|
|
||||||
N: Kai Mäkisara
|
N: Kai Mäkisara
|
||||||
E: Kai.Makisara@kolumbus.fi
|
E: Kai.Makisara@kolumbus.fi
|
||||||
D: SCSI Tape Driver
|
D: SCSI Tape Driver
|
||||||
|
|
||||||
|
@ -2298,8 +2299,8 @@ E: acme@redhat.com
|
||||||
W: http://oops.ghostprotocols.net:81/blog/
|
W: http://oops.ghostprotocols.net:81/blog/
|
||||||
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
|
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
|
||||||
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
|
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
|
||||||
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
||||||
S: 80240-060 - Curitiba - Paraná
|
S: 80240-060 - Curitiba - Paraná
|
||||||
S: Brazil
|
S: Brazil
|
||||||
|
|
||||||
N: Karsten Merker
|
N: Karsten Merker
|
||||||
|
@ -2579,10 +2580,9 @@ S: Australia
|
||||||
|
|
||||||
N: Miguel Ojeda Sandonis
|
N: Miguel Ojeda Sandonis
|
||||||
E: maxextreme@gmail.com
|
E: maxextreme@gmail.com
|
||||||
D: Author: Auxiliary LCD Controller driver (ks0108)
|
W: http://maxextreme.googlepages.com/
|
||||||
D: Author: Auxiliary LCD driver (cfag12864b)
|
D: Author of the ks0108, cfag12864b and cfag12864bfb auxiliary display drivers.
|
||||||
D: Author: Auxiliary LCD framebuffer driver (cfag12864bfb)
|
D: Maintainer of the auxiliary display drivers tree (drivers/auxdisplay/*)
|
||||||
D: Maintainer: Auxiliary display drivers tree (drivers/auxdisplay/*)
|
|
||||||
S: C/ Mieses 20, 9-B
|
S: C/ Mieses 20, 9-B
|
||||||
S: Valladolid 47009
|
S: Valladolid 47009
|
||||||
S: Spain
|
S: Spain
|
||||||
|
@ -2785,10 +2785,10 @@ N: Juan Quintela
|
||||||
E: quintela@fi.udc.es
|
E: quintela@fi.udc.es
|
||||||
D: Memory Management hacking
|
D: Memory Management hacking
|
||||||
S: LFCIA
|
S: LFCIA
|
||||||
S: Departamento de Computación
|
S: Departamento de Computación
|
||||||
S: Universidade da Coruña
|
S: Universidade da Coruña
|
||||||
S: E-15071
|
S: E-15071
|
||||||
S: A Coruña
|
S: A Coruña
|
||||||
S: Spain
|
S: Spain
|
||||||
|
|
||||||
N: Augusto Cesar Radtke
|
N: Augusto Cesar Radtke
|
||||||
|
@ -2939,7 +2939,7 @@ E: aris@cathedrallabs.org
|
||||||
D: Support for EtherExpress 10 ISA (i82595) in eepro driver
|
D: Support for EtherExpress 10 ISA (i82595) in eepro driver
|
||||||
D: User level driver support for input
|
D: User level driver support for input
|
||||||
S: R. Jose Serrato, 130 - Santa Candida
|
S: R. Jose Serrato, 130 - Santa Candida
|
||||||
S: 82640-320 - Curitiba - Paraná
|
S: 82640-320 - Curitiba - Paraná
|
||||||
S: Brazil
|
S: Brazil
|
||||||
|
|
||||||
N: Alessandro Rubini
|
N: Alessandro Rubini
|
||||||
|
@ -3345,15 +3345,15 @@ P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB
|
||||||
D: rcutorture maintainer
|
D: rcutorture maintainer
|
||||||
D: lock annotations, finding and fixing lock bugs
|
D: lock annotations, finding and fixing lock bugs
|
||||||
|
|
||||||
N: Winfried Trümper
|
N: Winfried Trümper
|
||||||
E: winni@xpilot.org
|
E: winni@xpilot.org
|
||||||
W: http://www.shop.de/~winni/
|
W: http://www.shop.de/~winni/
|
||||||
D: German HOWTO, Crash-Kurs Linux (German, 100 comprehensive pages)
|
D: German HOWTO, Crash-Kurs Linux (German, 100 comprehensive pages)
|
||||||
D: CD-Writing HOWTO, various mini-HOWTOs
|
D: CD-Writing HOWTO, various mini-HOWTOs
|
||||||
D: One-week tutorials on Linux twice a year (free of charge)
|
D: One-week tutorials on Linux twice a year (free of charge)
|
||||||
D: Linux-Workshop Köln (aka LUG Cologne, Germany), Installfests
|
D: Linux-Workshop Köln (aka LUG Cologne, Germany), Installfests
|
||||||
S: Tacitusstr. 6
|
S: Tacitusstr. 6
|
||||||
S: D-50968 Köln
|
S: D-50968 Köln
|
||||||
|
|
||||||
N: Tsu-Sheng Tsao
|
N: Tsu-Sheng Tsao
|
||||||
E: tsusheng@scf.usc.edu
|
E: tsusheng@scf.usc.edu
|
||||||
|
|
|
@ -6,7 +6,7 @@ Description:
|
||||||
races, contains a naming policy within the kernel that is
|
races, contains a naming policy within the kernel that is
|
||||||
against the LSB, and can be replaced by using udev.
|
against the LSB, and can be replaced by using udev.
|
||||||
The files fs/devfs/*, include/linux/devfs_fs*.h were removed,
|
The files fs/devfs/*, include/linux/devfs_fs*.h were removed,
|
||||||
along with the the assorted devfs function calls throughout the
|
along with the assorted devfs function calls throughout the
|
||||||
kernel tree.
|
kernel tree.
|
||||||
|
|
||||||
Users:
|
Users:
|
||||||
|
|
|
@ -160,6 +160,21 @@ supply of new-lines on your screen is not a renewable resource (think
|
||||||
25-line terminal screens here), you have more empty lines to put
|
25-line terminal screens here), you have more empty lines to put
|
||||||
comments on.
|
comments on.
|
||||||
|
|
||||||
|
Do not unnecessarily use braces where a single statement will do.
|
||||||
|
|
||||||
|
if (condition)
|
||||||
|
action();
|
||||||
|
|
||||||
|
This does not apply if one branch of a conditional statement is a single
|
||||||
|
statement. Use braces in both branches.
|
||||||
|
|
||||||
|
if (condition) {
|
||||||
|
do_this();
|
||||||
|
do_that();
|
||||||
|
} else {
|
||||||
|
otherwise();
|
||||||
|
}
|
||||||
|
|
||||||
3.1: Spaces
|
3.1: Spaces
|
||||||
|
|
||||||
Linux kernel style for use of spaces depends (mostly) on
|
Linux kernel style for use of spaces depends (mostly) on
|
||||||
|
@ -625,7 +640,7 @@ language.
|
||||||
|
|
||||||
There appears to be a common misperception that gcc has a magic "make me
|
There appears to be a common misperception that gcc has a magic "make me
|
||||||
faster" speedup option called "inline". While the use of inlines can be
|
faster" speedup option called "inline". While the use of inlines can be
|
||||||
appropriate (for example as a means of replacing macros, see Chapter 11), it
|
appropriate (for example as a means of replacing macros, see Chapter 12), it
|
||||||
very often is not. Abundant use of the inline keyword leads to a much bigger
|
very often is not. Abundant use of the inline keyword leads to a much bigger
|
||||||
kernel, which in turn slows the system as a whole down, due to a bigger
|
kernel, which in turn slows the system as a whole down, due to a bigger
|
||||||
icache footprint for the CPU and simply because there is less memory
|
icache footprint for the CPU and simply because there is less memory
|
||||||
|
|
|
@ -41,8 +41,9 @@ psdocs: $(PS)
|
||||||
PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
|
PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
|
||||||
pdfdocs: $(PDF)
|
pdfdocs: $(PDF)
|
||||||
|
|
||||||
HTML := $(patsubst %.xml, %.html, $(BOOKS))
|
HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
|
||||||
htmldocs: $(HTML)
|
htmldocs: $(HTML)
|
||||||
|
$(call build_main_index)
|
||||||
|
|
||||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||||
mandocs: $(MAN)
|
mandocs: $(MAN)
|
||||||
|
@ -132,10 +133,17 @@ quiet_cmd_db2pdf = PDF $@
|
||||||
%.pdf : %.xml
|
%.pdf : %.xml
|
||||||
$(call cmd,db2pdf)
|
$(call cmd,db2pdf)
|
||||||
|
|
||||||
|
|
||||||
|
main_idx = Documentation/DocBook/index.html
|
||||||
|
build_main_index = rm -rf $(main_idx) && \
|
||||||
|
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
|
||||||
|
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
|
||||||
|
cat $(HTML) >> $(main_idx)
|
||||||
|
|
||||||
quiet_cmd_db2html = HTML $@
|
quiet_cmd_db2html = HTML $@
|
||||||
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
|
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
|
||||||
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
||||||
Goto $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||||
|
|
||||||
%.html: %.xml
|
%.html: %.xml
|
||||||
@(which xmlto > /dev/null 2>&1) || \
|
@(which xmlto > /dev/null 2>&1) || \
|
||||||
|
@ -152,6 +160,7 @@ quiet_cmd_db2man = MAN $@
|
||||||
@(which xmlto > /dev/null 2>&1) || \
|
@(which xmlto > /dev/null 2>&1) || \
|
||||||
(echo "*** You need to install xmlto ***"; \
|
(echo "*** You need to install xmlto ***"; \
|
||||||
exit 1)
|
exit 1)
|
||||||
|
$(Q)mkdir -p $(obj)/man
|
||||||
$(call cmd,db2man)
|
$(call cmd,db2man)
|
||||||
@touch $@
|
@touch $@
|
||||||
|
|
||||||
|
@ -212,11 +221,7 @@ clean-files := $(DOCBOOKS) \
|
||||||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||||
$(C-procfs-example)
|
$(C-procfs-example)
|
||||||
|
|
||||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS))
|
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
|
||||||
|
|
||||||
#man put files in man subdir - traverse down
|
|
||||||
subdir- := man/
|
|
||||||
|
|
||||||
|
|
||||||
# Declare the contents of the .PHONY variable as phony. We keep that
|
# Declare the contents of the .PHONY variable as phony. We keep that
|
||||||
# information in a variable se we can use it in if_changed and friends.
|
# information in a variable se we can use it in if_changed and friends.
|
||||||
|
|
|
@ -84,6 +84,10 @@ X!Iinclude/linux/kobject.h
|
||||||
!Ekernel/rcupdate.c
|
!Ekernel/rcupdate.c
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
<sect1><title>Device Resource Management</title>
|
||||||
|
!Edrivers/base/devres.c
|
||||||
|
</sect1>
|
||||||
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="adt">
|
<chapter id="adt">
|
||||||
|
@ -576,4 +580,67 @@ X!Idrivers/video/console/fonts.c
|
||||||
!Edrivers/input/ff-core.c
|
!Edrivers/input/ff-core.c
|
||||||
!Edrivers/input/ff-memless.c
|
!Edrivers/input/ff-memless.c
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="spi">
|
||||||
|
<title>Serial Peripheral Interface (SPI)</title>
|
||||||
|
<para>
|
||||||
|
SPI is the "Serial Peripheral Interface", widely used with
|
||||||
|
embedded systems because it is a simple and efficient
|
||||||
|
interface: basically a multiplexed shift register.
|
||||||
|
Its three signal wires hold a clock (SCK, often in the range
|
||||||
|
of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
|
||||||
|
a "Master In, Slave Out" (MISO) data line.
|
||||||
|
SPI is a full duplex protocol; for each bit shifted out the
|
||||||
|
MOSI line (one per clock) another is shifted in on the MISO line.
|
||||||
|
Those bits are assembled into words of various sizes on the
|
||||||
|
way to and from system memory.
|
||||||
|
An additional chipselect line is usually active-low (nCS);
|
||||||
|
four signals are normally used for each peripheral, plus
|
||||||
|
sometimes an interrupt.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The SPI bus facilities listed here provide a generalized
|
||||||
|
interface to declare SPI busses and devices, manage them
|
||||||
|
according to the standard Linux driver model, and perform
|
||||||
|
input/output operations.
|
||||||
|
At this time, only "master" side interfaces are supported,
|
||||||
|
where Linux talks to SPI peripherals and does not implement
|
||||||
|
such a peripheral itself.
|
||||||
|
(Interfaces to support implementing SPI slaves would
|
||||||
|
necessarily look different.)
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The programming interface is structured around two kinds of driver,
|
||||||
|
and two kinds of device.
|
||||||
|
A "Controller Driver" abstracts the controller hardware, which may
|
||||||
|
be as simple as a set of GPIO pins or as complex as a pair of FIFOs
|
||||||
|
connected to dual DMA engines on the other side of the SPI shift
|
||||||
|
register (maximizing throughput). Such drivers bridge between
|
||||||
|
whatever bus they sit on (often the platform bus) and SPI, and
|
||||||
|
expose the SPI side of their device as a
|
||||||
|
<structname>struct spi_master</structname>.
|
||||||
|
SPI devices are children of that master, represented as a
|
||||||
|
<structname>struct spi_device</structname> and manufactured from
|
||||||
|
<structname>struct spi_board_info</structname> descriptors which
|
||||||
|
are usually provided by board-specific initialization code.
|
||||||
|
A <structname>struct spi_driver</structname> is called a
|
||||||
|
"Protocol Driver", and is bound to a spi_device using normal
|
||||||
|
driver model calls.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The I/O model is a set of queued messages. Protocol drivers
|
||||||
|
submit one or more <structname>struct spi_message</structname>
|
||||||
|
objects, which are processed and completed asynchronously.
|
||||||
|
(There are synchronous wrappers, however.) Messages are
|
||||||
|
built from one or more <structname>struct spi_transfer</structname>
|
||||||
|
objects, each of which wraps a full duplex SPI transfer.
|
||||||
|
A variety of protocol tweaking options are needed, because
|
||||||
|
different chips adopt very different policies for how they
|
||||||
|
use the bits transferred with SPI.
|
||||||
|
</para>
|
||||||
|
!Iinclude/linux/spi/spi.h
|
||||||
|
!Fdrivers/spi/spi.c spi_register_board_info
|
||||||
|
!Edrivers/spi/spi.c
|
||||||
|
</chapter>
|
||||||
|
|
||||||
</book>
|
</book>
|
||||||
|
|
|
@ -79,12 +79,12 @@
|
||||||
<chapter id="usage">
|
<chapter id="usage">
|
||||||
<title>Usage</title>
|
<title>Usage</title>
|
||||||
<para>
|
<para>
|
||||||
This chapter provides examples how to use the library.
|
This chapter provides examples of how to use the library.
|
||||||
</para>
|
</para>
|
||||||
<sect1>
|
<sect1>
|
||||||
<title>Initializing</title>
|
<title>Initializing</title>
|
||||||
<para>
|
<para>
|
||||||
The init function init_rs returns a pointer to a
|
The init function init_rs returns a pointer to an
|
||||||
rs decoder structure, which holds the necessary
|
rs decoder structure, which holds the necessary
|
||||||
information for encoding, decoding and error correction
|
information for encoding, decoding and error correction
|
||||||
with the given polynomial. It either uses an existing
|
with the given polynomial. It either uses an existing
|
||||||
|
@ -98,10 +98,10 @@
|
||||||
static struct rs_control *rs_decoder;
|
static struct rs_control *rs_decoder;
|
||||||
|
|
||||||
/* Symbolsize is 10 (bits)
|
/* Symbolsize is 10 (bits)
|
||||||
* Primitve polynomial is x^10+x^3+1
|
* Primitive polynomial is x^10+x^3+1
|
||||||
* first consecutive root is 0
|
* first consecutive root is 0
|
||||||
* primitve element to generate roots = 1
|
* primitive element to generate roots = 1
|
||||||
* generator polinomial degree (number of roots) = 6
|
* generator polynomial degree (number of roots) = 6
|
||||||
*/
|
*/
|
||||||
rs_decoder = init_rs (10, 0x409, 0, 1, 6);
|
rs_decoder = init_rs (10, 0x409, 0, 1, 6);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
@ -116,12 +116,12 @@ rs_decoder = init_rs (10, 0x409, 0, 1, 6);
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The expanded data can be inverted on the fly by
|
The expanded data can be inverted on the fly by
|
||||||
providing a non zero inversion mask. The expanded data is
|
providing a non-zero inversion mask. The expanded data is
|
||||||
XOR'ed with the mask. This is used e.g. for FLASH
|
XOR'ed with the mask. This is used e.g. for FLASH
|
||||||
ECC, where the all 0xFF is inverted to an all 0x00.
|
ECC, where the all 0xFF is inverted to an all 0x00.
|
||||||
The Reed-Solomon code for all 0x00 is all 0x00. The
|
The Reed-Solomon code for all 0x00 is all 0x00. The
|
||||||
code is inverted before storing to FLASH so it is 0xFF
|
code is inverted before storing to FLASH so it is 0xFF
|
||||||
too. This prevent's that reading from an erased FLASH
|
too. This prevents that reading from an erased FLASH
|
||||||
results in ECC errors.
|
results in ECC errors.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
|
@ -273,7 +273,7 @@ free_rs(rs_decoder);
|
||||||
May be used under the terms of the GNU General Public License (GPL)
|
May be used under the terms of the GNU General Public License (GPL)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
<para>
|
<para>
|
||||||
The wrapper functions and interfaces are written by Thomas Gleixner
|
The wrapper functions and interfaces are written by Thomas Gleixner.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Many users have provided bugfixes, improvements and helping hands for testing.
|
Many users have provided bugfixes, improvements and helping hands for testing.
|
||||||
|
|
|
@ -1,3 +0,0 @@
|
||||||
# Rules are put in Documentation/DocBook
|
|
||||||
|
|
||||||
clean-files := *.9.gz *.sgml manpage.links manpage.refs
|
|
|
@ -480,8 +480,8 @@ The PCI stack provides 3 possible levels of MSI disabling:
|
||||||
|
|
||||||
6.1. Disabling MSI on a single device
|
6.1. Disabling MSI on a single device
|
||||||
|
|
||||||
Under some circumstances, it might be required to disable MSI on a
|
Under some circumstances it might be required to disable MSI on a
|
||||||
single device, It may be achived by either not calling pci_enable_msi()
|
single device. This may be achieved by either not calling pci_enable_msi()
|
||||||
or all, or setting the pci_dev->no_msi flag before (most of the time
|
or all, or setting the pci_dev->no_msi flag before (most of the time
|
||||||
in a quirk).
|
in a quirk).
|
||||||
|
|
||||||
|
@ -492,7 +492,7 @@ being able to route MSI between busses. In this case, MSI have to be
|
||||||
disabled on all devices behind this bridge. It is achieves by setting
|
disabled on all devices behind this bridge. It is achieves by setting
|
||||||
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
|
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
|
||||||
subordinate bus. There is no need to set the same flag on bridges that
|
subordinate bus. There is no need to set the same flag on bridges that
|
||||||
are below the broken brigde. When pci_enable_msi() is called to enable
|
are below the broken bridge. When pci_enable_msi() is called to enable
|
||||||
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
|
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
|
||||||
flag in all parent busses of the device.
|
flag in all parent busses of the device.
|
||||||
|
|
||||||
|
|
|
@ -73,10 +73,14 @@ kernel patches.
|
||||||
If the new code is substantial, addition of subsystem-specific fault
|
If the new code is substantial, addition of subsystem-specific fault
|
||||||
injection might be appropriate.
|
injection might be appropriate.
|
||||||
|
|
||||||
22: Newly-added code has been compiled with `gcc -W'. This will generate
|
22: Newly-added code has been compiled with `gcc -W' (use "make
|
||||||
lots of noise, but is good for finding bugs like "warning: comparison
|
EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
|
||||||
between signed and unsigned".
|
finding bugs like "warning: comparison between signed and unsigned".
|
||||||
|
|
||||||
23: Tested after it has been merged into the -mm patchset to make sure
|
23: Tested after it has been merged into the -mm patchset to make sure
|
||||||
that it still works with all of the other queued patches and various
|
that it still works with all of the other queued patches and various
|
||||||
changes in the VM, VFS, and other subsystems.
|
changes in the VM, VFS, and other subsystems.
|
||||||
|
|
||||||
|
24: Avoid whitespace damage such as indenting with spaces or whitespace
|
||||||
|
at the end of lines. You can test this by feeding the patch to
|
||||||
|
"git apply --check --whitespace=error-all"
|
||||||
|
|
|
@ -87,6 +87,21 @@ Clarity: It helps if anyone can see how to fix the driver. It helps
|
||||||
driver that intentionally obfuscates how the hardware works
|
driver that intentionally obfuscates how the hardware works
|
||||||
it will go in the bitbucket.
|
it will go in the bitbucket.
|
||||||
|
|
||||||
|
PM support: Since Linux is used on many portable and desktop systems, your
|
||||||
|
driver is likely to be used on such a system and therefore it
|
||||||
|
should support basic power management by implementing, if
|
||||||
|
necessary, the .suspend and .resume methods used during the
|
||||||
|
system-wide suspend and resume transitions. You should verify
|
||||||
|
that your driver correctly handles the suspend and resume, but
|
||||||
|
if you are unable to ensure that, please at least define the
|
||||||
|
.suspend method returning the -ENOSYS ("Function not
|
||||||
|
implemented") error. You should also try to make sure that your
|
||||||
|
driver uses as little power as possible when it's not doing
|
||||||
|
anything. For the driver testing instructions see
|
||||||
|
Documentation/power/drivers-testing.txt and for a relatively
|
||||||
|
complete overview of the power management issues related to
|
||||||
|
drivers see Documentation/power/devices.txt .
|
||||||
|
|
||||||
Control: In general if there is active maintainance of a driver by
|
Control: In general if there is active maintainance of a driver by
|
||||||
the author then patches will be redirected to them unless
|
the author then patches will be redirected to them unless
|
||||||
they are totally obvious and without need of checking.
|
they are totally obvious and without need of checking.
|
||||||
|
|
|
@ -363,7 +363,8 @@ area or subsystem of the kernel is being patched.
|
||||||
The "summary phrase" in the email's Subject should concisely
|
The "summary phrase" in the email's Subject should concisely
|
||||||
describe the patch which that email contains. The "summary
|
describe the patch which that email contains. The "summary
|
||||||
phrase" should not be a filename. Do not use the same "summary
|
phrase" should not be a filename. Do not use the same "summary
|
||||||
phrase" for every patch in a whole patch series.
|
phrase" for every patch in a whole patch series (where a "patch
|
||||||
|
series" is an ordered sequence of multiple, related patches).
|
||||||
|
|
||||||
Bear in mind that the "summary phrase" of your email becomes
|
Bear in mind that the "summary phrase" of your email becomes
|
||||||
a globally-unique identifier for that patch. It propagates
|
a globally-unique identifier for that patch. It propagates
|
||||||
|
|
|
@ -61,8 +61,6 @@ __u64 stime, utime;
|
||||||
#define MAX_MSG_SIZE 1024
|
#define MAX_MSG_SIZE 1024
|
||||||
/* Maximum number of cpus expected to be specified in a cpumask */
|
/* Maximum number of cpus expected to be specified in a cpumask */
|
||||||
#define MAX_CPUS 32
|
#define MAX_CPUS 32
|
||||||
/* Maximum length of pathname to log file */
|
|
||||||
#define MAX_FILENAME 256
|
|
||||||
|
|
||||||
struct msgtemplate {
|
struct msgtemplate {
|
||||||
struct nlmsghdr n;
|
struct nlmsghdr n;
|
||||||
|
@ -72,6 +70,16 @@ struct msgtemplate {
|
||||||
|
|
||||||
char cpumask[100+6*MAX_CPUS];
|
char cpumask[100+6*MAX_CPUS];
|
||||||
|
|
||||||
|
static void usage(void)
|
||||||
|
{
|
||||||
|
fprintf(stderr, "getdelays [-dilv] [-w logfile] [-r bufsize] "
|
||||||
|
"[-m cpumask] [-t tgid] [-p pid]\n");
|
||||||
|
fprintf(stderr, " -d: print delayacct stats\n");
|
||||||
|
fprintf(stderr, " -i: print IO accounting (works only with -p)\n");
|
||||||
|
fprintf(stderr, " -l: listen forever\n");
|
||||||
|
fprintf(stderr, " -v: debug on\n");
|
||||||
|
}
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* Create a raw netlink socket and bind
|
* Create a raw netlink socket and bind
|
||||||
*/
|
*/
|
||||||
|
@ -221,13 +229,13 @@ int main(int argc, char *argv[])
|
||||||
int count = 0;
|
int count = 0;
|
||||||
int write_file = 0;
|
int write_file = 0;
|
||||||
int maskset = 0;
|
int maskset = 0;
|
||||||
char logfile[128];
|
char *logfile = NULL;
|
||||||
int loop = 0;
|
int loop = 0;
|
||||||
|
|
||||||
struct msgtemplate msg;
|
struct msgtemplate msg;
|
||||||
|
|
||||||
while (1) {
|
while (1) {
|
||||||
c = getopt(argc, argv, "diw:r:m:t:p:v:l");
|
c = getopt(argc, argv, "diw:r:m:t:p:vl");
|
||||||
if (c < 0)
|
if (c < 0)
|
||||||
break;
|
break;
|
||||||
|
|
||||||
|
@ -241,7 +249,7 @@ int main(int argc, char *argv[])
|
||||||
print_io_accounting = 1;
|
print_io_accounting = 1;
|
||||||
break;
|
break;
|
||||||
case 'w':
|
case 'w':
|
||||||
strncpy(logfile, optarg, MAX_FILENAME);
|
logfile = strdup(optarg);
|
||||||
printf("write to file %s\n", logfile);
|
printf("write to file %s\n", logfile);
|
||||||
write_file = 1;
|
write_file = 1;
|
||||||
break;
|
break;
|
||||||
|
@ -277,7 +285,7 @@ int main(int argc, char *argv[])
|
||||||
loop = 1;
|
loop = 1;
|
||||||
break;
|
break;
|
||||||
default:
|
default:
|
||||||
printf("Unknown option %d\n", c);
|
usage();
|
||||||
exit(-1);
|
exit(-1);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
@ -149,7 +149,7 @@ So, what's changed?
|
||||||
|
|
||||||
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
|
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
|
||||||
|
|
||||||
4. Direct access to SA1111 INTPOL is depreciated. Use set_irq_type instead.
|
4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead.
|
||||||
|
|
||||||
5. A handler is expected to perform any necessary acknowledgement of the
|
5. A handler is expected to perform any necessary acknowledgement of the
|
||||||
parent IRQ via the correct chip specific function. For instance, if
|
parent IRQ via the correct chip specific function. For instance, if
|
||||||
|
|
|
@ -23,7 +23,7 @@ Support
|
||||||
|
|
||||||
http://handhelds.org/moin/moin.cgi/HpIpaqH1940
|
http://handhelds.org/moin/moin.cgi/HpIpaqH1940
|
||||||
|
|
||||||
Herbert Pötzl pages:
|
Herbert Pötzl pages:
|
||||||
|
|
||||||
http://vserver.13thfloor.at/H1940/
|
http://vserver.13thfloor.at/H1940/
|
||||||
|
|
||||||
|
@ -32,7 +32,7 @@ Maintainers
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This project is being maintained and developed by a variety
|
This project is being maintained and developed by a variety
|
||||||
of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
|
of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
|
||||||
|
|
||||||
Thanks to the many others who have also provided support.
|
Thanks to the many others who have also provided support.
|
||||||
|
|
||||||
|
|
|
@ -78,9 +78,9 @@ Select (17)------------------------------(16) Data / Instruction
|
||||||
Ground (18)---[GND] [+5v]---(19) LED +
|
Ground (18)---[GND] [+5v]---(19) LED +
|
||||||
Ground (19)---[GND]
|
Ground (19)---[GND]
|
||||||
Ground (20)---[GND] E A Values:
|
Ground (20)---[GND] E A Values:
|
||||||
Ground (21)---[GND] [GND]---[P1]---(18) Vee · R = Resistor = 22 ohm
|
Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm
|
||||||
Ground (22)---[GND] | · P1 = Preset = 10 Kohm
|
Ground (22)---[GND] | - P1 = Preset = 10 Kohm
|
||||||
Ground (23)---[GND] ---- S ------( 3) V0 · P2 = Preset = 1 Kohm
|
Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm
|
||||||
Ground (24)---[GND] | |
|
Ground (24)---[GND] | |
|
||||||
Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED -
|
Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED -
|
||||||
|
|
||||||
|
|
|
@ -113,4 +113,4 @@ cause unexpected behaviour and can be a security hazard.
|
||||||
There is a web page about binfmt_misc at
|
There is a web page about binfmt_misc at
|
||||||
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html
|
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html
|
||||||
|
|
||||||
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
|
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
|
||||||
|
|
|
@ -0,0 +1,11 @@
|
||||||
|
00-INDEX
|
||||||
|
- This file
|
||||||
|
|
||||||
|
cache-lock.txt
|
||||||
|
- HOWTO for blackfin cache locking.
|
||||||
|
|
||||||
|
cachefeatures.txt
|
||||||
|
- Supported cache features.
|
||||||
|
|
||||||
|
Filesystems
|
||||||
|
- Requirements for mounting the root file system.
|
|
@ -0,0 +1,169 @@
|
||||||
|
/*
|
||||||
|
* File: Documentation/blackfin/Filesystems
|
||||||
|
* Based on:
|
||||||
|
* Author:
|
||||||
|
*
|
||||||
|
* Created:
|
||||||
|
* Description: This file contains the simple DMA Implementation for Blackfin
|
||||||
|
*
|
||||||
|
* Rev: $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $
|
||||||
|
*
|
||||||
|
* Modified:
|
||||||
|
* Copyright 2004-2006 Analog Devices Inc.
|
||||||
|
*
|
||||||
|
* Bugs: Enter bugs at http://blackfin.uclinux.org/
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
|
||||||
|
How to mount the root file system in uClinux/Blackfin
|
||||||
|
-----------------------------------------------------
|
||||||
|
|
||||||
|
1 Mounting EXT3 File system.
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Creating an EXT3 File system for uClinux/Blackfin:
|
||||||
|
|
||||||
|
|
||||||
|
Please follow the steps to form the EXT3 File system and mount the same as root
|
||||||
|
file system.
|
||||||
|
|
||||||
|
a Make an ext3 file system as large as you want the final root file
|
||||||
|
system.
|
||||||
|
|
||||||
|
mkfs.ext3 /dev/ram0 <your-rootfs-size-in-1k-blocks>
|
||||||
|
|
||||||
|
b Mount this Empty file system on a free directory as:
|
||||||
|
|
||||||
|
mount -t ext3 /dev/ram0 ./test
|
||||||
|
where ./test is the empty directory.
|
||||||
|
|
||||||
|
c Copy your root fs directory that you have so carefully made over.
|
||||||
|
|
||||||
|
cp -af /tmp/my_final_rootfs_files/* ./test
|
||||||
|
|
||||||
|
(For ex: cp -af uClinux-dist/romfs/* ./test)
|
||||||
|
|
||||||
|
d If you have done everything right till now you should be able to see
|
||||||
|
the required "root" dir's (that's etc, root, bin, lib, sbin...)
|
||||||
|
|
||||||
|
e Now unmount the file system
|
||||||
|
|
||||||
|
umount ./test
|
||||||
|
|
||||||
|
f Create the root file system image.
|
||||||
|
|
||||||
|
dd if=/dev/ram0 bs=1k count=<your-rootfs-size-in-1k-blocks> \
|
||||||
|
> ext3fs.img
|
||||||
|
|
||||||
|
|
||||||
|
Now you have to tell the kernel that will be mounting this file system as
|
||||||
|
rootfs.
|
||||||
|
So do a make menuconfig under kernel and select the Ext3 journaling file system
|
||||||
|
support under File system --> submenu.
|
||||||
|
|
||||||
|
|
||||||
|
2. Mounting EXT2 File system.
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
By default the ext2 file system image will be created if you invoke make from
|
||||||
|
the top uClinux-dist directory.
|
||||||
|
|
||||||
|
|
||||||
|
3. Mounting CRAMFS File System
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
To create a CRAMFS file system image execute the command
|
||||||
|
|
||||||
|
mkfs.cramfs ./test cramfs.img
|
||||||
|
|
||||||
|
where ./test is the target directory.
|
||||||
|
|
||||||
|
|
||||||
|
4. Mounting ROMFS File System
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
To create a ROMFS file system image execute the command
|
||||||
|
|
||||||
|
genromfs -v -V "ROMdisk" -f romfs.img -d ./test
|
||||||
|
|
||||||
|
where ./test is the target directory
|
||||||
|
|
||||||
|
|
||||||
|
5. Mounting the JFFS2 Filesystem
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
To create a compressed JFFS filesystem (JFFS2), please execute the command
|
||||||
|
|
||||||
|
mkfs.jffs2 -d ./test -o jffs2.img
|
||||||
|
|
||||||
|
where ./test is the target directory.
|
||||||
|
|
||||||
|
However, please make sure the following is in your kernel config.
|
||||||
|
|
||||||
|
/*
|
||||||
|
* RAM/ROM/Flash chip drivers
|
||||||
|
*/
|
||||||
|
#define CONFIG_MTD_CFI 1
|
||||||
|
#define CONFIG_MTD_ROM 1
|
||||||
|
/*
|
||||||
|
* Mapping drivers for chip access
|
||||||
|
*/
|
||||||
|
#define CONFIG_MTD_COMPLEX_MAPPINGS 1
|
||||||
|
#define CONFIG_MTD_BF533 1
|
||||||
|
#undef CONFIG_MTD_UCLINUX
|
||||||
|
|
||||||
|
Through the u-boot boot loader, use the jffs2.img in the corresponding
|
||||||
|
partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c.
|
||||||
|
|
||||||
|
NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a
|
||||||
|
STAMP driver soon.
|
||||||
|
|
||||||
|
|
||||||
|
6. Mounting the NFS File system
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
For mounting the NFS please do the following in the kernel config.
|
||||||
|
|
||||||
|
In Networking Support --> Networking options --> TCP/IP networking -->
|
||||||
|
IP: kernel level autoconfiguration
|
||||||
|
|
||||||
|
Enable BOOTP Support.
|
||||||
|
|
||||||
|
In Kernel hacking --> Compiled-in kernel boot parameter add the following
|
||||||
|
|
||||||
|
root=/dev/nfs rw ip=bootp
|
||||||
|
|
||||||
|
In File system --> Network File system, Enable
|
||||||
|
|
||||||
|
NFS file system support --> NFSv3 client support
|
||||||
|
Root File system on NFS
|
||||||
|
|
||||||
|
in uClibc menuconfig, do the following
|
||||||
|
In Networking Support
|
||||||
|
enable Remote Procedure Call (RPC) support
|
||||||
|
Full RPC Support
|
||||||
|
|
||||||
|
On the Host side, ensure that /etc/dhcpd.conf looks something like this
|
||||||
|
|
||||||
|
ddns-update-style ad-hoc;
|
||||||
|
allow bootp;
|
||||||
|
subnet 10.100.4.0 netmask 255.255.255.0 {
|
||||||
|
default-lease-time 122209600;
|
||||||
|
max-lease-time 31557600;
|
||||||
|
group {
|
||||||
|
host bf533 {
|
||||||
|
hardware ethernet 00:CF:52:49:C3:01;
|
||||||
|
fixed-address 10.100.4.50;
|
||||||
|
option root-path "/home/nfsmount";
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
ensure that /etc/exports looks something like this
|
||||||
|
/home/nfsmount *(rw,no_root_squash,no_all_squash)
|
||||||
|
|
||||||
|
run the following commands as root (may differ depending on your
|
||||||
|
distribution) :
|
||||||
|
- service nfs start
|
||||||
|
- service portmap start
|
||||||
|
- service dhcpd start
|
||||||
|
- /usr/sbin/exportfs
|
|
@ -0,0 +1,48 @@
|
||||||
|
/*
|
||||||
|
* File: Documentation/blackfin/cache-lock.txt
|
||||||
|
* Based on:
|
||||||
|
* Author:
|
||||||
|
*
|
||||||
|
* Created:
|
||||||
|
* Description: This file contains the simple DMA Implementation for Blackfin
|
||||||
|
*
|
||||||
|
* Rev: $Id: cache-lock.txt 2384 2006-11-01 04:12:43Z magicyang $
|
||||||
|
*
|
||||||
|
* Modified:
|
||||||
|
* Copyright 2004-2006 Analog Devices Inc.
|
||||||
|
*
|
||||||
|
* Bugs: Enter bugs at http://blackfin.uclinux.org/
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
|
||||||
|
How to lock your code in cache in uClinux/blackfin
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
There are only a few steps required to lock your code into the cache.
|
||||||
|
Currently you can lock the code by Way.
|
||||||
|
|
||||||
|
Below are the interface provided for locking the cache.
|
||||||
|
|
||||||
|
|
||||||
|
1. cache_grab_lock(int Ways);
|
||||||
|
|
||||||
|
This function grab the lock for locking your code into the cache specified
|
||||||
|
by Ways.
|
||||||
|
|
||||||
|
|
||||||
|
2. cache_lock(int Ways);
|
||||||
|
|
||||||
|
This function should be called after your critical code has been executed.
|
||||||
|
Once the critical code exits, the code is now loaded into the cache. This
|
||||||
|
function locks the code into the cache.
|
||||||
|
|
||||||
|
|
||||||
|
So, the example sequence will be:
|
||||||
|
|
||||||
|
cache_grab_lock(WAY0_L); /* Grab the lock */
|
||||||
|
|
||||||
|
critical_code(); /* Execute the code of interest */
|
||||||
|
|
||||||
|
cache_lock(WAY0_L); /* Lock the cache */
|
||||||
|
|
||||||
|
Where WAY0_L signifies WAY0 locking.
|
|
@ -0,0 +1,65 @@
|
||||||
|
/*
|
||||||
|
* File: Documentation/blackfin/cachefeatures.txt
|
||||||
|
* Based on:
|
||||||
|
* Author:
|
||||||
|
*
|
||||||
|
* Created:
|
||||||
|
* Description: This file contains the simple DMA Implementation for Blackfin
|
||||||
|
*
|
||||||
|
* Rev: $Id: cachefeatures.txt 2384 2006-11-01 04:12:43Z magicyang $
|
||||||
|
*
|
||||||
|
* Modified:
|
||||||
|
* Copyright 2004-2006 Analog Devices Inc.
|
||||||
|
*
|
||||||
|
* Bugs: Enter bugs at http://blackfin.uclinux.org/
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
|
||||||
|
- Instruction and Data cache initialization.
|
||||||
|
icache_init();
|
||||||
|
dcache_init();
|
||||||
|
|
||||||
|
- Instruction and Data cache Invalidation Routines, when flushing the
|
||||||
|
same is not required.
|
||||||
|
_icache_invalidate();
|
||||||
|
_dcache_invalidate();
|
||||||
|
|
||||||
|
Also, for invalidating the entire instruction and data cache, the below
|
||||||
|
routines are provided (another method for invalidation, refer page no 267 and 287 of
|
||||||
|
ADSP-BF533 Hardware Reference manual)
|
||||||
|
|
||||||
|
invalidate_entire_dcache();
|
||||||
|
invalidate_entire_icache();
|
||||||
|
|
||||||
|
-External Flushing of Instruction and data cache routines.
|
||||||
|
|
||||||
|
flush_instruction_cache();
|
||||||
|
flush_data_cache();
|
||||||
|
|
||||||
|
- Internal Flushing of Instruction and Data Cache.
|
||||||
|
|
||||||
|
icplb_flush();
|
||||||
|
dcplb_flush();
|
||||||
|
|
||||||
|
- Locking the cache.
|
||||||
|
|
||||||
|
cache_grab_lock();
|
||||||
|
cache_lock();
|
||||||
|
|
||||||
|
Please refer linux-2.6.x/Documentation/blackfin/cache-lock.txt for how to
|
||||||
|
lock the cache.
|
||||||
|
|
||||||
|
Locking the cache is optional feature.
|
||||||
|
|
||||||
|
- Miscellaneous cache functions.
|
||||||
|
|
||||||
|
flush_cache_all();
|
||||||
|
flush_cache_mm();
|
||||||
|
invalidate_dcache_range();
|
||||||
|
flush_dcache_range();
|
||||||
|
flush_dcache_page();
|
||||||
|
flush_cache_range();
|
||||||
|
flush_cache_page();
|
||||||
|
invalidate_dcache_range();
|
||||||
|
flush_page_to_ram();
|
||||||
|
|
|
@ -6,10 +6,10 @@ Intro
|
||||||
-----
|
-----
|
||||||
|
|
||||||
With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
|
With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
|
||||||
priorities is supported for reads on files. This enables users to io nice
|
priorities are supported for reads on files. This enables users to io nice
|
||||||
processes or process groups, similar to what has been possible to cpu
|
processes or process groups, similar to what has been possible with cpu
|
||||||
scheduling for ages. This document mainly details the current possibilites
|
scheduling for ages. This document mainly details the current possibilities
|
||||||
with cfq, other io schedulers do not support io priorities so far.
|
with cfq; other io schedulers do not support io priorities thus far.
|
||||||
|
|
||||||
Scheduling classes
|
Scheduling classes
|
||||||
------------------
|
------------------
|
||||||
|
|
|
@ -22,14 +22,21 @@ This driver is known to work with the following cards:
|
||||||
* SA E200i
|
* SA E200i
|
||||||
* SA E500
|
* SA E500
|
||||||
|
|
||||||
|
Detecting drive failures:
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
To get the status of logical volumes and to detect physical drive
|
||||||
|
failures, you can use the cciss_vol_status program found here:
|
||||||
|
http://cciss.sourceforge.net/#cciss_utils
|
||||||
|
|
||||||
|
Device Naming:
|
||||||
|
--------------
|
||||||
|
|
||||||
If nodes are not already created in the /dev/cciss directory, run as root:
|
If nodes are not already created in the /dev/cciss directory, run as root:
|
||||||
|
|
||||||
# cd /dev
|
# cd /dev
|
||||||
# ./MAKEDEV cciss
|
# ./MAKEDEV cciss
|
||||||
|
|
||||||
Device Naming:
|
|
||||||
--------------
|
|
||||||
|
|
||||||
You need some entries in /dev for the cciss device. The MAKEDEV script
|
You need some entries in /dev for the cciss device. The MAKEDEV script
|
||||||
can make device nodes for you automatically. Currently the device setup
|
can make device nodes for you automatically. Currently the device setup
|
||||||
is as follows:
|
is as follows:
|
||||||
|
|
|
@ -17,7 +17,7 @@ Contents
|
||||||
|
|
||||||
1. Introduction
|
1. Introduction
|
||||||
|
|
||||||
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
|
cpufreq-stats is a driver that provides CPU frequency statistics for each CPU.
|
||||||
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
|
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
|
||||||
interface (when configured) will appear in a separate directory under cpufreq
|
interface (when configured) will appear in a separate directory under cpufreq
|
||||||
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
|
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
|
||||||
|
|
|
@ -217,14 +217,17 @@ Q: What happens when a CPU is being logically offlined?
|
||||||
A: The following happen, listed in no particular order :-)
|
A: The following happen, listed in no particular order :-)
|
||||||
|
|
||||||
- A notification is sent to in-kernel registered modules by sending an event
|
- A notification is sent to in-kernel registered modules by sending an event
|
||||||
CPU_DOWN_PREPARE
|
CPU_DOWN_PREPARE or CPU_DOWN_PREPARE_FROZEN, depending on whether or not the
|
||||||
|
CPU is being offlined while tasks are frozen due to a suspend operation in
|
||||||
|
progress
|
||||||
- All process is migrated away from this outgoing CPU to a new CPU
|
- All process is migrated away from this outgoing CPU to a new CPU
|
||||||
- All interrupts targeted to this CPU is migrated to a new CPU
|
- All interrupts targeted to this CPU is migrated to a new CPU
|
||||||
- timers/bottom half/task lets are also migrated to a new CPU
|
- timers/bottom half/task lets are also migrated to a new CPU
|
||||||
- Once all services are migrated, kernel calls an arch specific routine
|
- Once all services are migrated, kernel calls an arch specific routine
|
||||||
__cpu_disable() to perform arch specific cleanup.
|
__cpu_disable() to perform arch specific cleanup.
|
||||||
- Once this is successful, an event for successful cleanup is sent by an event
|
- Once this is successful, an event for successful cleanup is sent by an event
|
||||||
CPU_DEAD.
|
CPU_DEAD (or CPU_DEAD_FROZEN if tasks are frozen due to a suspend while the
|
||||||
|
CPU is being offlined).
|
||||||
|
|
||||||
"It is expected that each service cleans up when the CPU_DOWN_PREPARE
|
"It is expected that each service cleans up when the CPU_DOWN_PREPARE
|
||||||
notifier is called, when CPU_DEAD is called its expected there is nothing
|
notifier is called, when CPU_DEAD is called its expected there is nothing
|
||||||
|
@ -242,9 +245,11 @@ A: This is what you would need in your kernel code to receive notifications.
|
||||||
|
|
||||||
switch (action) {
|
switch (action) {
|
||||||
case CPU_ONLINE:
|
case CPU_ONLINE:
|
||||||
|
case CPU_ONLINE_FROZEN:
|
||||||
foobar_online_action(cpu);
|
foobar_online_action(cpu);
|
||||||
break;
|
break;
|
||||||
case CPU_DEAD:
|
case CPU_DEAD:
|
||||||
|
case CPU_DEAD_FROZEN:
|
||||||
foobar_dead_action(cpu);
|
foobar_dead_action(cpu);
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
|
|
|
@ -177,7 +177,7 @@ Portions of this API were derived from the following projects:
|
||||||
and;
|
and;
|
||||||
|
|
||||||
Nettle (http://www.lysator.liu.se/~nisse/nettle/)
|
Nettle (http://www.lysator.liu.se/~nisse/nettle/)
|
||||||
Niels Möller
|
Niels Möller
|
||||||
|
|
||||||
Original developers of the crypto algorithms:
|
Original developers of the crypto algorithms:
|
||||||
|
|
||||||
|
@ -200,8 +200,8 @@ SHA1 algorithm contributors:
|
||||||
|
|
||||||
DES algorithm contributors:
|
DES algorithm contributors:
|
||||||
Raimar Falke
|
Raimar Falke
|
||||||
Gisle Sælensminde
|
Gisle Sælensminde
|
||||||
Niels Möller
|
Niels Möller
|
||||||
|
|
||||||
Blowfish algorithm contributors:
|
Blowfish algorithm contributors:
|
||||||
Herbert Valerio Riedel
|
Herbert Valerio Riedel
|
||||||
|
|
|
@ -0,0 +1,26 @@
|
||||||
|
dm-delay
|
||||||
|
========
|
||||||
|
|
||||||
|
Device-Mapper's "delay" target delays reads and/or writes
|
||||||
|
and maps them to different devices.
|
||||||
|
|
||||||
|
Parameters:
|
||||||
|
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>]
|
||||||
|
|
||||||
|
With separate write parameters, the first set is only used for reads.
|
||||||
|
Delays are specified in milliseconds.
|
||||||
|
|
||||||
|
Example scripts
|
||||||
|
===============
|
||||||
|
[[
|
||||||
|
#!/bin/sh
|
||||||
|
# Create device delaying rw operation for 500ms
|
||||||
|
echo "0 `blockdev --getsize $1` delay $1 0 500" | dmsetup create delayed
|
||||||
|
]]
|
||||||
|
|
||||||
|
[[
|
||||||
|
#!/bin/sh
|
||||||
|
# Create device delaying only write operation for 500ms and
|
||||||
|
# splitting reads and writes to different devices $1 $2
|
||||||
|
echo "0 `blockdev --getsize $1` delay $1 0 0 $2 0 500" | dmsetup create delayed
|
||||||
|
]]
|
|
@ -55,8 +55,8 @@ aic7*seq.h*
|
||||||
aicasm
|
aicasm
|
||||||
aicdb.h*
|
aicdb.h*
|
||||||
asm
|
asm
|
||||||
asm-offsets.*
|
asm-offsets.h
|
||||||
asm_offsets.*
|
asm_offsets.h
|
||||||
autoconf.h*
|
autoconf.h*
|
||||||
bbootsect
|
bbootsect
|
||||||
bin2c
|
bin2c
|
||||||
|
|
|
@ -182,7 +182,7 @@ For example, you can do something like the following.
|
||||||
|
|
||||||
...
|
...
|
||||||
|
|
||||||
devres_close_group(dev, my_midlayer_something);
|
devres_close_group(dev, my_midlayer_create_something);
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -16,7 +16,7 @@ host bridges to peripheral buses, and most controllers integrated
|
||||||
into system-on-chip platforms. What they usually have in common
|
into system-on-chip platforms. What they usually have in common
|
||||||
is direct addressing from a CPU bus. Rarely, a platform_device will
|
is direct addressing from a CPU bus. Rarely, a platform_device will
|
||||||
be connected through a segment of some other kind of bus; but its
|
be connected through a segment of some other kind of bus; but its
|
||||||
registers will still be directly addressible.
|
registers will still be directly addressable.
|
||||||
|
|
||||||
Platform devices are given a name, used in driver binding, and a
|
Platform devices are given a name, used in driver binding, and a
|
||||||
list of resources such as addresses and IRQs.
|
list of resources such as addresses and IRQs.
|
||||||
|
@ -125,7 +125,7 @@ three different ways to find such a match:
|
||||||
usually register later during booting, or by module loading.
|
usually register later during booting, or by module loading.
|
||||||
|
|
||||||
- Registering a driver using platform_driver_probe() works just like
|
- Registering a driver using platform_driver_probe() works just like
|
||||||
using platform_driver_register(), except that the the driver won't
|
using platform_driver_register(), except that the driver won't
|
||||||
be probed later if another device registers. (Which is OK, since
|
be probed later if another device registers. (Which is OK, since
|
||||||
this interface is only for use with non-hotpluggable devices.)
|
this interface is only for use with non-hotpluggable devices.)
|
||||||
|
|
||||||
|
|
|
@ -228,5 +228,5 @@ Patches, comments and suggestions are very very welcome.
|
||||||
|
|
||||||
Ulf Hermenau for helping me out with traditional chinese.
|
Ulf Hermenau for helping me out with traditional chinese.
|
||||||
|
|
||||||
André Smoktun and Christian Frömmel for supporting me with
|
André Smoktun and Christian Frömmel for supporting me with
|
||||||
hardware and listening to my problems very patiently.
|
hardware and listening to my problems very patiently.
|
||||||
|
|
|
@ -66,7 +66,7 @@ Michael Dreher <michael@5dot1.de>
|
||||||
Andreas 'randy' Weinberger
|
Andreas 'randy' Weinberger
|
||||||
for the support of the Fujitsu-Siemens Activy budget DVB-S
|
for the support of the Fujitsu-Siemens Activy budget DVB-S
|
||||||
|
|
||||||
Kenneth Aafløy <ke-aa@frisurf.no>
|
Kenneth Aafløy <ke-aa@frisurf.no>
|
||||||
for adding support for Typhoon DVB-S budget card
|
for adding support for Typhoon DVB-S budget card
|
||||||
|
|
||||||
Ernst Peinlich <e.peinlich@inode.at>
|
Ernst Peinlich <e.peinlich@inode.at>
|
||||||
|
|
|
@ -0,0 +1,68 @@
|
||||||
|
|
||||||
|
arkfb - fbdev driver for ARK Logic chips
|
||||||
|
========================================
|
||||||
|
|
||||||
|
|
||||||
|
Supported Hardware
|
||||||
|
==================
|
||||||
|
|
||||||
|
ARK 2000PV chip
|
||||||
|
ICS 5342 ramdac
|
||||||
|
|
||||||
|
- only BIOS initialized VGA devices supported
|
||||||
|
- probably not working on big endian
|
||||||
|
|
||||||
|
|
||||||
|
Supported Features
|
||||||
|
==================
|
||||||
|
|
||||||
|
* 4 bpp pseudocolor modes (with 18bit palette, two variants)
|
||||||
|
* 8 bpp pseudocolor mode (with 18bit palette)
|
||||||
|
* 16 bpp truecolor modes (RGB 555 and RGB 565)
|
||||||
|
* 24 bpp truecolor mode (RGB 888)
|
||||||
|
* 32 bpp truecolor mode (RGB 888)
|
||||||
|
* text mode (activated by bpp = 0)
|
||||||
|
* doublescan mode variant (not available in text mode)
|
||||||
|
* panning in both directions
|
||||||
|
* suspend/resume support
|
||||||
|
|
||||||
|
Text mode is supported even in higher resolutions, but there is limitation to
|
||||||
|
lower pixclocks (i got maximum about 70 MHz, it is dependent on specific
|
||||||
|
hardware). This limitation is not enforced by driver. Text mode supports 8bit
|
||||||
|
wide fonts only (hardware limitation) and 16bit tall fonts (driver
|
||||||
|
limitation). Unfortunately character attributes (like color) in text mode are
|
||||||
|
broken for unknown reason, so its usefulness is limited.
|
||||||
|
|
||||||
|
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
|
||||||
|
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
|
||||||
|
with interleaved planes (1 byte interleave), MSB first. Both modes support
|
||||||
|
8bit wide fonts only (driver limitation).
|
||||||
|
|
||||||
|
Suspend/resume works on systems that initialize video card during resume and
|
||||||
|
if device is active (for example used by fbcon).
|
||||||
|
|
||||||
|
|
||||||
|
Missing Features
|
||||||
|
================
|
||||||
|
(alias TODO list)
|
||||||
|
|
||||||
|
* secondary (not initialized by BIOS) device support
|
||||||
|
* big endian support
|
||||||
|
* DPMS support
|
||||||
|
* MMIO support
|
||||||
|
* interlaced mode variant
|
||||||
|
* support for fontwidths != 8 in 4 bpp modes
|
||||||
|
* support for fontheight != 16 in text mode
|
||||||
|
* hardware cursor
|
||||||
|
* vsync synchronization
|
||||||
|
* feature connector support
|
||||||
|
* acceleration support (8514-like 2D)
|
||||||
|
|
||||||
|
|
||||||
|
Known bugs
|
||||||
|
==========
|
||||||
|
|
||||||
|
* character attributes (and cursor) in text mode are broken
|
||||||
|
|
||||||
|
--
|
||||||
|
Ondrej Zajicek <santiago@crfreenet.org>
|
|
@ -54,8 +54,8 @@ Accepted options:
|
||||||
|
|
||||||
noaccel - do not use acceleration engine. It is default.
|
noaccel - do not use acceleration engine. It is default.
|
||||||
accel - use acceleration engine. Not finished.
|
accel - use acceleration engine. Not finished.
|
||||||
vmode:x - chooses PowerMacintosh video mode <x>. Depreciated.
|
vmode:x - chooses PowerMacintosh video mode <x>. Deprecated.
|
||||||
cmode:x - chooses PowerMacintosh colour mode <x>. Depreciated.
|
cmode:x - chooses PowerMacintosh colour mode <x>. Deprecated.
|
||||||
<XxX@X> - selects startup videomode. See modedb.txt for detailed
|
<XxX@X> - selects startup videomode. See modedb.txt for detailed
|
||||||
explanation. Default is 640x480x8bpp.
|
explanation. Default is 640x480x8bpp.
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,75 @@
|
||||||
|
Deferred IO
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Deferred IO is a way to delay and repurpose IO. It uses host memory as a
|
||||||
|
buffer and the MMU pagefault as a pretrigger for when to perform the device
|
||||||
|
IO. The following example may be a useful explaination of how one such setup
|
||||||
|
works:
|
||||||
|
|
||||||
|
- userspace app like Xfbdev mmaps framebuffer
|
||||||
|
- deferred IO and driver sets up nopage and page_mkwrite handlers
|
||||||
|
- userspace app tries to write to mmaped vaddress
|
||||||
|
- we get pagefault and reach nopage handler
|
||||||
|
- nopage handler finds and returns physical page
|
||||||
|
- we get page_mkwrite where we add this page to a list
|
||||||
|
- schedule a workqueue task to be run after a delay
|
||||||
|
- app continues writing to that page with no additional cost. this is
|
||||||
|
the key benefit.
|
||||||
|
- the workqueue task comes in and mkcleans the pages on the list, then
|
||||||
|
completes the work associated with updating the framebuffer. this is
|
||||||
|
the real work talking to the device.
|
||||||
|
- app tries to write to the address (that has now been mkcleaned)
|
||||||
|
- get pagefault and the above sequence occurs again
|
||||||
|
|
||||||
|
As can be seen from above, one benefit is roughly to allow bursty framebuffer
|
||||||
|
writes to occur at minimum cost. Then after some time when hopefully things
|
||||||
|
have gone quiet, we go and really update the framebuffer which would be
|
||||||
|
a relatively more expensive operation.
|
||||||
|
|
||||||
|
For some types of nonvolatile high latency displays, the desired image is
|
||||||
|
the final image rather than the intermediate stages which is why it's okay
|
||||||
|
to not update for each write that is occuring.
|
||||||
|
|
||||||
|
It may be the case that this is useful in other scenarios as well. Paul Mundt
|
||||||
|
has mentioned a case where it is beneficial to use the page count to decide
|
||||||
|
whether to coalesce and issue SG DMA or to do memory bursts.
|
||||||
|
|
||||||
|
Another one may be if one has a device framebuffer that is in an usual format,
|
||||||
|
say diagonally shifting RGB, this may then be a mechanism for you to allow
|
||||||
|
apps to pretend to have a normal framebuffer but reswizzle for the device
|
||||||
|
framebuffer at vsync time based on the touched pagelist.
|
||||||
|
|
||||||
|
How to use it: (for applications)
|
||||||
|
---------------------------------
|
||||||
|
No changes needed. mmap the framebuffer like normal and just use it.
|
||||||
|
|
||||||
|
How to use it: (for fbdev drivers)
|
||||||
|
----------------------------------
|
||||||
|
The following example may be helpful.
|
||||||
|
|
||||||
|
1. Setup your structure. Eg:
|
||||||
|
|
||||||
|
static struct fb_deferred_io hecubafb_defio = {
|
||||||
|
.delay = HZ,
|
||||||
|
.deferred_io = hecubafb_dpy_deferred_io,
|
||||||
|
};
|
||||||
|
|
||||||
|
The delay is the minimum delay between when the page_mkwrite trigger occurs
|
||||||
|
and when the deferred_io callback is called. The deferred_io callback is
|
||||||
|
explained below.
|
||||||
|
|
||||||
|
2. Setup your deferred IO callback. Eg:
|
||||||
|
static void hecubafb_dpy_deferred_io(struct fb_info *info,
|
||||||
|
struct list_head *pagelist)
|
||||||
|
|
||||||
|
The deferred_io callback is where you would perform all your IO to the display
|
||||||
|
device. You receive the pagelist which is the list of pages that were written
|
||||||
|
to during the delay. You must not modify this list. This callback is called
|
||||||
|
from a workqueue.
|
||||||
|
|
||||||
|
3. Call init
|
||||||
|
info->fbdefio = &hecubafb_defio;
|
||||||
|
fb_deferred_io_init(info);
|
||||||
|
|
||||||
|
4. Call cleanup
|
||||||
|
fb_deferred_io_cleanup(info);
|
|
@ -215,11 +215,11 @@ vertical retrace time is the sum of the upper margin, the lower margin and the
|
||||||
vsync length.
|
vsync length.
|
||||||
|
|
||||||
+----------+---------------------------------------------+----------+-------+
|
+----------+---------------------------------------------+----------+-------+
|
||||||
| | ^ | | |
|
| | ↑ | | |
|
||||||
| | |upper_margin | | |
|
| | |upper_margin | | |
|
||||||
| | ・ | | |
|
| | ↓ | | |
|
||||||
+----------###############################################----------+-------+
|
+----------###############################################----------+-------+
|
||||||
| # ^ # | |
|
| # ↑ # | |
|
||||||
| # | # | |
|
| # | # | |
|
||||||
| # | # | |
|
| # | # | |
|
||||||
| # | # | |
|
| # | # | |
|
||||||
|
@ -238,15 +238,15 @@ vsync length.
|
||||||
| # | # | |
|
| # | # | |
|
||||||
| # | # | |
|
| # | # | |
|
||||||
| # | # | |
|
| # | # | |
|
||||||
| # ・ # | |
|
| # ↓ # | |
|
||||||
+----------###############################################----------+-------+
|
+----------###############################################----------+-------+
|
||||||
| | ^ | | |
|
| | ↑ | | |
|
||||||
| | |lower_margin | | |
|
| | |lower_margin | | |
|
||||||
| | ・ | | |
|
| | ↓ | | |
|
||||||
+----------+---------------------------------------------+----------+-------+
|
+----------+---------------------------------------------+----------+-------+
|
||||||
| | ^ | | |
|
| | ↑ | | |
|
||||||
| | |vsync_len | | |
|
| | |vsync_len | | |
|
||||||
| | ・ | | |
|
| | ↓ | | |
|
||||||
+----------+---------------------------------------------+----------+-------+
|
+----------+---------------------------------------------+----------+-------+
|
||||||
|
|
||||||
The frame buffer device expects all horizontal timings in number of dotclocks
|
The frame buffer device expects all horizontal timings in number of dotclocks
|
||||||
|
|
|
@ -17,7 +17,7 @@ How to use it?
|
||||||
==============
|
==============
|
||||||
|
|
||||||
Imacfb does not have any kind of autodetection of your machine.
|
Imacfb does not have any kind of autodetection of your machine.
|
||||||
You have to add the fillowing kernel parameters in your elilo.conf:
|
You have to add the following kernel parameters in your elilo.conf:
|
||||||
Macbook :
|
Macbook :
|
||||||
video=imacfb:macbook
|
video=imacfb:macbook
|
||||||
MacMini :
|
MacMini :
|
||||||
|
|
|
@ -35,10 +35,12 @@ Supported Features
|
||||||
* suspend/resume support
|
* suspend/resume support
|
||||||
* DPMS support
|
* DPMS support
|
||||||
|
|
||||||
Text mode is supported even in higher resolutions, but there is limitation
|
Text mode is supported even in higher resolutions, but there is limitation to
|
||||||
to lower pixclocks (maximum between 50-60 MHz, depending on specific hardware).
|
lower pixclocks (maximum usually between 50-60 MHz, depending on specific
|
||||||
This limitation is not enforced by driver. Text mode supports 8bit wide fonts
|
hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This
|
||||||
only (hardware limitation) and 16bit tall fonts (driver limitation).
|
limitation is not enforced by driver. Text mode supports 8bit wide fonts only
|
||||||
|
(hardware limitation) and 16bit tall fonts (driver limitation). Text mode
|
||||||
|
support is broken on S3 Trio64 V2/DX.
|
||||||
|
|
||||||
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
|
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
|
||||||
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
|
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
|
||||||
|
@ -73,6 +75,8 @@ Known bugs
|
||||||
==========
|
==========
|
||||||
|
|
||||||
* cursor disable in text mode doesn't work
|
* cursor disable in text mode doesn't work
|
||||||
|
* text mode broken on S3 Trio64 V2/DX
|
||||||
|
|
||||||
|
|
||||||
--
|
--
|
||||||
Ondrej Zajicek <santiago@crfreenet.org>
|
Ondrej Zajicek <santiago@crfreenet.org>
|
||||||
|
|
|
@ -2,9 +2,9 @@
|
||||||
Introduction
|
Introduction
|
||||||
|
|
||||||
This is a frame buffer device driver for 3dfx' Voodoo Graphics
|
This is a frame buffer device driver for 3dfx' Voodoo Graphics
|
||||||
(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
|
(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
|
||||||
video boards. It's highly experimental code, but is guaranteed to work
|
video boards. It's highly experimental code, but is guaranteed to work
|
||||||
on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
|
on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
|
||||||
and with me "between chair and keyboard". Some people tested other
|
and with me "between chair and keyboard". Some people tested other
|
||||||
combinations and it seems that it works.
|
combinations and it seems that it works.
|
||||||
The main page is located at <http://sstfb.sourceforge.net>, and if
|
The main page is located at <http://sstfb.sourceforge.net>, and if
|
||||||
|
|
|
@ -0,0 +1,64 @@
|
||||||
|
|
||||||
|
vt8623fb - fbdev driver for graphics core in VIA VT8623 chipset
|
||||||
|
===============================================================
|
||||||
|
|
||||||
|
|
||||||
|
Supported Hardware
|
||||||
|
==================
|
||||||
|
|
||||||
|
VIA VT8623 [CLE266] chipset and its graphics core
|
||||||
|
(known as CastleRock or Unichrome)
|
||||||
|
|
||||||
|
I tested vt8623fb on VIA EPIA ML-6000
|
||||||
|
|
||||||
|
|
||||||
|
Supported Features
|
||||||
|
==================
|
||||||
|
|
||||||
|
* 4 bpp pseudocolor modes (with 18bit palette, two variants)
|
||||||
|
* 8 bpp pseudocolor mode (with 18bit palette)
|
||||||
|
* 16 bpp truecolor mode (RGB 565)
|
||||||
|
* 32 bpp truecolor mode (RGB 888)
|
||||||
|
* text mode (activated by bpp = 0)
|
||||||
|
* doublescan mode variant (not available in text mode)
|
||||||
|
* panning in both directions
|
||||||
|
* suspend/resume support
|
||||||
|
* DPMS support
|
||||||
|
|
||||||
|
Text mode is supported even in higher resolutions, but there is limitation to
|
||||||
|
lower pixclocks (maximum about 100 MHz). This limitation is not enforced by
|
||||||
|
driver. Text mode supports 8bit wide fonts only (hardware limitation) and
|
||||||
|
16bit tall fonts (driver limitation).
|
||||||
|
|
||||||
|
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
|
||||||
|
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
|
||||||
|
with interleaved planes (1 byte interleave), MSB first. Both modes support
|
||||||
|
8bit wide fonts only (driver limitation).
|
||||||
|
|
||||||
|
Suspend/resume works on systems that initialize video card during resume and
|
||||||
|
if device is active (for example used by fbcon).
|
||||||
|
|
||||||
|
|
||||||
|
Missing Features
|
||||||
|
================
|
||||||
|
(alias TODO list)
|
||||||
|
|
||||||
|
* secondary (not initialized by BIOS) device support
|
||||||
|
* MMIO support
|
||||||
|
* interlaced mode variant
|
||||||
|
* support for fontwidths != 8 in 4 bpp modes
|
||||||
|
* support for fontheight != 16 in text mode
|
||||||
|
* hardware cursor
|
||||||
|
* video overlay support
|
||||||
|
* vsync synchronization
|
||||||
|
* acceleration support (8514-like 2D, busmaster transfers)
|
||||||
|
|
||||||
|
|
||||||
|
Known bugs
|
||||||
|
==========
|
||||||
|
|
||||||
|
* cursor disable in text mode doesn't work
|
||||||
|
|
||||||
|
|
||||||
|
--
|
||||||
|
Ondrej Zajicek <santiago@crfreenet.org>
|
|
@ -6,6 +6,14 @@ be removed from this file.
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: MXSER
|
||||||
|
When: December 2007
|
||||||
|
Why: Old mxser driver is obsoleted by the mxser_new. Give it some time yet
|
||||||
|
and remove it.
|
||||||
|
Who: Jiri Slaby <jirislaby@gmail.com>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
What: V4L2 VIDIOC_G_MPEGCOMP and VIDIOC_S_MPEGCOMP
|
What: V4L2 VIDIOC_G_MPEGCOMP and VIDIOC_S_MPEGCOMP
|
||||||
When: October 2007
|
When: October 2007
|
||||||
Why: Broken attempt to set MPEG compression parameters. These ioctls are
|
Why: Broken attempt to set MPEG compression parameters. These ioctls are
|
||||||
|
@ -51,6 +59,15 @@ Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: old NCR53C9x driver
|
||||||
|
When: October 2007
|
||||||
|
Why: Replaced by the much better esp_scsi driver. Actual low-level
|
||||||
|
driver can ported over almost trivially.
|
||||||
|
Who: David Miller <davem@davemloft.net>
|
||||||
|
Christoph Hellwig <hch@lst.de>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
|
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
|
||||||
When: December 2006
|
When: December 2006
|
||||||
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
|
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
|
||||||
|
@ -117,25 +134,6 @@ Who: Adrian Bunk <bunk@stusta.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: pci_module_init(driver)
|
|
||||||
When: January 2007
|
|
||||||
Why: Is replaced by pci_register_driver(pci_driver).
|
|
||||||
Who: Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@suse.de>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: Usage of invalid timevals in setitimer
|
|
||||||
When: March 2007
|
|
||||||
Why: POSIX requires to validate timevals in the setitimer call. This
|
|
||||||
was never done by Linux. The invalid (e.g. negative timevals) were
|
|
||||||
silently converted to more or less random timeouts and intervals.
|
|
||||||
Until the removal a per boot limited number of warnings is printed
|
|
||||||
and the timevals are sanitized.
|
|
||||||
|
|
||||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
|
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
|
||||||
(temporary transition config option provided until then)
|
(temporary transition config option provided until then)
|
||||||
The transition config option will also be removed at the same time.
|
The transition config option will also be removed at the same time.
|
||||||
|
@ -163,7 +161,7 @@ Who: Greg Kroah-Hartman <gregkh@suse.de>
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: Interrupt only SA_* flags
|
What: Interrupt only SA_* flags
|
||||||
When: Januar 2007
|
When: September 2007
|
||||||
Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
|
Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
|
||||||
out of the signal namespace.
|
out of the signal namespace.
|
||||||
|
|
||||||
|
@ -190,18 +188,10 @@ Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: i2c_adapter.dev
|
What: i2c_adapter.list
|
||||||
i2c_adapter.list
|
|
||||||
When: July 2007
|
When: July 2007
|
||||||
Why: Superfluous, given i2c_adapter.class_dev:
|
Why: Superfluous, this list duplicates the one maintained by the driver
|
||||||
* The "dev" was a stand-in for the physical device node that legacy
|
core.
|
||||||
drivers would not have; but now it's almost always present. Any
|
|
||||||
remaining legacy drivers must upgrade (they now trigger warnings).
|
|
||||||
* The "list" duplicates class device children.
|
|
||||||
The delay in removing this is so upgraded lm_sensors and libsensors
|
|
||||||
can get deployed. (Removal causes minor changes in the sysfs layout,
|
|
||||||
notably the location of the adapter type name and parenting the i2c
|
|
||||||
client hardware directly from their controller.)
|
|
||||||
Who: Jean Delvare <khali@linux-fr.org>,
|
Who: Jean Delvare <khali@linux-fr.org>,
|
||||||
David Brownell <dbrownell@users.sourceforge.net>
|
David Brownell <dbrownell@users.sourceforge.net>
|
||||||
|
|
||||||
|
@ -306,3 +296,35 @@ Why: Code was merged, then submitter immediately disappeared leaving
|
||||||
Who: David S. Miller <davem@davemloft.net>
|
Who: David S. Miller <davem@davemloft.net>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: read_dev_chars(), read_conf_data{,_lpm}() (s390 common I/O layer)
|
||||||
|
When: December 2007
|
||||||
|
Why: These functions are a leftover from 2.4 times. They have several
|
||||||
|
problems:
|
||||||
|
- Duplication of checks that are done in the device driver's
|
||||||
|
interrupt handler
|
||||||
|
- common I/O layer can't do device specific error recovery
|
||||||
|
- device driver can't be notified for conditions happening during
|
||||||
|
execution of the function
|
||||||
|
Device drivers should issue the read device characteristics and read
|
||||||
|
configuration data ccws and do the appropriate error handling
|
||||||
|
themselves.
|
||||||
|
Who: Cornelia Huck <cornelia.huck@de.ibm.com>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers
|
||||||
|
When: September 2007
|
||||||
|
Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific
|
||||||
|
I2C-over-GPIO drivers.
|
||||||
|
Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: drivers depending on OSS_OBSOLETE
|
||||||
|
When: options in 2.6.23, code in 2.6.25
|
||||||
|
Why: obsolete OSS drivers
|
||||||
|
Who: Adrian Bunk <bunk@stusta.de>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
|
|
@ -15,6 +15,7 @@ prototypes:
|
||||||
int (*d_delete)(struct dentry *);
|
int (*d_delete)(struct dentry *);
|
||||||
void (*d_release)(struct dentry *);
|
void (*d_release)(struct dentry *);
|
||||||
void (*d_iput)(struct dentry *, struct inode *);
|
void (*d_iput)(struct dentry *, struct inode *);
|
||||||
|
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
none have BKL
|
none have BKL
|
||||||
|
@ -25,6 +26,7 @@ d_compare: no yes no no
|
||||||
d_delete: yes no yes no
|
d_delete: yes no yes no
|
||||||
d_release: no no no yes
|
d_release: no no no yes
|
||||||
d_iput: no no no yes
|
d_iput: no no no yes
|
||||||
|
d_dname: no no no no
|
||||||
|
|
||||||
--------------------------- inode_operations ---------------------------
|
--------------------------- inode_operations ---------------------------
|
||||||
prototypes:
|
prototypes:
|
||||||
|
@ -52,7 +54,7 @@ ata *);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
all may block, none have BKL
|
all may block, none have BKL
|
||||||
i_sem(inode)
|
i_mutex(inode)
|
||||||
lookup: yes
|
lookup: yes
|
||||||
create: yes
|
create: yes
|
||||||
link: yes (both)
|
link: yes (both)
|
||||||
|
@ -72,7 +74,7 @@ setxattr: yes
|
||||||
getxattr: no
|
getxattr: no
|
||||||
listxattr: no
|
listxattr: no
|
||||||
removexattr: yes
|
removexattr: yes
|
||||||
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_sem on
|
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
|
||||||
victim.
|
victim.
|
||||||
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
|
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
|
||||||
->truncate() is never called directly - it's a callback, not a
|
->truncate() is never called directly - it's a callback, not a
|
||||||
|
@ -459,7 +461,7 @@ doesn't take the BKL.
|
||||||
->read on directories probably must go away - we should just enforce -EISDIR
|
->read on directories probably must go away - we should just enforce -EISDIR
|
||||||
in sys_read() and friends.
|
in sys_read() and friends.
|
||||||
|
|
||||||
->fsync() has i_sem on inode.
|
->fsync() has i_mutex on inode.
|
||||||
|
|
||||||
--------------------------- dquot_operations -------------------------------
|
--------------------------- dquot_operations -------------------------------
|
||||||
prototypes:
|
prototypes:
|
||||||
|
|
|
@ -290,7 +290,7 @@ History
|
||||||
2.07 More fixes for Warp Server. Now it really works
|
2.07 More fixes for Warp Server. Now it really works
|
||||||
2.08 Creating new files is not so slow on large disks
|
2.08 Creating new files is not so slow on large disks
|
||||||
An attempt to sync deleted file does not generate filesystem error
|
An attempt to sync deleted file does not generate filesystem error
|
||||||
2.09 Fixed error on extremly fragmented files
|
2.09 Fixed error on extremely fragmented files
|
||||||
|
|
||||||
|
|
||||||
vim: set textwidth=80:
|
vim: set textwidth=80:
|
||||||
|
|
|
@ -29,7 +29,13 @@ errors=continue Keep going on a filesystem error.
|
||||||
errors=remount-ro Default. Remount the filesystem read-only on an error.
|
errors=remount-ro Default. Remount the filesystem read-only on an error.
|
||||||
errors=panic Panic and halt the machine if an error occurs.
|
errors=panic Panic and halt the machine if an error occurs.
|
||||||
|
|
||||||
Please send bugs, comments, cards and letters to shaggy@austin.ibm.com.
|
uid=value Override on-disk uid with specified value
|
||||||
|
gid=value Override on-disk gid with specified value
|
||||||
|
umask=value Override on-disk umask with specified octal value. For
|
||||||
|
directories, the execute bit will be set if the corresponding
|
||||||
|
read bit is set.
|
||||||
|
|
||||||
|
Please send bugs, comments, cards and letters to shaggy@linux.vnet.ibm.com.
|
||||||
|
|
||||||
The JFS mailing list can be subscribed to by using the link labeled
|
The JFS mailing list can be subscribed to by using the link labeled
|
||||||
"Mail list Subscribe" at our web page http://jfs.sourceforge.net/
|
"Mail list Subscribe" at our web page http://jfs.sourceforge.net/
|
||||||
|
|
|
@ -349,7 +349,7 @@ end of the line.
|
||||||
Note the "Should sync?" parameter "nosync" means that the two mirrors are
|
Note the "Should sync?" parameter "nosync" means that the two mirrors are
|
||||||
already in sync which will be the case on a clean shutdown of Windows. If the
|
already in sync which will be the case on a clean shutdown of Windows. If the
|
||||||
mirrors are not clean, you can specify the "sync" option instead of "nosync"
|
mirrors are not clean, you can specify the "sync" option instead of "nosync"
|
||||||
and the Device-Mapper driver will then copy the entirey of the "Source Device"
|
and the Device-Mapper driver will then copy the entirety of the "Source Device"
|
||||||
to the "Target Device" or if you specified multipled target devices to all of
|
to the "Target Device" or if you specified multipled target devices to all of
|
||||||
them.
|
them.
|
||||||
|
|
||||||
|
|
|
@ -123,6 +123,7 @@ subdirectory has the entries listed in Table 1-1.
|
||||||
Table 1-1: Process specific entries in /proc
|
Table 1-1: Process specific entries in /proc
|
||||||
..............................................................................
|
..............................................................................
|
||||||
File Content
|
File Content
|
||||||
|
clear_refs Clears page referenced bits shown in smaps output
|
||||||
cmdline Command line arguments
|
cmdline Command line arguments
|
||||||
cpu Current and last cpu in which it was executed (2.4)(smp)
|
cpu Current and last cpu in which it was executed (2.4)(smp)
|
||||||
cwd Link to the current working directory
|
cwd Link to the current working directory
|
||||||
|
@ -136,7 +137,7 @@ Table 1-1: Process specific entries in /proc
|
||||||
statm Process memory status information
|
statm Process memory status information
|
||||||
status Process status in human readable form
|
status Process status in human readable form
|
||||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||||
smaps Extension based on maps, presenting the rss size for each mapped file
|
smaps Extension based on maps, the rss size for each mapped file
|
||||||
..............................................................................
|
..............................................................................
|
||||||
|
|
||||||
For example, to get the status information of a process, all you have to do is
|
For example, to get the status information of a process, all you have to do is
|
||||||
|
@ -228,7 +229,7 @@ Table 1-3: Kernel info in /proc
|
||||||
mounts Mounted filesystems
|
mounts Mounted filesystems
|
||||||
net Networking info (see text)
|
net Networking info (see text)
|
||||||
partitions Table of partitions known to the system
|
partitions Table of partitions known to the system
|
||||||
pci Depreciated info of PCI bus (new way -> /proc/bus/pci/,
|
pci Deprecated info of PCI bus (new way -> /proc/bus/pci/,
|
||||||
decoupled by lspci (2.4)
|
decoupled by lspci (2.4)
|
||||||
rtc Real time clock
|
rtc Real time clock
|
||||||
scsi SCSI info (see text)
|
scsi SCSI info (see text)
|
||||||
|
@ -1137,6 +1138,13 @@ determine whether or not they are still functioning properly.
|
||||||
Because the NMI watchdog shares registers with oprofile, by disabling the NMI
|
Because the NMI watchdog shares registers with oprofile, by disabling the NMI
|
||||||
watchdog, oprofile may have more registers to utilize.
|
watchdog, oprofile may have more registers to utilize.
|
||||||
|
|
||||||
|
maps_protect
|
||||||
|
------------
|
||||||
|
|
||||||
|
Enables/Disables the protection of the per-process proc entries "maps" and
|
||||||
|
"smaps". When enabled, the contents of these files are visible only to
|
||||||
|
readers that are allowed to ptrace() the given process.
|
||||||
|
|
||||||
|
|
||||||
2.4 /proc/sys/vm - The virtual memory subsystem
|
2.4 /proc/sys/vm - The virtual memory subsystem
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
|
|
|
@ -351,7 +351,7 @@ If the current buffer is full, i.e. all sub-buffers remain unconsumed,
|
||||||
the callback returns 0 to indicate that the buffer switch should not
|
the callback returns 0 to indicate that the buffer switch should not
|
||||||
occur yet, i.e. until the consumer has had a chance to read the
|
occur yet, i.e. until the consumer has had a chance to read the
|
||||||
current set of ready sub-buffers. For the relay_buf_full() function
|
current set of ready sub-buffers. For the relay_buf_full() function
|
||||||
to make sense, the consumer is reponsible for notifying the relay
|
to make sense, the consumer is responsible for notifying the relay
|
||||||
interface when sub-buffers have been consumed via
|
interface when sub-buffers have been consumed via
|
||||||
relay_subbufs_consumed(). Any subsequent attempts to write into the
|
relay_subbufs_consumed(). Any subsequent attempts to write into the
|
||||||
buffer will again invoke the subbuf_start() callback with the same
|
buffer will again invoke the subbuf_start() callback with the same
|
||||||
|
|
|
@ -57,6 +57,13 @@ nonumtail=<bool> -- When creating 8.3 aliases, normally the alias will
|
||||||
currently exist in the directory, 'longfile.txt' will
|
currently exist in the directory, 'longfile.txt' will
|
||||||
be the short alias instead of 'longfi~1.txt'.
|
be the short alias instead of 'longfi~1.txt'.
|
||||||
|
|
||||||
|
usefree -- Use the "free clusters" value stored on FSINFO. It'll
|
||||||
|
be used to determine number of free clusters without
|
||||||
|
scanning disk. But it's not used by default, because
|
||||||
|
recent Windows don't update it correctly in some
|
||||||
|
case. If you are sure the "free clusters" on FSINFO is
|
||||||
|
correct, by this option you can avoid scanning disk.
|
||||||
|
|
||||||
quiet -- Stops printing certain warning messages.
|
quiet -- Stops printing certain warning messages.
|
||||||
|
|
||||||
check=s|r|n -- Case sensitivity checking setting.
|
check=s|r|n -- Case sensitivity checking setting.
|
||||||
|
|
|
@ -827,7 +827,7 @@ This describes how a filesystem can overload the standard dentry
|
||||||
operations. Dentries and the dcache are the domain of the VFS and the
|
operations. Dentries and the dcache are the domain of the VFS and the
|
||||||
individual filesystem implementations. Device drivers have no business
|
individual filesystem implementations. Device drivers have no business
|
||||||
here. These methods may be set to NULL, as they are either optional or
|
here. These methods may be set to NULL, as they are either optional or
|
||||||
the VFS uses a default. As of kernel 2.6.13, the following members are
|
the VFS uses a default. As of kernel 2.6.22, the following members are
|
||||||
defined:
|
defined:
|
||||||
|
|
||||||
struct dentry_operations {
|
struct dentry_operations {
|
||||||
|
@ -837,6 +837,7 @@ struct dentry_operations {
|
||||||
int (*d_delete)(struct dentry *);
|
int (*d_delete)(struct dentry *);
|
||||||
void (*d_release)(struct dentry *);
|
void (*d_release)(struct dentry *);
|
||||||
void (*d_iput)(struct dentry *, struct inode *);
|
void (*d_iput)(struct dentry *, struct inode *);
|
||||||
|
char *(*d_dname)(struct dentry *, char *, int);
|
||||||
};
|
};
|
||||||
|
|
||||||
d_revalidate: called when the VFS needs to revalidate a dentry. This
|
d_revalidate: called when the VFS needs to revalidate a dentry. This
|
||||||
|
@ -859,6 +860,26 @@ struct dentry_operations {
|
||||||
VFS calls iput(). If you define this method, you must call
|
VFS calls iput(). If you define this method, you must call
|
||||||
iput() yourself
|
iput() yourself
|
||||||
|
|
||||||
|
d_dname: called when the pathname of a dentry should be generated.
|
||||||
|
Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
|
||||||
|
pathname generation. (Instead of doing it when dentry is created,
|
||||||
|
its done only when the path is needed.). Real filesystems probably
|
||||||
|
dont want to use it, because their dentries are present in global
|
||||||
|
dcache hash, so their hash should be an invariant. As no lock is
|
||||||
|
held, d_dname() should not try to modify the dentry itself, unless
|
||||||
|
appropriate SMP safety is used. CAUTION : d_path() logic is quite
|
||||||
|
tricky. The correct way to return for example "Hello" is to put it
|
||||||
|
at the end of the buffer, and returns a pointer to the first char.
|
||||||
|
dynamic_dname() helper function is provided to take care of this.
|
||||||
|
|
||||||
|
Example :
|
||||||
|
|
||||||
|
static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
|
||||||
|
{
|
||||||
|
return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
|
||||||
|
dentry->d_inode->i_ino);
|
||||||
|
}
|
||||||
|
|
||||||
Each dentry has a pointer to its parent dentry, as well as a hash list
|
Each dentry has a pointer to its parent dentry, as well as a hash list
|
||||||
of child dentries. Child dentries are basically like files in a
|
of child dentries. Child dentries are basically like files in a
|
||||||
directory.
|
directory.
|
||||||
|
|
|
@ -19,7 +19,7 @@ completely. With execute-in-place, read&write type operations are performed
|
||||||
directly from/to the memory backed storage device. For file mappings, the
|
directly from/to the memory backed storage device. For file mappings, the
|
||||||
storage device itself is mapped directly into userspace.
|
storage device itself is mapped directly into userspace.
|
||||||
|
|
||||||
This implementation was initialy written for shared memory segments between
|
This implementation was initially written for shared memory segments between
|
||||||
different virtual machines on s390 hardware to allow multiple machines to
|
different virtual machines on s390 hardware to allow multiple machines to
|
||||||
share the same binaries and libraries.
|
share the same binaries and libraries.
|
||||||
|
|
||||||
|
|
|
@ -126,5 +126,5 @@ GDB stub and the debugger:
|
||||||
|
|
||||||
Furthermore, the GDB stub will intercept a number of exceptions automatically
|
Furthermore, the GDB stub will intercept a number of exceptions automatically
|
||||||
if they are caused by kernel execution. It will also intercept BUG() macro
|
if they are caused by kernel execution. It will also intercept BUG() macro
|
||||||
invokation.
|
invocation.
|
||||||
|
|
||||||
|
|
|
@ -66,7 +66,9 @@ registers; another might implement it by delegating through abstractions
|
||||||
used for several very different kinds of GPIO controller.
|
used for several very different kinds of GPIO controller.
|
||||||
|
|
||||||
That said, if the convention is supported on their platform, drivers should
|
That said, if the convention is supported on their platform, drivers should
|
||||||
use it when possible:
|
use it when possible. Platforms should declare GENERIC_GPIO support in
|
||||||
|
Kconfig (boolean true), which multi-platform drivers can depend on when
|
||||||
|
using the include file:
|
||||||
|
|
||||||
#include <asm/gpio.h>
|
#include <asm/gpio.h>
|
||||||
|
|
||||||
|
|
|
@ -80,7 +80,7 @@ temperature sensor inputs. Both the PWM output and the DAC output can be
|
||||||
used to control fan speed. Usually only one of these two outputs will be
|
used to control fan speed. Usually only one of these two outputs will be
|
||||||
used. Write the minimum PWM or DAC value to the appropriate control
|
used. Write the minimum PWM or DAC value to the appropriate control
|
||||||
register. Then set the low temperature limit in the tmin values for each
|
register. Then set the low temperature limit in the tmin values for each
|
||||||
temperature sensor. The range of control is fixed at 20 °C, and the
|
temperature sensor. The range of control is fixed at 20 °C, and the
|
||||||
largest difference between current and tmin of the temperature sensors sets
|
largest difference between current and tmin of the temperature sensors sets
|
||||||
the control output. See the datasheet for several example circuits for
|
the control output. See the datasheet for several example circuits for
|
||||||
controlling fan speed with the PWM and DAC outputs. The fan speed sensors
|
controlling fan speed with the PWM and DAC outputs. The fan speed sensors
|
||||||
|
|
|
@ -0,0 +1,36 @@
|
||||||
|
Kernel driver coretemp
|
||||||
|
======================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* All Intel Core family
|
||||||
|
Prefix: 'coretemp'
|
||||||
|
CPUID: family 0x6, models 0xe, 0xf
|
||||||
|
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
|
||||||
|
Volume 3A: System Programming Guide
|
||||||
|
|
||||||
|
Author: Rudolf Marek
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver permits reading temperature sensor embedded inside Intel Core CPU.
|
||||||
|
Temperature is measured in degrees Celsius and measurement resolution is
|
||||||
|
1 degree C. Valid temperatures are from 0 to TjMax degrees C, because
|
||||||
|
the actual value of temperature register is in fact a delta from TjMax.
|
||||||
|
|
||||||
|
Temperature known as TjMax is the maximum junction temperature of processor.
|
||||||
|
Intel defines this temperature as 85C or 100C. At this temperature, protection
|
||||||
|
mechanism will perform actions to forcibly cool down the processor. Alarm
|
||||||
|
may be raised, if the temperature grows enough (more than TjMax) to trigger
|
||||||
|
the Out-Of-Spec bit. Following table summarizes the exported sysfs files:
|
||||||
|
|
||||||
|
temp1_input - Core temperature (in millidegrees Celsius).
|
||||||
|
temp1_crit - Maximum junction temperature (in millidegrees Celsius).
|
||||||
|
temp1_crit_alarm - Set when Out-of-spec bit is set, never clears.
|
||||||
|
Correct CPU operation is no longer guaranteed.
|
||||||
|
temp1_label - Contains string "Core X", where X is processor
|
||||||
|
number.
|
||||||
|
|
||||||
|
The TjMax temperature is set to 85 degrees C if undocumented model specific
|
||||||
|
register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as
|
||||||
|
(sometimes) documented in processor datasheet.
|
|
@ -13,7 +13,7 @@ Supported chips:
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Frodo Looijaard <frodol@dds.nl>,
|
Frodo Looijaard <frodol@dds.nl>,
|
||||||
Kyösti Mälkki <kmalkki@cc.hut.fi>
|
Kyösti Mälkki <kmalkki@cc.hut.fi>
|
||||||
Hong-Gunn Chew <hglinux@gunnet.org>
|
Hong-Gunn Chew <hglinux@gunnet.org>
|
||||||
Jean Delvare <khali@linux-fr.org>
|
Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
|
|
@ -45,7 +45,7 @@ Unconfirmed motherboards:
|
||||||
The LM82 is confirmed to have been found on most AMD Geode reference
|
The LM82 is confirmed to have been found on most AMD Geode reference
|
||||||
designs and test platforms.
|
designs and test platforms.
|
||||||
|
|
||||||
The driver has been successfully tested by Magnus Forsström, who I'd
|
The driver has been successfully tested by Magnus Forsström, who I'd
|
||||||
like to thank here. More testers will be of course welcome.
|
like to thank here. More testers will be of course welcome.
|
||||||
|
|
||||||
The fact that the LM83 is only scarcely used can be easily explained.
|
The fact that the LM83 is only scarcely used can be easily explained.
|
||||||
|
|
|
@ -0,0 +1,53 @@
|
||||||
|
Kernel driver max6650
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Maxim 6650 / 6651
|
||||||
|
Prefix: 'max6650'
|
||||||
|
Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b
|
||||||
|
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
||||||
|
|
||||||
|
Authors:
|
||||||
|
Hans J. Koch <hjk@linutronix.de>
|
||||||
|
John Morris <john.morris@spirentcom.com>
|
||||||
|
Claus Gindhart <claus.gindhart@kontron.com>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver implements support for the Maxim 6650/6651
|
||||||
|
|
||||||
|
The 2 devices are very similar, but the Maxim 6550 has a reduced feature
|
||||||
|
set, e.g. only one fan-input, instead of 4 for the 6651.
|
||||||
|
|
||||||
|
The driver is not able to distinguish between the 2 devices.
|
||||||
|
|
||||||
|
The driver provides the following sensor accesses in sysfs:
|
||||||
|
|
||||||
|
fan1_input ro fan tachometer speed in RPM
|
||||||
|
fan2_input ro "
|
||||||
|
fan3_input ro "
|
||||||
|
fan4_input ro "
|
||||||
|
fan1_target rw desired fan speed in RPM (closed loop mode only)
|
||||||
|
pwm1_enable rw regulator mode, 0=full on, 1=open loop, 2=closed loop
|
||||||
|
pwm1 rw relative speed (0-255), 255=max. speed.
|
||||||
|
Used in open loop mode only.
|
||||||
|
fan1_div rw sets the speed range the inputs can handle. Legal
|
||||||
|
values are 1, 2, 4, and 8. Use lower values for
|
||||||
|
faster fans.
|
||||||
|
|
||||||
|
Module parameters
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
If your board has a BIOS that initializes the MAX6650/6651 correctly, you can
|
||||||
|
simply load your module without parameters. It won't touch the configuration
|
||||||
|
registers then. If your board BIOS doesn't initialize the chip, or you want
|
||||||
|
different settings, you can set the following parameters:
|
||||||
|
|
||||||
|
voltage_12V: 5=5V fan, 12=12V fan, 0=don't change
|
||||||
|
prescaler: Possible values are 1,2,4,8,16, or 0 for don't change
|
||||||
|
clock: The clock frequency in Hz of the chip the driver should assume [254000]
|
||||||
|
|
||||||
|
Please have a look at the MAX6650/6651 data sheet and make sure that you fully
|
||||||
|
understand the meaning of these parameters before you attempt to change them.
|
||||||
|
|
|
@ -8,7 +8,7 @@ Supported chips:
|
||||||
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
|
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||||
Aurelien Jarno <aurelien@aurel32.net> 2.6 port
|
Aurelien Jarno <aurelien@aurel32.net> 2.6 port
|
||||||
|
|
||||||
|
|
|
@ -14,6 +14,10 @@ Supported chips:
|
||||||
http://www.smsc.com/main/datasheets/47m14x.pdf
|
http://www.smsc.com/main/datasheets/47m14x.pdf
|
||||||
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
|
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
|
||||||
http://www.smsc.com/main/datasheets/47m192.pdf
|
http://www.smsc.com/main/datasheets/47m192.pdf
|
||||||
|
* SMSC LPC47M292
|
||||||
|
Addresses scanned: none, address read from Super I/O config space
|
||||||
|
Prefix: 'smsc47m2'
|
||||||
|
Datasheet: Not public
|
||||||
* SMSC LPC47M997
|
* SMSC LPC47M997
|
||||||
Addresses scanned: none, address read from Super I/O config space
|
Addresses scanned: none, address read from Super I/O config space
|
||||||
Prefix: 'smsc47m1'
|
Prefix: 'smsc47m1'
|
||||||
|
@ -32,9 +36,10 @@ Description
|
||||||
The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
|
The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
|
||||||
contain monitoring and PWM control circuitry for two fans.
|
contain monitoring and PWM control circuitry for two fans.
|
||||||
|
|
||||||
The 47M15x and 47M192 chips contain a full 'hardware monitoring block'
|
The LPC47M15x, LPC47M192 and LPC47M292 chips contain a full 'hardware
|
||||||
in addition to the fan monitoring and control. The hardware monitoring
|
monitoring block' in addition to the fan monitoring and control. The
|
||||||
block is not supported by the driver.
|
hardware monitoring block is not supported by this driver, use the
|
||||||
|
smsc47m192 driver for that.
|
||||||
|
|
||||||
No documentation is available for the 47M997, but it has the same device
|
No documentation is available for the 47M997, but it has the same device
|
||||||
ID as the 47M15x and 47M192 chips and seems to be compatible.
|
ID as the 47M15x and 47M192 chips and seems to be compatible.
|
||||||
|
|
|
@ -2,12 +2,13 @@ Kernel driver smsc47m192
|
||||||
========================
|
========================
|
||||||
|
|
||||||
Supported chips:
|
Supported chips:
|
||||||
* SMSC LPC47M192 and LPC47M997
|
* SMSC LPC47M192, LPC47M15x, LPC47M292 and LPC47M997
|
||||||
Prefix: 'smsc47m192'
|
Prefix: 'smsc47m192'
|
||||||
Addresses scanned: I2C 0x2c - 0x2d
|
Addresses scanned: I2C 0x2c - 0x2d
|
||||||
Datasheet: The datasheet for LPC47M192 is publicly available from
|
Datasheet: The datasheet for LPC47M192 is publicly available from
|
||||||
http://www.smsc.com/
|
http://www.smsc.com/
|
||||||
The LPC47M997 is compatible for hardware monitoring.
|
The LPC47M15x, LPC47M292 and LPC47M997 are compatible for
|
||||||
|
hardware monitoring.
|
||||||
|
|
||||||
Author: Hartmut Rick <linux@rick.claranet.de>
|
Author: Hartmut Rick <linux@rick.claranet.de>
|
||||||
Special thanks to Jean Delvare for careful checking
|
Special thanks to Jean Delvare for careful checking
|
||||||
|
@ -18,7 +19,7 @@ Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver implements support for the hardware sensor capabilities
|
This driver implements support for the hardware sensor capabilities
|
||||||
of the SMSC LPC47M192 and LPC47M997 Super-I/O chips.
|
of the SMSC LPC47M192 and compatible Super-I/O chips.
|
||||||
|
|
||||||
These chips support 3 temperature channels and 8 voltage inputs
|
These chips support 3 temperature channels and 8 voltage inputs
|
||||||
as well as CPU voltage VID input.
|
as well as CPU voltage VID input.
|
||||||
|
|
|
@ -152,6 +152,13 @@ fan[1-*]_div Fan divisor.
|
||||||
Note that this is actually an internal clock divisor, which
|
Note that this is actually an internal clock divisor, which
|
||||||
affects the measurable speed range, not the read value.
|
affects the measurable speed range, not the read value.
|
||||||
|
|
||||||
|
fan[1-*]_target
|
||||||
|
Desired fan speed
|
||||||
|
Unit: revolution/min (RPM)
|
||||||
|
RW
|
||||||
|
Only makes sense if the chip supports closed-loop fan speed
|
||||||
|
control based on the measured fan speed.
|
||||||
|
|
||||||
Also see the Alarms section for status flags associated with fans.
|
Also see the Alarms section for status flags associated with fans.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -8,7 +8,7 @@ Supported chips:
|
||||||
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
|
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||||
Bob Dougherty <bobd@stanford.edu>
|
Bob Dougherty <bobd@stanford.edu>
|
||||||
(Some conversion-factor data were contributed by
|
(Some conversion-factor data were contributed by
|
||||||
|
|
|
@ -107,7 +107,7 @@ Known problems:
|
||||||
by CR[0x49h].
|
by CR[0x49h].
|
||||||
- The function of vid and vrm has not been finished, because I'm NOT
|
- The function of vid and vrm has not been finished, because I'm NOT
|
||||||
very familiar with them. Adding support is welcome.
|
very familiar with them. Adding support is welcome.
|
||||||
- The function of chassis open detection needs more tests.
|
- The function of chassis open detection needs more tests.
|
||||||
- If you have ASUS server board and chip was not found: Then you will
|
- If you have ASUS server board and chip was not found: Then you will
|
||||||
need to upgrade to latest (or beta) BIOS. If it does not help please
|
need to upgrade to latest (or beta) BIOS. If it does not help please
|
||||||
contact us.
|
contact us.
|
||||||
|
|
|
@ -7,7 +7,7 @@ Supported adapters:
|
||||||
Authors:
|
Authors:
|
||||||
Frodo Looijaard <frodol@dds.nl>,
|
Frodo Looijaard <frodol@dds.nl>,
|
||||||
Philip Edelbrock <phil@netroedge.com>,
|
Philip Edelbrock <phil@netroedge.com>,
|
||||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||||
Ralph Metzler <rjkm@thp.uni-koeln.de>,
|
Ralph Metzler <rjkm@thp.uni-koeln.de>,
|
||||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||||
|
|
||||||
|
|
|
@ -9,6 +9,8 @@ Supported adapters:
|
||||||
* nForce4 MCP-04 10de:0034
|
* nForce4 MCP-04 10de:0034
|
||||||
* nForce4 MCP51 10de:0264
|
* nForce4 MCP51 10de:0264
|
||||||
* nForce4 MCP55 10de:0368
|
* nForce4 MCP55 10de:0368
|
||||||
|
* nForce4 MCP61 10de:03EB
|
||||||
|
* nForce4 MCP65 10de:0446
|
||||||
|
|
||||||
Datasheet: not publicly available, but seems to be similar to the
|
Datasheet: not publicly available, but seems to be similar to the
|
||||||
AMD-8111 SMBus 2.0 adapter.
|
AMD-8111 SMBus 2.0 adapter.
|
||||||
|
|
|
@ -60,7 +60,7 @@ Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||||
- design hints and bug fixes
|
- design hints and bug fixes
|
||||||
Alexander Maylsh <amalysh@web.de>
|
Alexander Maylsh <amalysh@web.de>
|
||||||
- ditto, plus an important datasheet... almost the one I really wanted
|
- ditto, plus an important datasheet... almost the one I really wanted
|
||||||
Hans-Günter Lütke Uphues <hg_lu@t-online.de>
|
Hans-Günter Lütke Uphues <hg_lu@t-online.de>
|
||||||
- patch for SiS735
|
- patch for SiS735
|
||||||
Robert Zwerus <arzie@dds.nl>
|
Robert Zwerus <arzie@dds.nl>
|
||||||
- testing for SiS645DX
|
- testing for SiS645DX
|
||||||
|
|
|
@ -4,7 +4,7 @@ Supported adapters:
|
||||||
* VIA Technologies, InC. VT82C586B
|
* VIA Technologies, InC. VT82C586B
|
||||||
Datasheet: Publicly available at the VIA website
|
Datasheet: Publicly available at the VIA website
|
||||||
|
|
||||||
Author: Kyösti Mälkki <kmalkki@cc.hut.fi>
|
Author: Kyösti Mälkki <kmalkki@cc.hut.fi>
|
||||||
|
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
|
@ -17,7 +17,7 @@ Supported adapters:
|
||||||
Datasheet: available on request and under NDA from VIA
|
Datasheet: available on request and under NDA from VIA
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||||
Jean Delvare <khali@linux-fr.org>
|
Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
|
|
@ -68,7 +68,7 @@ We have found some I2C devices that needs the following modifications:
|
||||||
|
|
||||||
Flags I2C_M_IGNORE_NAK
|
Flags I2C_M_IGNORE_NAK
|
||||||
Normally message is interrupted immediately if there is [NA] from the
|
Normally message is interrupted immediately if there is [NA] from the
|
||||||
client. Setting this flag treats any [NA] as [A], and all of
|
client. Setting this flag treats any [NA] as [A], and all of
|
||||||
message is sent.
|
message is sent.
|
||||||
These messages may still fail to SCL lo->hi timeout.
|
These messages may still fail to SCL lo->hi timeout.
|
||||||
|
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
Revision 6, 2005-11-20
|
Revision 7, 2007-04-19
|
||||||
Jean Delvare <khali@linux-fr.org>
|
Jean Delvare <khali@linux-fr.org>
|
||||||
Greg KH <greg@kroah.com>
|
Greg KH <greg@kroah.com>
|
||||||
|
|
||||||
|
@ -20,6 +20,10 @@ yours for best results.
|
||||||
|
|
||||||
Technical changes:
|
Technical changes:
|
||||||
|
|
||||||
|
* [Driver type] Any driver that was relying on i2c-isa has to be
|
||||||
|
converted to a proper isa, platform or pci driver. This is not
|
||||||
|
covered by this guide.
|
||||||
|
|
||||||
* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
|
* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
|
||||||
Includes typically look like that:
|
Includes typically look like that:
|
||||||
#include <linux/module.h>
|
#include <linux/module.h>
|
||||||
|
@ -27,12 +31,10 @@ Technical changes:
|
||||||
#include <linux/slab.h>
|
#include <linux/slab.h>
|
||||||
#include <linux/jiffies.h>
|
#include <linux/jiffies.h>
|
||||||
#include <linux/i2c.h>
|
#include <linux/i2c.h>
|
||||||
#include <linux/i2c-isa.h> /* for ISA drivers */
|
|
||||||
#include <linux/hwmon.h> /* for hardware monitoring drivers */
|
#include <linux/hwmon.h> /* for hardware monitoring drivers */
|
||||||
#include <linux/hwmon-sysfs.h>
|
#include <linux/hwmon-sysfs.h>
|
||||||
#include <linux/hwmon-vid.h> /* if you need VRM support */
|
#include <linux/hwmon-vid.h> /* if you need VRM support */
|
||||||
#include <linux/err.h> /* for class registration */
|
#include <linux/err.h> /* for class registration */
|
||||||
#include <asm/io.h> /* if you have I/O operations */
|
|
||||||
Please respect this inclusion order. Some extra headers may be
|
Please respect this inclusion order. Some extra headers may be
|
||||||
required for a given driver (e.g. "lm75.h").
|
required for a given driver (e.g. "lm75.h").
|
||||||
|
|
||||||
|
@ -69,20 +71,16 @@ Technical changes:
|
||||||
sensors mailing list <lm-sensors@lm-sensors.org> by providing a
|
sensors mailing list <lm-sensors@lm-sensors.org> by providing a
|
||||||
patch to the Documentation/hwmon/sysfs-interface file.
|
patch to the Documentation/hwmon/sysfs-interface file.
|
||||||
|
|
||||||
* [Attach] For I2C drivers, the attach function should make sure
|
* [Attach] The attach function should make sure that the adapter's
|
||||||
that the adapter's class has I2C_CLASS_HWMON (or whatever class is
|
class has I2C_CLASS_HWMON (or whatever class is suitable for your
|
||||||
suitable for your driver), using the following construct:
|
driver), using the following construct:
|
||||||
if (!(adapter->class & I2C_CLASS_HWMON))
|
if (!(adapter->class & I2C_CLASS_HWMON))
|
||||||
return 0;
|
return 0;
|
||||||
ISA-only drivers of course don't need this.
|
|
||||||
Call i2c_probe() instead of i2c_detect().
|
Call i2c_probe() instead of i2c_detect().
|
||||||
|
|
||||||
* [Detect] As mentioned earlier, the flags parameter is gone.
|
* [Detect] As mentioned earlier, the flags parameter is gone.
|
||||||
The type_name and client_name strings are replaced by a single
|
The type_name and client_name strings are replaced by a single
|
||||||
name string, which will be filled with a lowercase, short string.
|
name string, which will be filled with a lowercase, short string.
|
||||||
In i2c-only drivers, drop the i2c_is_isa_adapter check, it's
|
|
||||||
useless. Same for isa-only drivers, as the test would always be
|
|
||||||
true. Only hybrid drivers (which are quite rare) still need it.
|
|
||||||
The labels used for error paths are reduced to the number needed.
|
The labels used for error paths are reduced to the number needed.
|
||||||
It is advised that the labels are given descriptive names such as
|
It is advised that the labels are given descriptive names such as
|
||||||
exit and exit_free. Don't forget to properly set err before
|
exit and exit_free. Don't forget to properly set err before
|
||||||
|
|
|
@ -4,17 +4,23 @@ I2C and SMBus
|
||||||
=============
|
=============
|
||||||
|
|
||||||
I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
|
I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
|
||||||
slow two-wire protocol (10-400 kHz), but it suffices for many types of
|
slow two-wire protocol (variable speed, up to 400 kHz), with a high speed
|
||||||
devices.
|
extension (3.4 MHz). It provides an inexpensive bus for connecting many
|
||||||
|
types of devices with infrequent or low bandwidth communications needs.
|
||||||
|
I2C is widely used with embedded systems. Some systems use variants that
|
||||||
|
don't meet branding requirements, and so are not advertised as being I2C.
|
||||||
|
|
||||||
SMBus (System Management Bus) is a subset of the I2C protocol. Many
|
SMBus (System Management Bus) is based on the I2C protocol, and is mostly
|
||||||
modern mainboards have a System Management Bus. There are a lot of
|
a subset of I2C protocols and signaling. Many I2C devices will work on an
|
||||||
devices which can be connected to a SMBus; the most notable are modern
|
SMBus, but some SMBus protocols add semantics beyond what is required to
|
||||||
memory chips with EEPROM memories and chips for hardware monitoring.
|
achieve I2C branding. Modern PC mainboards rely on SMBus. The most common
|
||||||
|
devices connected through SMBus are RAM modules configured using I2C EEPROMs,
|
||||||
|
and hardware monitoring chips.
|
||||||
|
|
||||||
Because the SMBus is just a special case of the generalized I2C bus, we
|
Because the SMBus is mostly a subset of the generalized I2C bus, we can
|
||||||
can simulate the SMBus protocol on plain I2C busses. The reverse is
|
use its protocols on many I2C systems. However, there are systems that don't
|
||||||
regretfully impossible.
|
meet both SMBus and I2C electrical constraints; and others which can't
|
||||||
|
implement all the common SMBus protocol semantics or messages.
|
||||||
|
|
||||||
|
|
||||||
Terminology
|
Terminology
|
||||||
|
@ -29,6 +35,7 @@ When we talk about I2C, we use the following terms:
|
||||||
An Algorithm driver contains general code that can be used for a whole class
|
An Algorithm driver contains general code that can be used for a whole class
|
||||||
of I2C adapters. Each specific adapter driver depends on one algorithm
|
of I2C adapters. Each specific adapter driver depends on one algorithm
|
||||||
driver.
|
driver.
|
||||||
|
|
||||||
A Driver driver (yes, this sounds ridiculous, sorry) contains the general
|
A Driver driver (yes, this sounds ridiculous, sorry) contains the general
|
||||||
code to access some type of device. Each detected device gets its own
|
code to access some type of device. Each detected device gets its own
|
||||||
data in the Client structure. Usually, Driver and Client are more closely
|
data in the Client structure. Usually, Driver and Client are more closely
|
||||||
|
@ -40,6 +47,10 @@ a separate Adapter and Algorithm driver), and drivers for your I2C devices
|
||||||
in this package. See the lm_sensors project http://www.lm-sensors.nu
|
in this package. See the lm_sensors project http://www.lm-sensors.nu
|
||||||
for device drivers.
|
for device drivers.
|
||||||
|
|
||||||
|
At this time, Linux only operates I2C (or SMBus) in master mode; you can't
|
||||||
|
use these APIs to make a Linux system behave as a slave/device, either to
|
||||||
|
speak a custom protocol or to emulate some other device.
|
||||||
|
|
||||||
|
|
||||||
Included Bus Drivers
|
Included Bus Drivers
|
||||||
====================
|
====================
|
||||||
|
|
|
@ -1,5 +1,5 @@
|
||||||
This is a small guide for those who want to write kernel drivers for I2C
|
This is a small guide for those who want to write kernel drivers for I2C
|
||||||
or SMBus devices.
|
or SMBus devices, using Linux as the protocol host/master (not slave).
|
||||||
|
|
||||||
To set up a driver, you need to do several things. Some are optional, and
|
To set up a driver, you need to do several things. Some are optional, and
|
||||||
some things can be done slightly or completely different. Use this as a
|
some things can be done slightly or completely different. Use this as a
|
||||||
|
@ -29,8 +29,16 @@ static struct i2c_driver foo_driver = {
|
||||||
.driver = {
|
.driver = {
|
||||||
.name = "foo",
|
.name = "foo",
|
||||||
},
|
},
|
||||||
|
|
||||||
|
/* iff driver uses driver model ("new style") binding model: */
|
||||||
|
.probe = foo_probe,
|
||||||
|
.remove = foo_remove,
|
||||||
|
|
||||||
|
/* else, driver uses "legacy" binding model: */
|
||||||
.attach_adapter = foo_attach_adapter,
|
.attach_adapter = foo_attach_adapter,
|
||||||
.detach_client = foo_detach_client,
|
.detach_client = foo_detach_client,
|
||||||
|
|
||||||
|
/* these may be used regardless of the driver binding model */
|
||||||
.shutdown = foo_shutdown, /* optional */
|
.shutdown = foo_shutdown, /* optional */
|
||||||
.suspend = foo_suspend, /* optional */
|
.suspend = foo_suspend, /* optional */
|
||||||
.resume = foo_resume, /* optional */
|
.resume = foo_resume, /* optional */
|
||||||
|
@ -40,7 +48,8 @@ static struct i2c_driver foo_driver = {
|
||||||
The name field is the driver name, and must not contain spaces. It
|
The name field is the driver name, and must not contain spaces. It
|
||||||
should match the module name (if the driver can be compiled as a module),
|
should match the module name (if the driver can be compiled as a module),
|
||||||
although you can use MODULE_ALIAS (passing "foo" in this example) to add
|
although you can use MODULE_ALIAS (passing "foo" in this example) to add
|
||||||
another name for the module.
|
another name for the module. If the driver name doesn't match the module
|
||||||
|
name, the module won't be automatically loaded (hotplug/coldplug).
|
||||||
|
|
||||||
All other fields are for call-back functions which will be explained
|
All other fields are for call-back functions which will be explained
|
||||||
below.
|
below.
|
||||||
|
@ -65,16 +74,13 @@ An example structure is below.
|
||||||
|
|
||||||
struct foo_data {
|
struct foo_data {
|
||||||
struct i2c_client client;
|
struct i2c_client client;
|
||||||
struct semaphore lock; /* For ISA access in `sensors' drivers. */
|
|
||||||
int sysctl_id; /* To keep the /proc directory entry for
|
|
||||||
`sensors' drivers. */
|
|
||||||
enum chips type; /* To keep the chips type for `sensors' drivers. */
|
enum chips type; /* To keep the chips type for `sensors' drivers. */
|
||||||
|
|
||||||
/* Because the i2c bus is slow, it is often useful to cache the read
|
/* Because the i2c bus is slow, it is often useful to cache the read
|
||||||
information of a chip for some time (for example, 1 or 2 seconds).
|
information of a chip for some time (for example, 1 or 2 seconds).
|
||||||
It depends of course on the device whether this is really worthwhile
|
It depends of course on the device whether this is really worthwhile
|
||||||
or even sensible. */
|
or even sensible. */
|
||||||
struct semaphore update_lock; /* When we are reading lots of information,
|
struct mutex update_lock; /* When we are reading lots of information,
|
||||||
another process should not update the
|
another process should not update the
|
||||||
below information */
|
below information */
|
||||||
char valid; /* != 0 if the following fields are valid. */
|
char valid; /* != 0 if the following fields are valid. */
|
||||||
|
@ -95,8 +101,7 @@ some obscure clients). But we need generic reading and writing routines.
|
||||||
I have found it useful to define foo_read and foo_write function for this.
|
I have found it useful to define foo_read and foo_write function for this.
|
||||||
For some cases, it will be easier to call the i2c functions directly,
|
For some cases, it will be easier to call the i2c functions directly,
|
||||||
but many chips have some kind of register-value idea that can easily
|
but many chips have some kind of register-value idea that can easily
|
||||||
be encapsulated. Also, some chips have both ISA and I2C interfaces, and
|
be encapsulated.
|
||||||
it useful to abstract from this (only for `sensors' drivers).
|
|
||||||
|
|
||||||
The below functions are simple examples, and should not be copied
|
The below functions are simple examples, and should not be copied
|
||||||
literally.
|
literally.
|
||||||
|
@ -119,28 +124,101 @@ literally.
|
||||||
return i2c_smbus_write_word_data(client,reg,value);
|
return i2c_smbus_write_word_data(client,reg,value);
|
||||||
}
|
}
|
||||||
|
|
||||||
For sensors code, you may have to cope with ISA registers too. Something
|
|
||||||
like the below often works. Note the locking!
|
|
||||||
|
|
||||||
int foo_read_value(struct i2c_client *client, u8 reg)
|
|
||||||
{
|
|
||||||
int res;
|
|
||||||
if (i2c_is_isa_client(client)) {
|
|
||||||
down(&(((struct foo_data *) (client->data)) -> lock));
|
|
||||||
outb_p(reg,client->addr + FOO_ADDR_REG_OFFSET);
|
|
||||||
res = inb_p(client->addr + FOO_DATA_REG_OFFSET);
|
|
||||||
up(&(((struct foo_data *) (client->data)) -> lock));
|
|
||||||
return res;
|
|
||||||
} else
|
|
||||||
return i2c_smbus_read_byte_data(client,reg);
|
|
||||||
}
|
|
||||||
|
|
||||||
Writing is done the same way.
|
|
||||||
|
|
||||||
|
|
||||||
Probing and attaching
|
Probing and attaching
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
|
The Linux I2C stack was originally written to support access to hardware
|
||||||
|
monitoring chips on PC motherboards, and thus it embeds some assumptions
|
||||||
|
that are more appropriate to SMBus (and PCs) than to I2C. One of these
|
||||||
|
assumptions is that most adapters and devices drivers support the SMBUS_QUICK
|
||||||
|
protocol to probe device presence. Another is that devices and their drivers
|
||||||
|
can be sufficiently configured using only such probe primitives.
|
||||||
|
|
||||||
|
As Linux and its I2C stack became more widely used in embedded systems
|
||||||
|
and complex components such as DVB adapters, those assumptions became more
|
||||||
|
problematic. Drivers for I2C devices that issue interrupts need more (and
|
||||||
|
different) configuration information, as do drivers handling chip variants
|
||||||
|
that can't be distinguished by protocol probing, or which need some board
|
||||||
|
specific information to operate correctly.
|
||||||
|
|
||||||
|
Accordingly, the I2C stack now has two models for associating I2C devices
|
||||||
|
with their drivers: the original "legacy" model, and a newer one that's
|
||||||
|
fully compatible with the Linux 2.6 driver model. These models do not mix,
|
||||||
|
since the "legacy" model requires drivers to create "i2c_client" device
|
||||||
|
objects after SMBus style probing, while the Linux driver model expects
|
||||||
|
drivers to be given such device objects in their probe() routines.
|
||||||
|
|
||||||
|
|
||||||
|
Standard Driver Model Binding ("New Style")
|
||||||
|
-------------------------------------------
|
||||||
|
|
||||||
|
System infrastructure, typically board-specific initialization code or
|
||||||
|
boot firmware, reports what I2C devices exist. For example, there may be
|
||||||
|
a table, in the kernel or from the boot loader, identifying I2C devices
|
||||||
|
and linking them to board-specific configuration information about IRQs
|
||||||
|
and other wiring artifacts, chip type, and so on. That could be used to
|
||||||
|
create i2c_client objects for each I2C device.
|
||||||
|
|
||||||
|
I2C device drivers using this binding model work just like any other
|
||||||
|
kind of driver in Linux: they provide a probe() method to bind to
|
||||||
|
those devices, and a remove() method to unbind.
|
||||||
|
|
||||||
|
static int foo_probe(struct i2c_client *client);
|
||||||
|
static int foo_remove(struct i2c_client *client);
|
||||||
|
|
||||||
|
Remember that the i2c_driver does not create those client handles. The
|
||||||
|
handle may be used during foo_probe(). If foo_probe() reports success
|
||||||
|
(zero not a negative status code) it may save the handle and use it until
|
||||||
|
foo_remove() returns. That binding model is used by most Linux drivers.
|
||||||
|
|
||||||
|
Drivers match devices when i2c_client.driver_name and the driver name are
|
||||||
|
the same; this approach is used in several other busses that don't have
|
||||||
|
device typing support in the hardware. The driver and module name should
|
||||||
|
match, so hotplug/coldplug mechanisms will modprobe the driver.
|
||||||
|
|
||||||
|
|
||||||
|
Device Creation (Standard driver model)
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
If you know for a fact that an I2C device is connected to a given I2C bus,
|
||||||
|
you can instantiate that device by simply filling an i2c_board_info
|
||||||
|
structure with the device address and driver name, and calling
|
||||||
|
i2c_new_device(). This will create the device, then the driver core will
|
||||||
|
take care of finding the right driver and will call its probe() method.
|
||||||
|
If a driver supports different device types, you can specify the type you
|
||||||
|
want using the type field. You can also specify an IRQ and platform data
|
||||||
|
if needed.
|
||||||
|
|
||||||
|
Sometimes you know that a device is connected to a given I2C bus, but you
|
||||||
|
don't know the exact address it uses. This happens on TV adapters for
|
||||||
|
example, where the same driver supports dozens of slightly different
|
||||||
|
models, and I2C device addresses change from one model to the next. In
|
||||||
|
that case, you can use the i2c_new_probed_device() variant, which is
|
||||||
|
similar to i2c_new_device(), except that it takes an additional list of
|
||||||
|
possible I2C addresses to probe. A device is created for the first
|
||||||
|
responsive address in the list. If you expect more than one device to be
|
||||||
|
present in the address range, simply call i2c_new_probed_device() that
|
||||||
|
many times.
|
||||||
|
|
||||||
|
The call to i2c_new_device() or i2c_new_probed_device() typically happens
|
||||||
|
in the I2C bus driver. You may want to save the returned i2c_client
|
||||||
|
reference for later use.
|
||||||
|
|
||||||
|
|
||||||
|
Device Deletion (Standard driver model)
|
||||||
|
---------------------------------------
|
||||||
|
|
||||||
|
Each I2C device which has been created using i2c_new_device() or
|
||||||
|
i2c_new_probed_device() can be unregistered by calling
|
||||||
|
i2c_unregister_device(). If you don't call it explicitly, it will be
|
||||||
|
called automatically before the underlying I2C bus itself is removed, as a
|
||||||
|
device can't survive its parent in the device driver model.
|
||||||
|
|
||||||
|
|
||||||
|
Legacy Driver Binding Model
|
||||||
|
---------------------------
|
||||||
|
|
||||||
Most i2c devices can be present on several i2c addresses; for some this
|
Most i2c devices can be present on several i2c addresses; for some this
|
||||||
is determined in hardware (by soldering some chip pins to Vcc or Ground),
|
is determined in hardware (by soldering some chip pins to Vcc or Ground),
|
||||||
for others this can be changed in software (by writing to specific client
|
for others this can be changed in software (by writing to specific client
|
||||||
|
@ -157,13 +235,9 @@ detection algorithm.
|
||||||
You do not have to use this parameter interface; but don't try to use
|
You do not have to use this parameter interface; but don't try to use
|
||||||
function i2c_probe() if you don't.
|
function i2c_probe() if you don't.
|
||||||
|
|
||||||
NOTE: If you want to write a `sensors' driver, the interface is slightly
|
|
||||||
different! See below.
|
|
||||||
|
|
||||||
|
Probing classes (Legacy model)
|
||||||
|
------------------------------
|
||||||
Probing classes
|
|
||||||
---------------
|
|
||||||
|
|
||||||
All parameters are given as lists of unsigned 16-bit integers. Lists are
|
All parameters are given as lists of unsigned 16-bit integers. Lists are
|
||||||
terminated by I2C_CLIENT_END.
|
terminated by I2C_CLIENT_END.
|
||||||
|
@ -210,8 +284,8 @@ Note that you *have* to call the defined variable `normal_i2c',
|
||||||
without any prefix!
|
without any prefix!
|
||||||
|
|
||||||
|
|
||||||
Attaching to an adapter
|
Attaching to an adapter (Legacy model)
|
||||||
-----------------------
|
--------------------------------------
|
||||||
|
|
||||||
Whenever a new adapter is inserted, or for all adapters if the driver is
|
Whenever a new adapter is inserted, or for all adapters if the driver is
|
||||||
being registered, the callback attach_adapter() is called. Now is the
|
being registered, the callback attach_adapter() is called. Now is the
|
||||||
|
@ -237,17 +311,13 @@ them (unless a `force' parameter was used). In addition, addresses that
|
||||||
are already in use (by some other registered client) are skipped.
|
are already in use (by some other registered client) are skipped.
|
||||||
|
|
||||||
|
|
||||||
The detect client function
|
The detect client function (Legacy model)
|
||||||
--------------------------
|
-----------------------------------------
|
||||||
|
|
||||||
The detect client function is called by i2c_probe. The `kind' parameter
|
The detect client function is called by i2c_probe. The `kind' parameter
|
||||||
contains -1 for a probed detection, 0 for a forced detection, or a positive
|
contains -1 for a probed detection, 0 for a forced detection, or a positive
|
||||||
number for a forced detection with a chip type forced.
|
number for a forced detection with a chip type forced.
|
||||||
|
|
||||||
Below, some things are only needed if this is a `sensors' driver. Those
|
|
||||||
parts are between /* SENSORS ONLY START */ and /* SENSORS ONLY END */
|
|
||||||
markers.
|
|
||||||
|
|
||||||
Returning an error different from -ENODEV in a detect function will cause
|
Returning an error different from -ENODEV in a detect function will cause
|
||||||
the detection to stop: other addresses and adapters won't be scanned.
|
the detection to stop: other addresses and adapters won't be scanned.
|
||||||
This should only be done on fatal or internal errors, such as a memory
|
This should only be done on fatal or internal errors, such as a memory
|
||||||
|
@ -256,64 +326,20 @@ shortage or i2c_attach_client failing.
|
||||||
For now, you can ignore the `flags' parameter. It is there for future use.
|
For now, you can ignore the `flags' parameter. It is there for future use.
|
||||||
|
|
||||||
int foo_detect_client(struct i2c_adapter *adapter, int address,
|
int foo_detect_client(struct i2c_adapter *adapter, int address,
|
||||||
unsigned short flags, int kind)
|
int kind)
|
||||||
{
|
{
|
||||||
int err = 0;
|
int err = 0;
|
||||||
int i;
|
int i;
|
||||||
struct i2c_client *new_client;
|
struct i2c_client *client;
|
||||||
struct foo_data *data;
|
struct foo_data *data;
|
||||||
const char *client_name = ""; /* For non-`sensors' drivers, put the real
|
const char *name = "";
|
||||||
name here! */
|
|
||||||
|
|
||||||
/* Let's see whether this adapter can support what we need.
|
/* Let's see whether this adapter can support what we need.
|
||||||
Please substitute the things you need here!
|
Please substitute the things you need here! */
|
||||||
For `sensors' drivers, add `! is_isa &&' to the if statement */
|
|
||||||
if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
|
if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
|
||||||
I2C_FUNC_SMBUS_WRITE_BYTE))
|
I2C_FUNC_SMBUS_WRITE_BYTE))
|
||||||
goto ERROR0;
|
goto ERROR0;
|
||||||
|
|
||||||
/* SENSORS ONLY START */
|
|
||||||
const char *type_name = "";
|
|
||||||
int is_isa = i2c_is_isa_adapter(adapter);
|
|
||||||
|
|
||||||
/* Do this only if the chip can additionally be found on the ISA bus
|
|
||||||
(hybrid chip). */
|
|
||||||
|
|
||||||
if (is_isa) {
|
|
||||||
|
|
||||||
/* Discard immediately if this ISA range is already used */
|
|
||||||
/* FIXME: never use check_region(), only request_region() */
|
|
||||||
if (check_region(address,FOO_EXTENT))
|
|
||||||
goto ERROR0;
|
|
||||||
|
|
||||||
/* Probe whether there is anything on this address.
|
|
||||||
Some example code is below, but you will have to adapt this
|
|
||||||
for your own driver */
|
|
||||||
|
|
||||||
if (kind < 0) /* Only if no force parameter was used */ {
|
|
||||||
/* We may need long timeouts at least for some chips. */
|
|
||||||
#define REALLY_SLOW_IO
|
|
||||||
i = inb_p(address + 1);
|
|
||||||
if (inb_p(address + 2) != i)
|
|
||||||
goto ERROR0;
|
|
||||||
if (inb_p(address + 3) != i)
|
|
||||||
goto ERROR0;
|
|
||||||
if (inb_p(address + 7) != i)
|
|
||||||
goto ERROR0;
|
|
||||||
#undef REALLY_SLOW_IO
|
|
||||||
|
|
||||||
/* Let's just hope nothing breaks here */
|
|
||||||
i = inb_p(address + 5) & 0x7f;
|
|
||||||
outb_p(~i & 0x7f,address+5);
|
|
||||||
if ((inb_p(address + 5) & 0x7f) != (~i & 0x7f)) {
|
|
||||||
outb_p(i,address+5);
|
|
||||||
return 0;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
/* SENSORS ONLY END */
|
|
||||||
|
|
||||||
/* OK. For now, we presume we have a valid client. We now create the
|
/* OK. For now, we presume we have a valid client. We now create the
|
||||||
client structure, even though we cannot fill it completely yet.
|
client structure, even though we cannot fill it completely yet.
|
||||||
But it allows us to access several i2c functions safely */
|
But it allows us to access several i2c functions safely */
|
||||||
|
@ -323,13 +349,12 @@ For now, you can ignore the `flags' parameter. It is there for future use.
|
||||||
goto ERROR0;
|
goto ERROR0;
|
||||||
}
|
}
|
||||||
|
|
||||||
new_client = &data->client;
|
client = &data->client;
|
||||||
i2c_set_clientdata(new_client, data);
|
i2c_set_clientdata(client, data);
|
||||||
|
|
||||||
new_client->addr = address;
|
client->addr = address;
|
||||||
new_client->adapter = adapter;
|
client->adapter = adapter;
|
||||||
new_client->driver = &foo_driver;
|
client->driver = &foo_driver;
|
||||||
new_client->flags = 0;
|
|
||||||
|
|
||||||
/* Now, we do the remaining detection. If no `force' parameter is used. */
|
/* Now, we do the remaining detection. If no `force' parameter is used. */
|
||||||
|
|
||||||
|
@ -337,19 +362,17 @@ For now, you can ignore the `flags' parameter. It is there for future use.
|
||||||
parameter was used. */
|
parameter was used. */
|
||||||
if (kind < 0) {
|
if (kind < 0) {
|
||||||
/* The below is of course bogus */
|
/* The below is of course bogus */
|
||||||
if (foo_read(new_client,FOO_REG_GENERIC) != FOO_GENERIC_VALUE)
|
if (foo_read(client, FOO_REG_GENERIC) != FOO_GENERIC_VALUE)
|
||||||
goto ERROR1;
|
goto ERROR1;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* SENSORS ONLY START */
|
|
||||||
|
|
||||||
/* Next, specific detection. This is especially important for `sensors'
|
/* Next, specific detection. This is especially important for `sensors'
|
||||||
devices. */
|
devices. */
|
||||||
|
|
||||||
/* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter
|
/* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter
|
||||||
was used. */
|
was used. */
|
||||||
if (kind <= 0) {
|
if (kind <= 0) {
|
||||||
i = foo_read(new_client,FOO_REG_CHIPTYPE);
|
i = foo_read(client, FOO_REG_CHIPTYPE);
|
||||||
if (i == FOO_TYPE_1)
|
if (i == FOO_TYPE_1)
|
||||||
kind = chip1; /* As defined in the enum */
|
kind = chip1; /* As defined in the enum */
|
||||||
else if (i == FOO_TYPE_2)
|
else if (i == FOO_TYPE_2)
|
||||||
|
@ -363,63 +386,31 @@ For now, you can ignore the `flags' parameter. It is there for future use.
|
||||||
|
|
||||||
/* Now set the type and chip names */
|
/* Now set the type and chip names */
|
||||||
if (kind == chip1) {
|
if (kind == chip1) {
|
||||||
type_name = "chip1"; /* For /proc entry */
|
name = "chip1";
|
||||||
client_name = "CHIP 1";
|
|
||||||
} else if (kind == chip2) {
|
} else if (kind == chip2) {
|
||||||
type_name = "chip2"; /* For /proc entry */
|
name = "chip2";
|
||||||
client_name = "CHIP 2";
|
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Reserve the ISA region */
|
|
||||||
if (is_isa)
|
|
||||||
request_region(address,FOO_EXTENT,type_name);
|
|
||||||
|
|
||||||
/* SENSORS ONLY END */
|
|
||||||
|
|
||||||
/* Fill in the remaining client fields. */
|
/* Fill in the remaining client fields. */
|
||||||
strcpy(new_client->name,client_name);
|
strlcpy(client->name, name, I2C_NAME_SIZE);
|
||||||
|
|
||||||
/* SENSORS ONLY BEGIN */
|
|
||||||
data->type = kind;
|
data->type = kind;
|
||||||
/* SENSORS ONLY END */
|
mutex_init(&data->update_lock); /* Only if you use this field */
|
||||||
|
|
||||||
data->valid = 0; /* Only if you use this field */
|
|
||||||
init_MUTEX(&data->update_lock); /* Only if you use this field */
|
|
||||||
|
|
||||||
/* Any other initializations in data must be done here too. */
|
/* Any other initializations in data must be done here too. */
|
||||||
|
|
||||||
/* Tell the i2c layer a new client has arrived */
|
|
||||||
if ((err = i2c_attach_client(new_client)))
|
|
||||||
goto ERROR3;
|
|
||||||
|
|
||||||
/* SENSORS ONLY BEGIN */
|
|
||||||
/* Register a new directory entry with module sensors. See below for
|
|
||||||
the `template' structure. */
|
|
||||||
if ((i = i2c_register_entry(new_client, type_name,
|
|
||||||
foo_dir_table_template,THIS_MODULE)) < 0) {
|
|
||||||
err = i;
|
|
||||||
goto ERROR4;
|
|
||||||
}
|
|
||||||
data->sysctl_id = i;
|
|
||||||
|
|
||||||
/* SENSORS ONLY END */
|
|
||||||
|
|
||||||
/* This function can write default values to the client registers, if
|
/* This function can write default values to the client registers, if
|
||||||
needed. */
|
needed. */
|
||||||
foo_init_client(new_client);
|
foo_init_client(client);
|
||||||
|
|
||||||
|
/* Tell the i2c layer a new client has arrived */
|
||||||
|
if ((err = i2c_attach_client(client)))
|
||||||
|
goto ERROR1;
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
|
|
||||||
/* OK, this is not exactly good programming practice, usually. But it is
|
/* OK, this is not exactly good programming practice, usually. But it is
|
||||||
very code-efficient in this case. */
|
very code-efficient in this case. */
|
||||||
|
|
||||||
ERROR4:
|
|
||||||
i2c_detach_client(new_client);
|
|
||||||
ERROR3:
|
|
||||||
ERROR2:
|
|
||||||
/* SENSORS ONLY START */
|
|
||||||
if (is_isa)
|
|
||||||
release_region(address,FOO_EXTENT);
|
|
||||||
/* SENSORS ONLY END */
|
|
||||||
ERROR1:
|
ERROR1:
|
||||||
kfree(data);
|
kfree(data);
|
||||||
ERROR0:
|
ERROR0:
|
||||||
|
@ -427,8 +418,8 @@ For now, you can ignore the `flags' parameter. It is there for future use.
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
Removing the client
|
Removing the client (Legacy model)
|
||||||
===================
|
==================================
|
||||||
|
|
||||||
The detach_client call back function is called when a client should be
|
The detach_client call back function is called when a client should be
|
||||||
removed. It may actually fail, but only when panicking. This code is
|
removed. It may actually fail, but only when panicking. This code is
|
||||||
|
@ -436,22 +427,12 @@ much simpler than the attachment code, fortunately!
|
||||||
|
|
||||||
int foo_detach_client(struct i2c_client *client)
|
int foo_detach_client(struct i2c_client *client)
|
||||||
{
|
{
|
||||||
int err,i;
|
int err;
|
||||||
|
|
||||||
/* SENSORS ONLY START */
|
|
||||||
/* Deregister with the `i2c-proc' module. */
|
|
||||||
i2c_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id);
|
|
||||||
/* SENSORS ONLY END */
|
|
||||||
|
|
||||||
/* Try to detach the client from i2c space */
|
/* Try to detach the client from i2c space */
|
||||||
if ((err = i2c_detach_client(client)))
|
if ((err = i2c_detach_client(client)))
|
||||||
return err;
|
return err;
|
||||||
|
|
||||||
/* HYBRID SENSORS CHIP ONLY START */
|
|
||||||
if i2c_is_isa_client(client)
|
|
||||||
release_region(client->addr,LM78_EXTENT);
|
|
||||||
/* HYBRID SENSORS CHIP ONLY END */
|
|
||||||
|
|
||||||
kfree(i2c_get_clientdata(client));
|
kfree(i2c_get_clientdata(client));
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
@ -464,45 +445,34 @@ When the kernel is booted, or when your foo driver module is inserted,
|
||||||
you have to do some initializing. Fortunately, just attaching (registering)
|
you have to do some initializing. Fortunately, just attaching (registering)
|
||||||
the driver module is usually enough.
|
the driver module is usually enough.
|
||||||
|
|
||||||
/* Keep track of how far we got in the initialization process. If several
|
|
||||||
things have to initialized, and we fail halfway, only those things
|
|
||||||
have to be cleaned up! */
|
|
||||||
static int __initdata foo_initialized = 0;
|
|
||||||
|
|
||||||
static int __init foo_init(void)
|
static int __init foo_init(void)
|
||||||
{
|
{
|
||||||
int res;
|
int res;
|
||||||
printk("foo version %s (%s)\n",FOO_VERSION,FOO_DATE);
|
|
||||||
|
|
||||||
if ((res = i2c_add_driver(&foo_driver))) {
|
if ((res = i2c_add_driver(&foo_driver))) {
|
||||||
printk("foo: Driver registration failed, module not inserted.\n");
|
printk("foo: Driver registration failed, module not inserted.\n");
|
||||||
foo_cleanup();
|
|
||||||
return res;
|
return res;
|
||||||
}
|
}
|
||||||
foo_initialized ++;
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
|
||||||
void foo_cleanup(void)
|
static void __exit foo_cleanup(void)
|
||||||
{
|
{
|
||||||
if (foo_initialized == 1) {
|
i2c_del_driver(&foo_driver);
|
||||||
if ((res = i2c_del_driver(&foo_driver))) {
|
|
||||||
printk("foo: Driver registration failed, module not removed.\n");
|
|
||||||
return;
|
|
||||||
}
|
|
||||||
foo_initialized --;
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Substitute your own name and email address */
|
/* Substitute your own name and email address */
|
||||||
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
|
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
|
||||||
MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
|
MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
|
||||||
|
|
||||||
|
/* a few non-GPL license types are also allowed */
|
||||||
|
MODULE_LICENSE("GPL");
|
||||||
|
|
||||||
module_init(foo_init);
|
module_init(foo_init);
|
||||||
module_exit(foo_cleanup);
|
module_exit(foo_cleanup);
|
||||||
|
|
||||||
Note that some functions are marked by `__init', and some data structures
|
Note that some functions are marked by `__init', and some data structures
|
||||||
by `__init_data'. Hose functions and structures can be removed after
|
by `__initdata'. These functions and structures can be removed after
|
||||||
kernel booting (or module loading) is completed.
|
kernel booting (or module loading) is completed.
|
||||||
|
|
||||||
|
|
||||||
|
@ -632,110 +602,7 @@ General purpose routines
|
||||||
Below all general purpose routines are listed, that were not mentioned
|
Below all general purpose routines are listed, that were not mentioned
|
||||||
before.
|
before.
|
||||||
|
|
||||||
/* This call returns a unique low identifier for each registered adapter,
|
/* This call returns a unique low identifier for each registered adapter.
|
||||||
* or -1 if the adapter was not registered.
|
|
||||||
*/
|
*/
|
||||||
extern int i2c_adapter_id(struct i2c_adapter *adap);
|
extern int i2c_adapter_id(struct i2c_adapter *adap);
|
||||||
|
|
||||||
|
|
||||||
The sensors sysctl/proc interface
|
|
||||||
=================================
|
|
||||||
|
|
||||||
This section only applies if you write `sensors' drivers.
|
|
||||||
|
|
||||||
Each sensors driver creates a directory in /proc/sys/dev/sensors for each
|
|
||||||
registered client. The directory is called something like foo-i2c-4-65.
|
|
||||||
The sensors module helps you to do this as easily as possible.
|
|
||||||
|
|
||||||
The template
|
|
||||||
------------
|
|
||||||
|
|
||||||
You will need to define a ctl_table template. This template will automatically
|
|
||||||
be copied to a newly allocated structure and filled in where necessary when
|
|
||||||
you call sensors_register_entry.
|
|
||||||
|
|
||||||
First, I will give an example definition.
|
|
||||||
static ctl_table foo_dir_table_template[] = {
|
|
||||||
{ FOO_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &i2c_proc_real,
|
|
||||||
&i2c_sysctl_real,NULL,&foo_func },
|
|
||||||
{ FOO_SYSCTL_FUNC2, "func2", NULL, 0, 0644, NULL, &i2c_proc_real,
|
|
||||||
&i2c_sysctl_real,NULL,&foo_func },
|
|
||||||
{ FOO_SYSCTL_DATA, "data", NULL, 0, 0644, NULL, &i2c_proc_real,
|
|
||||||
&i2c_sysctl_real,NULL,&foo_data },
|
|
||||||
{ 0 }
|
|
||||||
};
|
|
||||||
|
|
||||||
In the above example, three entries are defined. They can either be
|
|
||||||
accessed through the /proc interface, in the /proc/sys/dev/sensors/*
|
|
||||||
directories, as files named func1, func2 and data, or alternatively
|
|
||||||
through the sysctl interface, in the appropriate table, with identifiers
|
|
||||||
FOO_SYSCTL_FUNC1, FOO_SYSCTL_FUNC2 and FOO_SYSCTL_DATA.
|
|
||||||
|
|
||||||
The third, sixth and ninth parameters should always be NULL, and the
|
|
||||||
fourth should always be 0. The fifth is the mode of the /proc file;
|
|
||||||
0644 is safe, as the file will be owned by root:root.
|
|
||||||
|
|
||||||
The seventh and eighth parameters should be &i2c_proc_real and
|
|
||||||
&i2c_sysctl_real if you want to export lists of reals (scaled
|
|
||||||
integers). You can also use your own function for them, as usual.
|
|
||||||
Finally, the last parameter is the call-back to gather the data
|
|
||||||
(see below) if you use the *_proc_real functions.
|
|
||||||
|
|
||||||
|
|
||||||
Gathering the data
|
|
||||||
------------------
|
|
||||||
|
|
||||||
The call back functions (foo_func and foo_data in the above example)
|
|
||||||
can be called in several ways; the operation parameter determines
|
|
||||||
what should be done:
|
|
||||||
|
|
||||||
* If operation == SENSORS_PROC_REAL_INFO, you must return the
|
|
||||||
magnitude (scaling) in nrels_mag;
|
|
||||||
* If operation == SENSORS_PROC_REAL_READ, you must read information
|
|
||||||
from the chip and return it in results. The number of integers
|
|
||||||
to display should be put in nrels_mag;
|
|
||||||
* If operation == SENSORS_PROC_REAL_WRITE, you must write the
|
|
||||||
supplied information to the chip. nrels_mag will contain the number
|
|
||||||
of integers, results the integers themselves.
|
|
||||||
|
|
||||||
The *_proc_real functions will display the elements as reals for the
|
|
||||||
/proc interface. If you set the magnitude to 2, and supply 345 for
|
|
||||||
SENSORS_PROC_REAL_READ, it would display 3.45; and if the user would
|
|
||||||
write 45.6 to the /proc file, it would be returned as 4560 for
|
|
||||||
SENSORS_PROC_REAL_WRITE. A magnitude may even be negative!
|
|
||||||
|
|
||||||
An example function:
|
|
||||||
|
|
||||||
/* FOO_FROM_REG and FOO_TO_REG translate between scaled values and
|
|
||||||
register values. Note the use of the read cache. */
|
|
||||||
void foo_in(struct i2c_client *client, int operation, int ctl_name,
|
|
||||||
int *nrels_mag, long *results)
|
|
||||||
{
|
|
||||||
struct foo_data *data = client->data;
|
|
||||||
int nr = ctl_name - FOO_SYSCTL_FUNC1; /* reduce to 0 upwards */
|
|
||||||
|
|
||||||
if (operation == SENSORS_PROC_REAL_INFO)
|
|
||||||
*nrels_mag = 2;
|
|
||||||
else if (operation == SENSORS_PROC_REAL_READ) {
|
|
||||||
/* Update the readings cache (if necessary) */
|
|
||||||
foo_update_client(client);
|
|
||||||
/* Get the readings from the cache */
|
|
||||||
results[0] = FOO_FROM_REG(data->foo_func_base[nr]);
|
|
||||||
results[1] = FOO_FROM_REG(data->foo_func_more[nr]);
|
|
||||||
results[2] = FOO_FROM_REG(data->foo_func_readonly[nr]);
|
|
||||||
*nrels_mag = 2;
|
|
||||||
} else if (operation == SENSORS_PROC_REAL_WRITE) {
|
|
||||||
if (*nrels_mag >= 1) {
|
|
||||||
/* Update the cache */
|
|
||||||
data->foo_base[nr] = FOO_TO_REG(results[0]);
|
|
||||||
/* Update the chip */
|
|
||||||
foo_write_value(client,FOO_REG_FUNC_BASE(nr),data->foo_base[nr]);
|
|
||||||
}
|
|
||||||
if (*nrels_mag >= 2) {
|
|
||||||
/* Update the cache */
|
|
||||||
data->foo_more[nr] = FOO_TO_REG(results[1]);
|
|
||||||
/* Update the chip */
|
|
||||||
foo_write_value(client,FOO_REG_FUNC_MORE(nr),data->foo_more[nr]);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
|
@ -30,13 +30,13 @@ Juha Sievanen, University of Helsinki Finland
|
||||||
Bug fixes
|
Bug fixes
|
||||||
Core code extensions
|
Core code extensions
|
||||||
|
|
||||||
Auvo Häkkinen, University of Helsinki Finland
|
Auvo Häkkinen, University of Helsinki Finland
|
||||||
LAN OSM code
|
LAN OSM code
|
||||||
/Proc interface to LAN class
|
/Proc interface to LAN class
|
||||||
Bug fixes
|
Bug fixes
|
||||||
Core code extensions
|
Core code extensions
|
||||||
|
|
||||||
Taneli Vähäkangas, University of Helsinki Finland
|
Taneli Vähäkangas, University of Helsinki Finland
|
||||||
Fixes to i2o_config
|
Fixes to i2o_config
|
||||||
|
|
||||||
CREDITS
|
CREDITS
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
H. Peter Anvin <hpa@zytor.com>
|
H. Peter Anvin <hpa@zytor.com>
|
||||||
Last update 2007-01-26
|
Last update 2007-05-07
|
||||||
|
|
||||||
On the i386 platform, the Linux kernel uses a rather complicated boot
|
On the i386 platform, the Linux kernel uses a rather complicated boot
|
||||||
convention. This has evolved partially due to historical aspects, as
|
convention. This has evolved partially due to historical aspects, as
|
||||||
|
@ -11,7 +11,7 @@ bootable image, the complicated PC memory model and due to changed
|
||||||
expectations in the PC industry caused by the effective demise of
|
expectations in the PC industry caused by the effective demise of
|
||||||
real-mode DOS as a mainstream operating system.
|
real-mode DOS as a mainstream operating system.
|
||||||
|
|
||||||
Currently, four versions of the Linux/i386 boot protocol exist.
|
Currently, the following versions of the Linux/i386 boot protocol exist.
|
||||||
|
|
||||||
Old kernels: zImage/Image support only. Some very early kernels
|
Old kernels: zImage/Image support only. Some very early kernels
|
||||||
may not even support a command line.
|
may not even support a command line.
|
||||||
|
@ -35,9 +35,13 @@ Protocol 2.03: (Kernel 2.4.18-pre1) Explicitly makes the highest possible
|
||||||
initrd address available to the bootloader.
|
initrd address available to the bootloader.
|
||||||
|
|
||||||
Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes.
|
Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes.
|
||||||
|
|
||||||
Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
|
Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
|
||||||
Introduce relocatable_kernel and kernel_alignment fields.
|
Introduce relocatable_kernel and kernel_alignment fields.
|
||||||
|
|
||||||
|
Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
|
||||||
|
the boot command line
|
||||||
|
|
||||||
|
|
||||||
**** MEMORY LAYOUT
|
**** MEMORY LAYOUT
|
||||||
|
|
||||||
|
@ -133,6 +137,8 @@ Offset Proto Name Meaning
|
||||||
022C/4 2.03+ initrd_addr_max Highest legal initrd address
|
022C/4 2.03+ initrd_addr_max Highest legal initrd address
|
||||||
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
|
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
|
||||||
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
|
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
|
||||||
|
0235/3 N/A pad2 Unused
|
||||||
|
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
|
||||||
|
|
||||||
(1) For backwards compatibility, if the setup_sects field contains 0, the
|
(1) For backwards compatibility, if the setup_sects field contains 0, the
|
||||||
real value is 4.
|
real value is 4.
|
||||||
|
@ -177,9 +183,9 @@ filled out, however:
|
||||||
a version number. Otherwise, enter 0xFF here.
|
a version number. Otherwise, enter 0xFF here.
|
||||||
|
|
||||||
Assigned boot loader ids:
|
Assigned boot loader ids:
|
||||||
0 LILO
|
0 LILO (0x00 reserved for pre-2.00 bootloader)
|
||||||
1 Loadlin
|
1 Loadlin
|
||||||
2 bootsect-loader
|
2 bootsect-loader (0x20, all other values reserved)
|
||||||
3 SYSLINUX
|
3 SYSLINUX
|
||||||
4 EtherBoot
|
4 EtherBoot
|
||||||
5 ELILO
|
5 ELILO
|
||||||
|
@ -204,6 +210,9 @@ filled out, however:
|
||||||
additional data (such as the kernel command line) moved in
|
additional data (such as the kernel command line) moved in
|
||||||
addition to the real-mode kernel itself.
|
addition to the real-mode kernel itself.
|
||||||
|
|
||||||
|
The unit is bytes starting with the beginning of the boot
|
||||||
|
sector.
|
||||||
|
|
||||||
ramdisk_image, ramdisk_size:
|
ramdisk_image, ramdisk_size:
|
||||||
If your boot loader has loaded an initial ramdisk (initrd),
|
If your boot loader has loaded an initial ramdisk (initrd),
|
||||||
set ramdisk_image to the 32-bit pointer to the ramdisk data
|
set ramdisk_image to the 32-bit pointer to the ramdisk data
|
||||||
|
@ -233,6 +242,12 @@ filled out, however:
|
||||||
if your ramdisk is exactly 131072 bytes long and this field is
|
if your ramdisk is exactly 131072 bytes long and this field is
|
||||||
0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
|
0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
|
||||||
|
|
||||||
|
cmdline_size:
|
||||||
|
The maximum size of the command line without the terminating
|
||||||
|
zero. This means that the command line can contain at most
|
||||||
|
cmdline_size characters. With protocol version 2.05 and
|
||||||
|
earlier, the maximum size was 255.
|
||||||
|
|
||||||
|
|
||||||
**** THE KERNEL COMMAND LINE
|
**** THE KERNEL COMMAND LINE
|
||||||
|
|
||||||
|
@ -241,11 +256,10 @@ loader to communicate with the kernel. Some of its options are also
|
||||||
relevant to the boot loader itself, see "special command line options"
|
relevant to the boot loader itself, see "special command line options"
|
||||||
below.
|
below.
|
||||||
|
|
||||||
The kernel command line is a null-terminated string currently up to
|
The kernel command line is a null-terminated string. The maximum
|
||||||
255 characters long, plus the final null. A string that is too long
|
length can be retrieved from the field cmdline_size. Before protocol
|
||||||
will be automatically truncated by the kernel, a boot loader may allow
|
version 2.06, the maximum was 255 characters. A string that is too
|
||||||
a longer command line to be passed to permit future kernels to extend
|
long will be automatically truncated by the kernel.
|
||||||
this limit.
|
|
||||||
|
|
||||||
If the boot protocol version is 2.02 or later, the address of the
|
If the boot protocol version is 2.02 or later, the address of the
|
||||||
kernel command line is given by the header field cmd_line_ptr (see
|
kernel command line is given by the header field cmd_line_ptr (see
|
||||||
|
@ -267,14 +281,54 @@ command line is entered using the following protocol:
|
||||||
field.
|
field.
|
||||||
|
|
||||||
|
|
||||||
|
**** MEMORY LAYOUT OF THE REAL-MODE CODE
|
||||||
|
|
||||||
|
The real-mode code requires a stack/heap to be set up, as well as
|
||||||
|
memory allocated for the kernel command line. This needs to be done
|
||||||
|
in the real-mode accessible memory in bottom megabyte.
|
||||||
|
|
||||||
|
It should be noted that modern machines often have a sizable Extended
|
||||||
|
BIOS Data Area (EBDA). As a result, it is advisable to use as little
|
||||||
|
of the low megabyte as possible.
|
||||||
|
|
||||||
|
Unfortunately, under the following circumstances the 0x90000 memory
|
||||||
|
segment has to be used:
|
||||||
|
|
||||||
|
- When loading a zImage kernel ((loadflags & 0x01) == 0).
|
||||||
|
- When loading a 2.01 or earlier boot protocol kernel.
|
||||||
|
|
||||||
|
-> For the 2.00 and 2.01 boot protocols, the real-mode code
|
||||||
|
can be loaded at another address, but it is internally
|
||||||
|
relocated to 0x90000. For the "old" protocol, the
|
||||||
|
real-mode code must be loaded at 0x90000.
|
||||||
|
|
||||||
|
When loading at 0x90000, avoid using memory above 0x9a000.
|
||||||
|
|
||||||
|
For boot protocol 2.02 or higher, the command line does not have to be
|
||||||
|
located in the same 64K segment as the real-mode setup code; it is
|
||||||
|
thus permitted to give the stack/heap the full 64K segment and locate
|
||||||
|
the command line above it.
|
||||||
|
|
||||||
|
The kernel command line should not be located below the real-mode
|
||||||
|
code, nor should it be located in high memory.
|
||||||
|
|
||||||
|
|
||||||
**** SAMPLE BOOT CONFIGURATION
|
**** SAMPLE BOOT CONFIGURATION
|
||||||
|
|
||||||
As a sample configuration, assume the following layout of the real
|
As a sample configuration, assume the following layout of the real
|
||||||
mode segment (this is a typical, and recommended layout):
|
mode segment:
|
||||||
|
|
||||||
0x0000-0x7FFF Real mode kernel
|
When loading below 0x90000, use the entire segment:
|
||||||
0x8000-0x8FFF Stack and heap
|
|
||||||
0x9000-0x90FF Kernel command line
|
0x0000-0x7fff Real mode kernel
|
||||||
|
0x8000-0xdfff Stack and heap
|
||||||
|
0xe000-0xffff Kernel command line
|
||||||
|
|
||||||
|
When loading at 0x90000 OR the protocol version is 2.01 or earlier:
|
||||||
|
|
||||||
|
0x0000-0x7fff Real mode kernel
|
||||||
|
0x8000-0x97ff Stack and heap
|
||||||
|
0x9800-0x9fff Kernel command line
|
||||||
|
|
||||||
Such a boot loader should enter the following fields in the header:
|
Such a boot loader should enter the following fields in the header:
|
||||||
|
|
||||||
|
@ -290,22 +344,33 @@ Such a boot loader should enter the following fields in the header:
|
||||||
ramdisk_image = <initrd_address>;
|
ramdisk_image = <initrd_address>;
|
||||||
ramdisk_size = <initrd_size>;
|
ramdisk_size = <initrd_size>;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
if ( protocol >= 0x0202 && loadflags & 0x01 )
|
||||||
|
heap_end = 0xe000;
|
||||||
|
else
|
||||||
|
heap_end = 0x9800;
|
||||||
|
|
||||||
if ( protocol >= 0x0201 ) {
|
if ( protocol >= 0x0201 ) {
|
||||||
heap_end_ptr = 0x9000 - 0x200;
|
heap_end_ptr = heap_end - 0x200;
|
||||||
loadflags |= 0x80; /* CAN_USE_HEAP */
|
loadflags |= 0x80; /* CAN_USE_HEAP */
|
||||||
}
|
}
|
||||||
|
|
||||||
if ( protocol >= 0x0202 ) {
|
if ( protocol >= 0x0202 ) {
|
||||||
cmd_line_ptr = base_ptr + 0x9000;
|
cmd_line_ptr = base_ptr + heap_end;
|
||||||
|
strcpy(cmd_line_ptr, cmdline);
|
||||||
} else {
|
} else {
|
||||||
cmd_line_magic = 0xA33F;
|
cmd_line_magic = 0xA33F;
|
||||||
cmd_line_offset = 0x9000;
|
cmd_line_offset = heap_end;
|
||||||
setup_move_size = 0x9100;
|
setup_move_size = heap_end + strlen(cmdline)+1;
|
||||||
|
strcpy(base_ptr+cmd_line_offset, cmdline);
|
||||||
}
|
}
|
||||||
} else {
|
} else {
|
||||||
/* Very old kernel */
|
/* Very old kernel */
|
||||||
|
|
||||||
|
heap_end = 0x9800;
|
||||||
|
|
||||||
cmd_line_magic = 0xA33F;
|
cmd_line_magic = 0xA33F;
|
||||||
cmd_line_offset = 0x9000;
|
cmd_line_offset = heap_end;
|
||||||
|
|
||||||
/* A very old kernel MUST have its real-mode code
|
/* A very old kernel MUST have its real-mode code
|
||||||
loaded at 0x90000 */
|
loaded at 0x90000 */
|
||||||
|
@ -313,12 +378,11 @@ Such a boot loader should enter the following fields in the header:
|
||||||
if ( base_ptr != 0x90000 ) {
|
if ( base_ptr != 0x90000 ) {
|
||||||
/* Copy the real-mode kernel */
|
/* Copy the real-mode kernel */
|
||||||
memcpy(0x90000, base_ptr, (setup_sects+1)*512);
|
memcpy(0x90000, base_ptr, (setup_sects+1)*512);
|
||||||
/* Copy the command line */
|
|
||||||
memcpy(0x99000, base_ptr+0x9000, 256);
|
|
||||||
|
|
||||||
base_ptr = 0x90000; /* Relocated */
|
base_ptr = 0x90000; /* Relocated */
|
||||||
}
|
}
|
||||||
|
|
||||||
|
strcpy(0x90000+cmd_line_offset, cmdline);
|
||||||
|
|
||||||
/* It is recommended to clear memory up to the 32K mark */
|
/* It is recommended to clear memory up to the 32K mark */
|
||||||
memset(0x90000 + (setup_sects+1)*512, 0,
|
memset(0x90000 + (setup_sects+1)*512, 0,
|
||||||
(64-(setup_sects+1))*512);
|
(64-(setup_sects+1))*512);
|
||||||
|
@ -364,10 +428,11 @@ conflict with actual kernel options now or in the future.
|
||||||
line is parsed.
|
line is parsed.
|
||||||
|
|
||||||
mem=<size>
|
mem=<size>
|
||||||
<size> is an integer in C notation optionally followed by K, M
|
<size> is an integer in C notation optionally followed by
|
||||||
or G (meaning << 10, << 20 or << 30). This specifies the end
|
(case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
|
||||||
of memory to the kernel. This affects the possible placement
|
<< 30, << 40, << 50 or << 60). This specifies the end of
|
||||||
of an initrd, since an initrd should be placed near end of
|
memory to the kernel. This affects the possible placement of
|
||||||
|
an initrd, since an initrd should be placed near end of
|
||||||
memory. Note that this is an option to *both* the kernel and
|
memory. Note that this is an option to *both* the kernel and
|
||||||
the bootloader!
|
the bootloader!
|
||||||
|
|
||||||
|
@ -417,7 +482,7 @@ In our example from above, we would do:
|
||||||
|
|
||||||
/* Set up the real-mode kernel stack */
|
/* Set up the real-mode kernel stack */
|
||||||
_SS = seg;
|
_SS = seg;
|
||||||
_SP = 0x9000; /* Load SP immediately after loading SS! */
|
_SP = heap_end;
|
||||||
|
|
||||||
_DS = _ES = _FS = _GS = seg;
|
_DS = _ES = _FS = _GS = seg;
|
||||||
jmp_far(seg+0x20, 0); /* Run the kernel */
|
jmp_far(seg+0x20, 0); /* Run the kernel */
|
||||||
|
@ -449,8 +514,9 @@ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
|
||||||
code32_start:
|
code32_start:
|
||||||
A 32-bit flat-mode routine *jumped* to immediately after the
|
A 32-bit flat-mode routine *jumped* to immediately after the
|
||||||
transition to protected mode, but before the kernel is
|
transition to protected mode, but before the kernel is
|
||||||
uncompressed. No segments, except CS, are set up; you should
|
uncompressed. No segments, except CS, are guaranteed to be
|
||||||
set them up to KERNEL_DS (0x18) yourself.
|
set up (current kernels do, but older ones do not); you should
|
||||||
|
set them up to BOOT_DS (0x18) yourself.
|
||||||
|
|
||||||
After completing your hook, you should jump to the address
|
After completing your hook, you should jump to the address
|
||||||
that was in this field before your boot loader overwrote it.
|
that was in this field before your boot loader overwrote it.
|
||||||
|
|
|
@ -0,0 +1,247 @@
|
||||||
|
/*
|
||||||
|
* Exercise /dev/mem mmap cases that have been troublesome in the past
|
||||||
|
*
|
||||||
|
* (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
|
||||||
|
* Bjorn Helgaas <bjorn.helgaas@hp.com>
|
||||||
|
*
|
||||||
|
* This program is free software; you can redistribute it and/or modify
|
||||||
|
* it under the terms of the GNU General Public License version 2 as
|
||||||
|
* published by the Free Software Foundation.
|
||||||
|
*/
|
||||||
|
|
||||||
|
#include <stdlib.h>
|
||||||
|
#include <stdio.h>
|
||||||
|
#include <sys/types.h>
|
||||||
|
#include <dirent.h>
|
||||||
|
#include <fcntl.h>
|
||||||
|
#include <fnmatch.h>
|
||||||
|
#include <string.h>
|
||||||
|
#include <sys/mman.h>
|
||||||
|
#include <sys/stat.h>
|
||||||
|
#include <unistd.h>
|
||||||
|
|
||||||
|
int sum;
|
||||||
|
|
||||||
|
int map_mem(char *path, off_t offset, size_t length, int touch)
|
||||||
|
{
|
||||||
|
int fd, rc;
|
||||||
|
void *addr;
|
||||||
|
int *c;
|
||||||
|
|
||||||
|
fd = open(path, O_RDWR);
|
||||||
|
if (fd == -1) {
|
||||||
|
perror(path);
|
||||||
|
return -1;
|
||||||
|
}
|
||||||
|
|
||||||
|
addr = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
|
||||||
|
if (addr == MAP_FAILED)
|
||||||
|
return 1;
|
||||||
|
|
||||||
|
if (touch) {
|
||||||
|
c = (int *) addr;
|
||||||
|
while (c < (int *) (offset + length))
|
||||||
|
sum += *c++;
|
||||||
|
}
|
||||||
|
|
||||||
|
rc = munmap(addr, length);
|
||||||
|
if (rc == -1) {
|
||||||
|
perror("munmap");
|
||||||
|
return -1;
|
||||||
|
}
|
||||||
|
|
||||||
|
close(fd);
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
int scan_sysfs(char *path, char *file, off_t offset, size_t length, int touch)
|
||||||
|
{
|
||||||
|
struct dirent **namelist;
|
||||||
|
char *name, *path2;
|
||||||
|
int i, n, r, rc, result = 0;
|
||||||
|
struct stat buf;
|
||||||
|
|
||||||
|
n = scandir(path, &namelist, 0, alphasort);
|
||||||
|
if (n < 0) {
|
||||||
|
perror("scandir");
|
||||||
|
return -1;
|
||||||
|
}
|
||||||
|
|
||||||
|
for (i = 0; i < n; i++) {
|
||||||
|
name = namelist[i]->d_name;
|
||||||
|
|
||||||
|
if (fnmatch(".", name, 0) == 0)
|
||||||
|
goto skip;
|
||||||
|
if (fnmatch("..", name, 0) == 0)
|
||||||
|
goto skip;
|
||||||
|
|
||||||
|
path2 = malloc(strlen(path) + strlen(name) + 3);
|
||||||
|
strcpy(path2, path);
|
||||||
|
strcat(path2, "/");
|
||||||
|
strcat(path2, name);
|
||||||
|
|
||||||
|
if (fnmatch(file, name, 0) == 0) {
|
||||||
|
rc = map_mem(path2, offset, length, touch);
|
||||||
|
if (rc == 0)
|
||||||
|
fprintf(stderr, "PASS: %s 0x%lx-0x%lx is %s\n", path2, offset, offset + length, touch ? "readable" : "mappable");
|
||||||
|
else if (rc > 0)
|
||||||
|
fprintf(stderr, "PASS: %s 0x%lx-0x%lx not mappable\n", path2, offset, offset + length);
|
||||||
|
else {
|
||||||
|
fprintf(stderr, "FAIL: %s 0x%lx-0x%lx not accessible\n", path2, offset, offset + length);
|
||||||
|
return rc;
|
||||||
|
}
|
||||||
|
} else {
|
||||||
|
r = lstat(path2, &buf);
|
||||||
|
if (r == 0 && S_ISDIR(buf.st_mode)) {
|
||||||
|
rc = scan_sysfs(path2, file, offset, length, touch);
|
||||||
|
if (rc < 0)
|
||||||
|
return rc;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
result |= rc;
|
||||||
|
free(path2);
|
||||||
|
|
||||||
|
skip:
|
||||||
|
free(namelist[i]);
|
||||||
|
}
|
||||||
|
free(namelist);
|
||||||
|
return rc;
|
||||||
|
}
|
||||||
|
|
||||||
|
char buf[1024];
|
||||||
|
|
||||||
|
int read_rom(char *path)
|
||||||
|
{
|
||||||
|
int fd, rc;
|
||||||
|
size_t size = 0;
|
||||||
|
|
||||||
|
fd = open(path, O_RDWR);
|
||||||
|
if (fd == -1) {
|
||||||
|
perror(path);
|
||||||
|
return -1;
|
||||||
|
}
|
||||||
|
|
||||||
|
rc = write(fd, "1", 2);
|
||||||
|
if (rc <= 0) {
|
||||||
|
perror("write");
|
||||||
|
return -1;
|
||||||
|
}
|
||||||
|
|
||||||
|
do {
|
||||||
|
rc = read(fd, buf, sizeof(buf));
|
||||||
|
if (rc > 0)
|
||||||
|
size += rc;
|
||||||
|
} while (rc > 0);
|
||||||
|
|
||||||
|
close(fd);
|
||||||
|
return size;
|
||||||
|
}
|
||||||
|
|
||||||
|
int scan_rom(char *path, char *file)
|
||||||
|
{
|
||||||
|
struct dirent **namelist;
|
||||||
|
char *name, *path2;
|
||||||
|
int i, n, r, rc, result = 0;
|
||||||
|
struct stat buf;
|
||||||
|
|
||||||
|
n = scandir(path, &namelist, 0, alphasort);
|
||||||
|
if (n < 0) {
|
||||||
|
perror("scandir");
|
||||||
|
return -1;
|
||||||
|
}
|
||||||
|
|
||||||
|
for (i = 0; i < n; i++) {
|
||||||
|
name = namelist[i]->d_name;
|
||||||
|
|
||||||
|
if (fnmatch(".", name, 0) == 0)
|
||||||
|
goto skip;
|
||||||
|
if (fnmatch("..", name, 0) == 0)
|
||||||
|
goto skip;
|
||||||
|
|
||||||
|
path2 = malloc(strlen(path) + strlen(name) + 3);
|
||||||
|
strcpy(path2, path);
|
||||||
|
strcat(path2, "/");
|
||||||
|
strcat(path2, name);
|
||||||
|
|
||||||
|
if (fnmatch(file, name, 0) == 0) {
|
||||||
|
rc = read_rom(path2);
|
||||||
|
|
||||||
|
/*
|
||||||
|
* It's OK if the ROM is unreadable. Maybe there
|
||||||
|
* is no ROM, or some other error ocurred. The
|
||||||
|
* important thing is that no MCA happened.
|
||||||
|
*/
|
||||||
|
if (rc > 0)
|
||||||
|
fprintf(stderr, "PASS: %s read %ld bytes\n", path2, rc);
|
||||||
|
else {
|
||||||
|
fprintf(stderr, "PASS: %s not readable\n", path2);
|
||||||
|
return rc;
|
||||||
|
}
|
||||||
|
} else {
|
||||||
|
r = lstat(path2, &buf);
|
||||||
|
if (r == 0 && S_ISDIR(buf.st_mode)) {
|
||||||
|
rc = scan_rom(path2, file);
|
||||||
|
if (rc < 0)
|
||||||
|
return rc;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
result |= rc;
|
||||||
|
free(path2);
|
||||||
|
|
||||||
|
skip:
|
||||||
|
free(namelist[i]);
|
||||||
|
}
|
||||||
|
free(namelist);
|
||||||
|
return rc;
|
||||||
|
}
|
||||||
|
|
||||||
|
main()
|
||||||
|
{
|
||||||
|
int rc;
|
||||||
|
|
||||||
|
if (map_mem("/dev/mem", 0, 0xA0000, 1) == 0)
|
||||||
|
fprintf(stderr, "PASS: /dev/mem 0x0-0xa0000 is readable\n");
|
||||||
|
else
|
||||||
|
fprintf(stderr, "FAIL: /dev/mem 0x0-0xa0000 not accessible\n");
|
||||||
|
|
||||||
|
/*
|
||||||
|
* It's not safe to blindly read the VGA frame buffer. If you know
|
||||||
|
* how to poke the card the right way, it should respond, but it's
|
||||||
|
* not safe in general. Many machines, e.g., Intel chipsets, cover
|
||||||
|
* up a non-responding card by just returning -1, but others will
|
||||||
|
* report the failure as a machine check.
|
||||||
|
*/
|
||||||
|
if (map_mem("/dev/mem", 0xA0000, 0x20000, 0) == 0)
|
||||||
|
fprintf(stderr, "PASS: /dev/mem 0xa0000-0xc0000 is mappable\n");
|
||||||
|
else
|
||||||
|
fprintf(stderr, "FAIL: /dev/mem 0xa0000-0xc0000 not accessible\n");
|
||||||
|
|
||||||
|
if (map_mem("/dev/mem", 0xC0000, 0x40000, 1) == 0)
|
||||||
|
fprintf(stderr, "PASS: /dev/mem 0xc0000-0x100000 is readable\n");
|
||||||
|
else
|
||||||
|
fprintf(stderr, "FAIL: /dev/mem 0xc0000-0x100000 not accessible\n");
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Often you can map all the individual pieces above (0-0xA0000,
|
||||||
|
* 0xA0000-0xC0000, and 0xC0000-0x100000), but can't map the whole
|
||||||
|
* thing at once. This is because the individual pieces use different
|
||||||
|
* attributes, and there's no single attribute supported over the
|
||||||
|
* whole region.
|
||||||
|
*/
|
||||||
|
rc = map_mem("/dev/mem", 0, 1024*1024, 0);
|
||||||
|
if (rc == 0)
|
||||||
|
fprintf(stderr, "PASS: /dev/mem 0x0-0x100000 is mappable\n");
|
||||||
|
else if (rc > 0)
|
||||||
|
fprintf(stderr, "PASS: /dev/mem 0x0-0x100000 not mappable\n");
|
||||||
|
else
|
||||||
|
fprintf(stderr, "FAIL: /dev/mem 0x0-0x100000 not accessible\n");
|
||||||
|
|
||||||
|
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 0xA0000, 1);
|
||||||
|
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xA0000, 0x20000, 0);
|
||||||
|
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xC0000, 0x40000, 1);
|
||||||
|
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 1024*1024, 0);
|
||||||
|
|
||||||
|
scan_rom("/sys/devices", "rom");
|
||||||
|
}
|
|
@ -112,16 +112,6 @@ POTENTIAL ATTRIBUTE ALIASING CASES
|
||||||
|
|
||||||
The /dev/mem mmap constraints apply.
|
The /dev/mem mmap constraints apply.
|
||||||
|
|
||||||
However, since this is for mapping legacy MMIO space, WB access
|
|
||||||
does not make sense. This matters on machines without legacy
|
|
||||||
VGA support: these machines may have WB memory for the entire
|
|
||||||
first megabyte (or even the entire first granule).
|
|
||||||
|
|
||||||
On these machines, we could mmap legacy_mem as WB, which would
|
|
||||||
be safe in terms of attribute aliasing, but X has no way of
|
|
||||||
knowing that it is accessing regular memory, not a frame buffer,
|
|
||||||
so the kernel should fail the mmap rather than doing it with WB.
|
|
||||||
|
|
||||||
read/write of /dev/mem
|
read/write of /dev/mem
|
||||||
|
|
||||||
This uses copy_from_user(), which implicitly uses a kernel
|
This uses copy_from_user(), which implicitly uses a kernel
|
||||||
|
@ -138,14 +128,20 @@ POTENTIAL ATTRIBUTE ALIASING CASES
|
||||||
|
|
||||||
ioremap()
|
ioremap()
|
||||||
|
|
||||||
This returns a kernel identity mapping for use inside the
|
This returns a mapping for use inside the kernel.
|
||||||
kernel.
|
|
||||||
|
|
||||||
If the region is in kern_memmap, we should use the attribute
|
If the region is in kern_memmap, we should use the attribute
|
||||||
specified there. Otherwise, if the EFI memory map reports that
|
specified there.
|
||||||
the entire granule supports WB, we should use that (granules
|
|
||||||
that are partially reserved or occupied by firmware do not appear
|
If the EFI memory map reports that the entire granule supports
|
||||||
in kern_memmap). Otherwise, we should use a UC mapping.
|
WB, we should use that (granules that are partially reserved
|
||||||
|
or occupied by firmware do not appear in kern_memmap).
|
||||||
|
|
||||||
|
If the granule contains non-WB memory, but we can cover the
|
||||||
|
region safely with kernel page table mappings, we can use
|
||||||
|
ioremap_page_range() as most other architectures do.
|
||||||
|
|
||||||
|
Failing all of the above, we have to fall back to a UC mapping.
|
||||||
|
|
||||||
PAST PROBLEM CASES
|
PAST PROBLEM CASES
|
||||||
|
|
||||||
|
@ -158,7 +154,7 @@ PAST PROBLEM CASES
|
||||||
succeed. It may create either WB or UC user mappings, depending
|
succeed. It may create either WB or UC user mappings, depending
|
||||||
on whether the region is in kern_memmap or the EFI memory map.
|
on whether the region is in kern_memmap or the EFI memory map.
|
||||||
|
|
||||||
mmap of 0x0-0xA0000 /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
|
mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
|
||||||
|
|
||||||
See https://bugzilla.novell.com/show_bug.cgi?id=140858.
|
See https://bugzilla.novell.com/show_bug.cgi?id=140858.
|
||||||
|
|
||||||
|
@ -171,28 +167,25 @@ PAST PROBLEM CASES
|
||||||
so it is safe to use WB mappings.
|
so it is safe to use WB mappings.
|
||||||
|
|
||||||
The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
|
The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
|
||||||
which will use a granule-sized UC mapping covering 0-0xFFFFF. This
|
which uses a granule-sized UC mapping. This granule will cover some
|
||||||
granule covers some WB-only memory, but since UC is non-speculative,
|
WB-only memory, but since UC is non-speculative, the processor will
|
||||||
the processor will never generate an uncacheable reference to the
|
never generate an uncacheable reference to the WB-only areas unless
|
||||||
WB-only areas unless the driver explicitly touches them.
|
the driver explicitly touches them.
|
||||||
|
|
||||||
mmap of 0x0-0xFFFFF legacy_mem by "X"
|
mmap of 0x0-0xFFFFF legacy_mem by "X"
|
||||||
|
|
||||||
If the EFI memory map reports this entire range as WB, there
|
If the EFI memory map reports that the entire range supports the
|
||||||
is no VGA MMIO hole, and the mmap should fail or be done with
|
same attributes, we can allow the mmap (and we will prefer WB if
|
||||||
a WB mapping.
|
supported, as is the case with HP sx[12]000 machines with VGA
|
||||||
|
disabled).
|
||||||
|
|
||||||
There's no easy way for X to determine whether the 0xA0000-0xBFFFF
|
If EFI reports the range as partly WB and partly UC (as on sx[12]000
|
||||||
region is a frame buffer or just memory, so I think it's best to
|
machines with VGA enabled), we must fail the mmap because there's no
|
||||||
just fail this mmap request rather than using a WB mapping. As
|
safe attribute to use.
|
||||||
far as I know, there's no need to map legacy_mem with WB
|
|
||||||
mappings.
|
|
||||||
|
|
||||||
Otherwise, a UC mapping of the entire region is probably safe.
|
If EFI reports some of the range but not all (as on Intel firmware
|
||||||
The VGA hole means the region will not be in kern_memmap. The
|
that doesn't report the VGA frame buffer at all), we should fail the
|
||||||
HP sx1000 chipset doesn't support UC access to the memory surrounding
|
mmap and force the user to map just the specific region of interest.
|
||||||
the VGA hole, but X doesn't need that area anyway and should not
|
|
||||||
reference it.
|
|
||||||
|
|
||||||
mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
|
mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
|
||||||
|
|
||||||
|
@ -202,6 +195,16 @@ PAST PROBLEM CASES
|
||||||
This is a special case of the previous case, and the mmap should
|
This is a special case of the previous case, and the mmap should
|
||||||
fail for the same reason as above.
|
fail for the same reason as above.
|
||||||
|
|
||||||
|
read of /sys/devices/.../rom
|
||||||
|
|
||||||
|
For VGA devices, this may cause an ioremap() of 0xC0000. This
|
||||||
|
used to be done with a UC mapping, because the VGA frame buffer
|
||||||
|
at 0xA0000 prevents use of a WB granule. The UC mapping causes
|
||||||
|
an MCA on HP sx[12]000 chipsets.
|
||||||
|
|
||||||
|
We should use WB page table mappings to avoid covering the VGA
|
||||||
|
frame buffer.
|
||||||
|
|
||||||
NOTES
|
NOTES
|
||||||
|
|
||||||
[1] SDM rev 2.2, vol 2, sec 4.4.1.
|
[1] SDM rev 2.2, vol 2, sec 4.4.1.
|
||||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -179,9 +179,9 @@ reporting mode for joystick 1, with both buttons being logically assigned to
|
||||||
the mouse. After any joystick command, the ikbd assumes that joysticks are
|
the mouse. After any joystick command, the ikbd assumes that joysticks are
|
||||||
connected to both Joystick0 and Joystick1. Any mouse command (except MOUSE
|
connected to both Joystick0 and Joystick1. Any mouse command (except MOUSE
|
||||||
DISABLE) then causes port 0 to again be scanned as if it were a mouse, and
|
DISABLE) then causes port 0 to again be scanned as if it were a mouse, and
|
||||||
both buttons are logically connected to it. If a mouse diable command is
|
both buttons are logically connected to it. If a mouse disable command is
|
||||||
received while port 0 is presumed to be a mouse, the button is logically
|
received while port 0 is presumed to be a mouse, the button is logically
|
||||||
assigned to Joystick1 ( until the mouse is reenabled by another mouse command).
|
assigned to Joystick1 (until the mouse is reenabled by another mouse command).
|
||||||
|
|
||||||
9. ikbd Command Set
|
9. ikbd Command Set
|
||||||
|
|
||||||
|
|
|
@ -1,5 +1,3 @@
|
||||||
$Id: input-programming.txt,v 1.4 2001/05/04 09:47:14 vojtech Exp $
|
|
||||||
|
|
||||||
Programming input drivers
|
Programming input drivers
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -20,28 +18,51 @@ pressed or released a BUTTON_IRQ happens. The driver could look like:
|
||||||
#include <asm/irq.h>
|
#include <asm/irq.h>
|
||||||
#include <asm/io.h>
|
#include <asm/io.h>
|
||||||
|
|
||||||
|
static struct input_dev *button_dev;
|
||||||
|
|
||||||
static void button_interrupt(int irq, void *dummy, struct pt_regs *fp)
|
static void button_interrupt(int irq, void *dummy, struct pt_regs *fp)
|
||||||
{
|
{
|
||||||
input_report_key(&button_dev, BTN_1, inb(BUTTON_PORT) & 1);
|
input_report_key(button_dev, BTN_1, inb(BUTTON_PORT) & 1);
|
||||||
input_sync(&button_dev);
|
input_sync(button_dev);
|
||||||
}
|
}
|
||||||
|
|
||||||
static int __init button_init(void)
|
static int __init button_init(void)
|
||||||
{
|
{
|
||||||
|
int error;
|
||||||
|
|
||||||
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
|
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
|
||||||
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
|
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
|
||||||
return -EBUSY;
|
return -EBUSY;
|
||||||
}
|
}
|
||||||
|
|
||||||
button_dev.evbit[0] = BIT(EV_KEY);
|
button_dev = input_allocate_device();
|
||||||
button_dev.keybit[LONG(BTN_0)] = BIT(BTN_0);
|
if (!button_dev) {
|
||||||
|
printk(KERN_ERR "button.c: Not enough memory\n");
|
||||||
|
error = -ENOMEM;
|
||||||
|
goto err_free_irq;
|
||||||
|
}
|
||||||
|
|
||||||
input_register_device(&button_dev);
|
button_dev->evbit[0] = BIT(EV_KEY);
|
||||||
|
button_dev->keybit[LONG(BTN_0)] = BIT(BTN_0);
|
||||||
|
|
||||||
|
error = input_register_device(button_dev);
|
||||||
|
if (error) {
|
||||||
|
printk(KERN_ERR "button.c: Failed to register device\n");
|
||||||
|
goto err_free_dev;
|
||||||
|
}
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
|
||||||
|
err_free_dev:
|
||||||
|
input_free_device(button_dev);
|
||||||
|
err_free_irq:
|
||||||
|
free_irq(BUTTON_IRQ, button_interrupt);
|
||||||
|
return error;
|
||||||
}
|
}
|
||||||
|
|
||||||
static void __exit button_exit(void)
|
static void __exit button_exit(void)
|
||||||
{
|
{
|
||||||
input_unregister_device(&button_dev);
|
input_unregister_device(button_dev);
|
||||||
free_irq(BUTTON_IRQ, button_interrupt);
|
free_irq(BUTTON_IRQ, button_interrupt);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -58,11 +79,12 @@ In the _init function, which is called either upon module load or when
|
||||||
booting the kernel, it grabs the required resources (it should also check
|
booting the kernel, it grabs the required resources (it should also check
|
||||||
for the presence of the device).
|
for the presence of the device).
|
||||||
|
|
||||||
Then it sets the input bitfields. This way the device driver tells the other
|
Then it allocates a new input device structure with input_aloocate_device()
|
||||||
|
and sets up input bitfields. This way the device driver tells the other
|
||||||
parts of the input systems what it is - what events can be generated or
|
parts of the input systems what it is - what events can be generated or
|
||||||
accepted by this input device. Our example device can only generate EV_KEY type
|
accepted by this input device. Our example device can only generate EV_KEY
|
||||||
events, and from those only BTN_0 event code. Thus we only set these two
|
type events, and from those only BTN_0 event code. Thus we only set these
|
||||||
bits. We could have used
|
two bits. We could have used
|
||||||
|
|
||||||
set_bit(EV_KEY, button_dev.evbit);
|
set_bit(EV_KEY, button_dev.evbit);
|
||||||
set_bit(BTN_0, button_dev.keybit);
|
set_bit(BTN_0, button_dev.keybit);
|
||||||
|
@ -76,9 +98,8 @@ Then the example driver registers the input device structure by calling
|
||||||
|
|
||||||
This adds the button_dev structure to linked lists of the input driver and
|
This adds the button_dev structure to linked lists of the input driver and
|
||||||
calls device handler modules _connect functions to tell them a new input
|
calls device handler modules _connect functions to tell them a new input
|
||||||
device has appeared. Because the _connect functions may call kmalloc(,
|
device has appeared. input_register_device() may sleep and therefore must
|
||||||
GFP_KERNEL), which can sleep, input_register_device() must not be called
|
not be called from an interrupt or with a spinlock held.
|
||||||
from an interrupt or with a spinlock held.
|
|
||||||
|
|
||||||
While in use, the only used function of the driver is
|
While in use, the only used function of the driver is
|
||||||
|
|
||||||
|
@ -113,16 +134,10 @@ can use the open and close callback to know when it can stop polling or
|
||||||
release the interrupt and when it must resume polling or grab the interrupt
|
release the interrupt and when it must resume polling or grab the interrupt
|
||||||
again. To do that, we would add this to our example driver:
|
again. To do that, we would add this to our example driver:
|
||||||
|
|
||||||
int button_used = 0;
|
|
||||||
|
|
||||||
static int button_open(struct input_dev *dev)
|
static int button_open(struct input_dev *dev)
|
||||||
{
|
{
|
||||||
if (button_used++)
|
|
||||||
return 0;
|
|
||||||
|
|
||||||
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
|
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
|
||||||
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
|
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
|
||||||
button_used--;
|
|
||||||
return -EBUSY;
|
return -EBUSY;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -131,20 +146,21 @@ static int button_open(struct input_dev *dev)
|
||||||
|
|
||||||
static void button_close(struct input_dev *dev)
|
static void button_close(struct input_dev *dev)
|
||||||
{
|
{
|
||||||
if (!--button_used)
|
|
||||||
free_irq(IRQ_AMIGA_VERTB, button_interrupt);
|
free_irq(IRQ_AMIGA_VERTB, button_interrupt);
|
||||||
}
|
}
|
||||||
|
|
||||||
static int __init button_init(void)
|
static int __init button_init(void)
|
||||||
{
|
{
|
||||||
...
|
...
|
||||||
button_dev.open = button_open;
|
button_dev->open = button_open;
|
||||||
button_dev.close = button_close;
|
button_dev->close = button_close;
|
||||||
...
|
...
|
||||||
}
|
}
|
||||||
|
|
||||||
Note the button_used variable - we have to track how many times the open
|
Note that input core keeps track of number of users for the device and
|
||||||
function was called to know when exactly our device stops being used.
|
makes sure that dev->open() is called only when the first user connects
|
||||||
|
to the device and that dev->close() is called when the very last user
|
||||||
|
disconnects. Calls to both callbacks are serialized.
|
||||||
|
|
||||||
The open() callback should return a 0 in case of success or any nonzero value
|
The open() callback should return a 0 in case of success or any nonzero value
|
||||||
in case of failure. The close() callback (which is void) must always succeed.
|
in case of failure. The close() callback (which is void) must always succeed.
|
||||||
|
@ -187,6 +203,10 @@ the ABS_X axis:
|
||||||
button_dev.absfuzz[ABS_X] = 4;
|
button_dev.absfuzz[ABS_X] = 4;
|
||||||
button_dev.absflat[ABS_X] = 8;
|
button_dev.absflat[ABS_X] = 8;
|
||||||
|
|
||||||
|
Or, you can just say:
|
||||||
|
|
||||||
|
input_set_abs_params(button_dev, ABS_X, 0, 255, 4, 8);
|
||||||
|
|
||||||
This setting would be appropriate for a joystick X axis, with the minimum of
|
This setting would be appropriate for a joystick X axis, with the minimum of
|
||||||
0, maximum of 255 (which the joystick *must* be able to reach, no problem if
|
0, maximum of 255 (which the joystick *must* be able to reach, no problem if
|
||||||
it sometimes reports more, but it must be able to always reach the min and
|
it sometimes reports more, but it must be able to always reach the min and
|
||||||
|
@ -197,14 +217,7 @@ If you don't need absfuzz and absflat, you can set them to zero, which mean
|
||||||
that the thing is precise and always returns to exactly the center position
|
that the thing is precise and always returns to exactly the center position
|
||||||
(if it has any).
|
(if it has any).
|
||||||
|
|
||||||
1.4 The void *private field
|
1.4 NBITS(), LONG(), BIT()
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This field in the input structure can be used to point to any private data
|
|
||||||
structures in the input device driver, in case the driver handles more than
|
|
||||||
one device. You'll need it in the open and close callbacks.
|
|
||||||
|
|
||||||
1.5 NBITS(), LONG(), BIT()
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
These three macros from input.h help some bitfield computations:
|
These three macros from input.h help some bitfield computations:
|
||||||
|
@ -213,13 +226,9 @@ These three macros from input.h help some bitfield computations:
|
||||||
LONG(x) - returns the index in the array in longs for bit x
|
LONG(x) - returns the index in the array in longs for bit x
|
||||||
BIT(x) - returns the index in a long for bit x
|
BIT(x) - returns the index in a long for bit x
|
||||||
|
|
||||||
1.6 The number, id* and name fields
|
1.5 The id* and name fields
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
The dev->number is assigned by the input system to the input device when it
|
|
||||||
is registered. It has no use except for identifying the device to the user
|
|
||||||
in system messages.
|
|
||||||
|
|
||||||
The dev->name should be set before registering the input device by the input
|
The dev->name should be set before registering the input device by the input
|
||||||
device driver. It's a string like 'Generic button device' containing a
|
device driver. It's a string like 'Generic button device' containing a
|
||||||
user friendly name of the device.
|
user friendly name of the device.
|
||||||
|
@ -234,15 +243,25 @@ driver.
|
||||||
|
|
||||||
The id and name fields can be passed to userland via the evdev interface.
|
The id and name fields can be passed to userland via the evdev interface.
|
||||||
|
|
||||||
1.7 The keycode, keycodemax, keycodesize fields
|
1.6 The keycode, keycodemax, keycodesize fields
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
These two fields will be used for any input devices that report their data
|
These three fields should be used by input devices that have dense keymaps.
|
||||||
as scancodes. If not all scancodes can be known by autodetection, they may
|
The keycode is an array used to map from scancodes to input system keycodes.
|
||||||
need to be set by userland utilities. The keycode array then is an array
|
The keycode max should contain the size of the array and keycodesize the
|
||||||
used to map from scancodes to input system keycodes. The keycode max will
|
size of each entry in it (in bytes).
|
||||||
contain the size of the array and keycodesize the size of each entry in it
|
|
||||||
(in bytes).
|
Userspace can query and alter current scancode to keycode mappings using
|
||||||
|
EVIOCGKEYCODE and EVIOCSKEYCODE ioctls on corresponding evdev interface.
|
||||||
|
When a device has all 3 aforementioned fields filled in, the driver may
|
||||||
|
rely on kernel's default implementation of setting and querying keycode
|
||||||
|
mappings.
|
||||||
|
|
||||||
|
1.7 dev->getkeycode() and dev->setkeycode()
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
getkeycode() and setkeycode() callbacks allow drivers to override default
|
||||||
|
keycode/keycodesize/keycodemax mapping mechanism provided by input core
|
||||||
|
and implement sparse keycode maps.
|
||||||
|
|
||||||
1.8 Key autorepeat
|
1.8 Key autorepeat
|
||||||
~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -266,7 +285,7 @@ direction - from the system to the input device driver. If your input device
|
||||||
driver can handle these events, it has to set the respective bits in evbit,
|
driver can handle these events, it has to set the respective bits in evbit,
|
||||||
*and* also the callback routine:
|
*and* also the callback routine:
|
||||||
|
|
||||||
button_dev.event = button_event;
|
button_dev->event = button_event;
|
||||||
|
|
||||||
int button_event(struct input_dev *dev, unsigned int type, unsigned int code, int value);
|
int button_event(struct input_dev *dev, unsigned int type, unsigned int code, int value);
|
||||||
{
|
{
|
||||||
|
|
|
@ -65,15 +65,15 @@ of buttons, see section 0.3 - Unknown Controllers
|
||||||
I've tested this with Stepmania, and it works quite well.
|
I've tested this with Stepmania, and it works quite well.
|
||||||
|
|
||||||
|
|
||||||
0.3 Unkown Controllers
|
0.3 Unknown Controllers
|
||||||
----------------------
|
----------------------
|
||||||
If you have an unkown xbox controller, it should work just fine with
|
If you have an unknown xbox controller, it should work just fine with
|
||||||
the default settings.
|
the default settings.
|
||||||
|
|
||||||
HOWEVER if you have an unknown dance pad not listed below, it will not
|
HOWEVER if you have an unknown dance pad not listed below, it will not
|
||||||
work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
|
work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
|
||||||
|
|
||||||
PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with
|
PLEASE, if you have an unknown controller, email Dom <binary1230@yahoo.com> with
|
||||||
a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
|
a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
|
||||||
whether it is a dance pad or normal controller) so that we can add your pad
|
whether it is a dance pad or normal controller) so that we can add your pad
|
||||||
to the list of supported devices, ensuring that it will work out of the
|
to the list of supported devices, ensuring that it will work out of the
|
||||||
|
|
|
@ -138,7 +138,8 @@ Code Seq# Include File Comments
|
||||||
'm' 00-1F net/irda/irmod.h conflict!
|
'm' 00-1F net/irda/irmod.h conflict!
|
||||||
'n' 00-7F linux/ncp_fs.h
|
'n' 00-7F linux/ncp_fs.h
|
||||||
'n' E0-FF video/matrox.h matroxfb
|
'n' E0-FF video/matrox.h matroxfb
|
||||||
'p' 00-3F linux/mc146818rtc.h
|
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
|
||||||
|
'p' 00-3F linux/mc146818rtc.h conflict!
|
||||||
'p' 40-7F linux/nvram.h
|
'p' 40-7F linux/nvram.h
|
||||||
'p' 80-9F user-space parport
|
'p' 80-9F user-space parport
|
||||||
<mailto:tim@cyberelk.net>
|
<mailto:tim@cyberelk.net>
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
I want to thank all who contributed to this project and especially to:
|
I want to thank all who contributed to this project and especially to:
|
||||||
(in alphabetical order)
|
(in alphabetical order)
|
||||||
|
|
||||||
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
|
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
|
||||||
Tester, lots of bugfixes and hints.
|
Tester, lots of bugfixes and hints.
|
||||||
|
|
||||||
Alan Cox (alan@redhat.com)
|
Alan Cox (alan@redhat.com)
|
||||||
|
@ -11,7 +11,7 @@ Alan Cox (alan@redhat.com)
|
||||||
Henner Eisen (eis@baty.hanse.de)
|
Henner Eisen (eis@baty.hanse.de)
|
||||||
For X.25 implementation.
|
For X.25 implementation.
|
||||||
|
|
||||||
Volker Götz (volker@oops.franken.de)
|
Volker Götz (volker@oops.franken.de)
|
||||||
For contribution of man-pages, the imontty-tool and a perfect
|
For contribution of man-pages, the imontty-tool and a perfect
|
||||||
maintaining of the mailing-list at hub-wue.
|
maintaining of the mailing-list at hub-wue.
|
||||||
|
|
||||||
|
|
|
@ -402,7 +402,7 @@ README for the ISDN-subsystem
|
||||||
the script tools/tcltk/isdnmon. You can add actions for line-status
|
the script tools/tcltk/isdnmon. You can add actions for line-status
|
||||||
changes. See the comments at the beginning of the script for how to
|
changes. See the comments at the beginning of the script for how to
|
||||||
do that. There are other tty-based tools in the tools-subdirectory
|
do that. There are other tty-based tools in the tools-subdirectory
|
||||||
contributed by Michael Knigge (imon), Volker Götz (imontty) and
|
contributed by Michael Knigge (imon), Volker Götz (imontty) and
|
||||||
Andreas Kool (isdnmon).
|
Andreas Kool (isdnmon).
|
||||||
|
|
||||||
l) For initial testing, you can set the verbose-level to 2 (default: 0).
|
l) For initial testing, you can set the verbose-level to 2 (default: 0).
|
||||||
|
|
|
@ -3,8 +3,8 @@ $Id: README.icn,v 1.7 2000/08/06 09:22:51 armin Exp $
|
||||||
You can get the ICN-ISDN-card from:
|
You can get the ICN-ISDN-card from:
|
||||||
|
|
||||||
Thinking Objects Software GmbH
|
Thinking Objects Software GmbH
|
||||||
Versbacher Röthe 159
|
Versbacher Röthe 159
|
||||||
97078 Würzburg
|
97078 Würzburg
|
||||||
Tel: +49 931 2877950
|
Tel: +49 931 2877950
|
||||||
Fax: +49 931 2877951
|
Fax: +49 931 2877951
|
||||||
|
|
||||||
|
|
|
@ -390,7 +390,7 @@ the execution bit, then just do
|
||||||
|
|
||||||
|
|
||||||
originally by Brian A. Lantz, brian@lantz.com
|
originally by Brian A. Lantz, brian@lantz.com
|
||||||
heavily edited for binfmt_misc by Richard Günther
|
heavily edited for binfmt_misc by Richard Günther
|
||||||
new scripts by Colin J. Watson <cjw44@cam.ac.uk>
|
new scripts by Colin J. Watson <cjw44@cam.ac.uk>
|
||||||
added executable Jar file support by Kurt Huwig <kurt@iku-netz.de>
|
added executable Jar file support by Kurt Huwig <kurt@iku-netz.de>
|
||||||
|
|
||||||
|
|
|
@ -249,7 +249,7 @@ following files:
|
||||||
--> filename: Makefile
|
--> filename: Makefile
|
||||||
KERNELDIR := /lib/modules/`uname -r`/build
|
KERNELDIR := /lib/modules/`uname -r`/build
|
||||||
all::
|
all::
|
||||||
$(MAKE) -C $KERNELDIR M=`pwd` $@
|
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
||||||
|
|
||||||
# Module specific targets
|
# Module specific targets
|
||||||
genbin:
|
genbin:
|
||||||
|
|
|
@ -236,7 +236,7 @@
|
||||||
|
|
||||||
* Title: "Design and Implementation of the Second Extended
|
* Title: "Design and Implementation of the Second Extended
|
||||||
Filesystem"
|
Filesystem"
|
||||||
Author: Rémy Card, Theodore Ts'o, Stephen Tweedie.
|
Author: Rémy Card, Theodore Ts'o, Stephen Tweedie.
|
||||||
URL: http://web.mit.edu/tytso/www/linux/ext2intro.html
|
URL: http://web.mit.edu/tytso/www/linux/ext2intro.html
|
||||||
Keywords: ext2, linux fs history, inode, directory, link, devices,
|
Keywords: ext2, linux fs history, inode, directory, link, devices,
|
||||||
VFS, physical structure, performance, benchmarks, ext2fs library,
|
VFS, physical structure, performance, benchmarks, ext2fs library,
|
||||||
|
|
|
@ -64,6 +64,7 @@ parameter is applicable:
|
||||||
GENERIC_TIME The generic timeofday code is enabled.
|
GENERIC_TIME The generic timeofday code is enabled.
|
||||||
NFS Appropriate NFS support is enabled.
|
NFS Appropriate NFS support is enabled.
|
||||||
OSS OSS sound support is enabled.
|
OSS OSS sound support is enabled.
|
||||||
|
PV_OPS A paravirtualized kernel
|
||||||
PARIDE The ParIDE subsystem is enabled.
|
PARIDE The ParIDE subsystem is enabled.
|
||||||
PARISC The PA-RISC architecture is enabled.
|
PARISC The PA-RISC architecture is enabled.
|
||||||
PCI PCI bus support is enabled.
|
PCI PCI bus support is enabled.
|
||||||
|
@ -495,6 +496,30 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
Format: <area>[,<node>]
|
Format: <area>[,<node>]
|
||||||
See also Documentation/networking/decnet.txt.
|
See also Documentation/networking/decnet.txt.
|
||||||
|
|
||||||
|
default_blu= [VT]
|
||||||
|
Format: <blue0>,<blue1>,<blue2>,...,<blue15>
|
||||||
|
Change the default blue palette of the console.
|
||||||
|
This is a 16-member array composed of values
|
||||||
|
ranging from 0-255.
|
||||||
|
|
||||||
|
default_grn= [VT]
|
||||||
|
Format: <green0>,<green1>,<green2>,...,<green15>
|
||||||
|
Change the default green palette of the console.
|
||||||
|
This is a 16-member array composed of values
|
||||||
|
ranging from 0-255.
|
||||||
|
|
||||||
|
default_red= [VT]
|
||||||
|
Format: <red0>,<red1>,<red2>,...,<red15>
|
||||||
|
Change the default red palette of the console.
|
||||||
|
This is a 16-member array composed of values
|
||||||
|
ranging from 0-255.
|
||||||
|
|
||||||
|
default_utf8= [VT]
|
||||||
|
Format=<0|1>
|
||||||
|
Set system-wide default UTF-8 mode for all tty's.
|
||||||
|
Default is 0 and by setting to 1, it enables UTF-8
|
||||||
|
mode for all newly opened or allocated terminals.
|
||||||
|
|
||||||
dhash_entries= [KNL]
|
dhash_entries= [KNL]
|
||||||
Set number of hash buckets for dentry cache.
|
Set number of hash buckets for dentry cache.
|
||||||
|
|
||||||
|
@ -695,8 +720,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
|
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
|
||||||
See Documentation/ide.txt.
|
See Documentation/ide.txt.
|
||||||
|
|
||||||
idle= [HW]
|
idle= [X86]
|
||||||
Format: idle=poll or idle=halt
|
Format: idle=poll or idle=mwait
|
||||||
|
Poll forces a polling idle loop that can slightly improves the performance
|
||||||
|
of waking up a idle CPU, but will use a lot of power and make the system
|
||||||
|
run hot. Not recommended.
|
||||||
|
idle=mwait. On systems which support MONITOR/MWAIT but the kernel chose
|
||||||
|
to not use it because it doesn't save as much power as a normal idle
|
||||||
|
loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same
|
||||||
|
as idle=poll.
|
||||||
|
|
||||||
ignore_loglevel [KNL]
|
ignore_loglevel [KNL]
|
||||||
Ignore loglevel setting - this will print /all/
|
Ignore loglevel setting - this will print /all/
|
||||||
|
@ -722,14 +754,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
|
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
|
||||||
Format: <irq>
|
Format: <irq>
|
||||||
|
|
||||||
combined_mode= [HW] control which driver uses IDE ports in combined
|
|
||||||
mode: legacy IDE driver, libata, or both
|
|
||||||
(in the libata case, libata.atapi_enabled=1 may be
|
|
||||||
useful as well). Note that using the ide or libata
|
|
||||||
options may affect your device naming (e.g. by
|
|
||||||
changing hdc to sdb).
|
|
||||||
Format: combined (default), ide, or libata
|
|
||||||
|
|
||||||
inttest= [IA64]
|
inttest= [IA64]
|
||||||
|
|
||||||
io7= [HW] IO7 for Marvel based alpha systems
|
io7= [HW] IO7 for Marvel based alpha systems
|
||||||
|
@ -808,6 +832,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip
|
lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip
|
||||||
Format: addr:<io>,irq:<irq>
|
Format: addr:<io>,irq:<irq>
|
||||||
|
|
||||||
|
legacy_serial.force [HW,IA-32,X86-64]
|
||||||
|
Probe for COM ports at legacy addresses even
|
||||||
|
if PNPBIOS or ACPI should describe them. This
|
||||||
|
is for working around firmware defects.
|
||||||
|
|
||||||
llsc*= [IA64] See function print_params() in
|
llsc*= [IA64] See function print_params() in
|
||||||
arch/ia64/sn/kernel/llsc4.c.
|
arch/ia64/sn/kernel/llsc4.c.
|
||||||
|
|
||||||
|
@ -1157,6 +1186,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
nomce [IA-32] Machine Check Exception
|
nomce [IA-32] Machine Check Exception
|
||||||
|
|
||||||
|
noreplace-paravirt [IA-32,PV_OPS] Don't patch paravirt_ops
|
||||||
|
|
||||||
|
noreplace-smp [IA-32,SMP] Don't replace SMP instructions
|
||||||
|
with UP alternatives
|
||||||
|
|
||||||
noresidual [PPC] Don't use residual data on PReP machines.
|
noresidual [PPC] Don't use residual data on PReP machines.
|
||||||
|
|
||||||
noresume [SWSUSP] Disables resume and restores original swap
|
noresume [SWSUSP] Disables resume and restores original swap
|
||||||
|
@ -1562,6 +1596,20 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
smart2= [HW]
|
smart2= [HW]
|
||||||
Format: <io1>[,<io2>[,...,<io8>]]
|
Format: <io1>[,<io2>[,...,<io8>]]
|
||||||
|
|
||||||
|
smp-alt-once [IA-32,SMP] On a hotplug CPU system, only
|
||||||
|
attempt to substitute SMP alternatives once at boot.
|
||||||
|
|
||||||
|
smsc-ircc2.nopnp [HW] Don't use PNP to discover SMC devices
|
||||||
|
smsc-ircc2.ircc_cfg= [HW] Device configuration I/O port
|
||||||
|
smsc-ircc2.ircc_sir= [HW] SIR base I/O port
|
||||||
|
smsc-ircc2.ircc_fir= [HW] FIR base I/O port
|
||||||
|
smsc-ircc2.ircc_irq= [HW] IRQ line
|
||||||
|
smsc-ircc2.ircc_dma= [HW] DMA channel
|
||||||
|
smsc-ircc2.ircc_transceiver= [HW] Transceiver type:
|
||||||
|
0: Toshiba Satellite 1800 (GP data pin select)
|
||||||
|
1: Fast pin select (default)
|
||||||
|
2: ATC IRMode
|
||||||
|
|
||||||
snd-ad1816a= [HW,ALSA]
|
snd-ad1816a= [HW,ALSA]
|
||||||
|
|
||||||
snd-ad1848= [HW,ALSA]
|
snd-ad1848= [HW,ALSA]
|
||||||
|
@ -1820,6 +1868,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
[USBHID] The interval which mice are to be polled at.
|
[USBHID] The interval which mice are to be polled at.
|
||||||
|
|
||||||
vdso= [IA-32,SH]
|
vdso= [IA-32,SH]
|
||||||
|
vdso=2: enable compat VDSO (default with COMPAT_VDSO)
|
||||||
vdso=1: enable VDSO (default)
|
vdso=1: enable VDSO (default)
|
||||||
vdso=0: disable VDSO mapping
|
vdso=0: disable VDSO mapping
|
||||||
|
|
||||||
|
|
|
@ -14,6 +14,7 @@ CONTENTS
|
||||||
8. Kprobes Example
|
8. Kprobes Example
|
||||||
9. Jprobes Example
|
9. Jprobes Example
|
||||||
10. Kretprobes Example
|
10. Kretprobes Example
|
||||||
|
Appendix A: The kprobes debugfs interface
|
||||||
|
|
||||||
1. Concepts: Kprobes, Jprobes, Return Probes
|
1. Concepts: Kprobes, Jprobes, Return Probes
|
||||||
|
|
||||||
|
@ -349,9 +350,12 @@ for instrumentation and error reporting.)
|
||||||
|
|
||||||
If the number of times a function is called does not match the number
|
If the number of times a function is called does not match the number
|
||||||
of times it returns, registering a return probe on that function may
|
of times it returns, registering a return probe on that function may
|
||||||
produce undesirable results. We have the do_exit() case covered.
|
produce undesirable results. In such a case, a line:
|
||||||
do_execve() and do_fork() are not an issue. We're unaware of other
|
kretprobe BUG!: Processing kretprobe d000000000041aa8 @ c00000000004f48c
|
||||||
specific cases where this could be a problem.
|
gets printed. With this information, one will be able to correlate the
|
||||||
|
exact instance of the kretprobe that caused the problem. We have the
|
||||||
|
do_exit() case covered. do_execve() and do_fork() are not an issue.
|
||||||
|
We're unaware of other specific cases where this could be a problem.
|
||||||
|
|
||||||
If, upon entry to or exit from a function, the CPU is running on
|
If, upon entry to or exit from a function, the CPU is running on
|
||||||
a stack other than that of the current task, registering a return
|
a stack other than that of the current task, registering a return
|
||||||
|
@ -614,3 +618,27 @@ http://www-106.ibm.com/developerworks/library/l-kprobes.html?ca=dgr-lnxw42Kprobe
|
||||||
http://www.redhat.com/magazine/005mar05/features/kprobes/
|
http://www.redhat.com/magazine/005mar05/features/kprobes/
|
||||||
http://www-users.cs.umn.edu/~boutcher/kprobes/
|
http://www-users.cs.umn.edu/~boutcher/kprobes/
|
||||||
http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf (pages 101-115)
|
http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf (pages 101-115)
|
||||||
|
|
||||||
|
|
||||||
|
Appendix A: The kprobes debugfs interface
|
||||||
|
|
||||||
|
With recent kernels (> 2.6.20) the list of registered kprobes is visible
|
||||||
|
under the /debug/kprobes/ directory (assuming debugfs is mounted at /debug).
|
||||||
|
|
||||||
|
/debug/kprobes/list: Lists all registered probes on the system
|
||||||
|
|
||||||
|
c015d71a k vfs_read+0x0
|
||||||
|
c011a316 j do_fork+0x0
|
||||||
|
c03dedc5 r tcp_v4_rcv+0x0
|
||||||
|
|
||||||
|
The first column provides the kernel address where the probe is inserted.
|
||||||
|
The second column identifies the type of probe (k - kprobe, r - kretprobe
|
||||||
|
and j - jprobe), while the third column specifies the symbol+offset of
|
||||||
|
the probe. If the probed function belongs to a module, the module name
|
||||||
|
is also specified.
|
||||||
|
|
||||||
|
/debug/kprobes/enabled: Turn kprobes ON/OFF
|
||||||
|
|
||||||
|
Provides a knob to globally turn registered kprobes ON or OFF. By default,
|
||||||
|
all kprobes are enabled. By echoing "0" to this file, all registered probes
|
||||||
|
will be disarmed, till such time a "1" is echoed to this file.
|
||||||
|
|
|
@ -67,7 +67,7 @@ void more_data_handling(void *cb_data)
|
||||||
.
|
.
|
||||||
. do stuff with data here
|
. do stuff with data here
|
||||||
.
|
.
|
||||||
kref_put(data, data_release);
|
kref_put(&data->refcount, data_release);
|
||||||
}
|
}
|
||||||
|
|
||||||
int my_data_handler(void)
|
int my_data_handler(void)
|
||||||
|
|
|
@ -33,7 +33,7 @@ or anything. Simply install all the files included in this document, and
|
||||||
laptop mode will automatically be started when you're on battery. For
|
laptop mode will automatically be started when you're on battery. For
|
||||||
your convenience, a tarball containing an installer can be downloaded at:
|
your convenience, a tarball containing an installer can be downloaded at:
|
||||||
|
|
||||||
http://www.xs4all.nl/~bsamwel/laptop_mode/tools/
|
http://www.samwel.tk/laptop_mode/laptop_mode/
|
||||||
|
|
||||||
To configure laptop mode, you need to edit the configuration file, which is
|
To configure laptop mode, you need to edit the configuration file, which is
|
||||||
located in /etc/default/laptop-mode on Debian-based systems, or in
|
located in /etc/default/laptop-mode on Debian-based systems, or in
|
||||||
|
|
|
@ -204,7 +204,7 @@ always shows a "no IRQ here" on the Buddha, and accesses to
|
||||||
the third IDE port are going into data's Nirwana on the
|
the third IDE port are going into data's Nirwana on the
|
||||||
Buddha.
|
Buddha.
|
||||||
|
|
||||||
Jens Schönfeld february 19th, 1997
|
Jens Schönfeld february 19th, 1997
|
||||||
updated may 27th, 1997
|
updated may 27th, 1997
|
||||||
eMail: sysop@nostlgic.tng.oche.de
|
eMail: sysop@nostlgic.tng.oche.de
|
||||||
|
|
||||||
|
|
|
@ -129,7 +129,7 @@ SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
|
||||||
GDA_MAGIC 0x58464552 gda include/asm-mips64/sn/gda.h
|
GDA_MAGIC 0x58464552 gda include/asm-mips64/sn/gda.h
|
||||||
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
||||||
STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h
|
STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h
|
||||||
EEPROM_MAGIC_VALUE 0X5ab478d2 lanai_dev drivers/atm/lanai.c
|
EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c
|
||||||
HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
|
HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
|
||||||
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h
|
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h
|
||||||
PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h
|
PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h
|
||||||
|
|
|
@ -178,6 +178,21 @@ All md devices contain:
|
||||||
The size should be at least PAGE_SIZE (4k) and should be a power
|
The size should be at least PAGE_SIZE (4k) and should be a power
|
||||||
of 2. This can only be set while assembling an array
|
of 2. This can only be set while assembling an array
|
||||||
|
|
||||||
|
layout
|
||||||
|
The "layout" for the array for the particular level. This is
|
||||||
|
simply a number that is interpretted differently by different
|
||||||
|
levels. It can be written while assembling an array.
|
||||||
|
|
||||||
|
reshape_position
|
||||||
|
This is either "none" or a sector number within the devices of
|
||||||
|
the array where "reshape" is up to. If this is set, the three
|
||||||
|
attributes mentioned above (raid_disks, chunk_size, layout) can
|
||||||
|
potentially have 2 values, an old and a new value. If these
|
||||||
|
values differ, reading the attribute returns
|
||||||
|
new (old)
|
||||||
|
and writing will effect the 'new' value, leaving the 'old'
|
||||||
|
unchanged.
|
||||||
|
|
||||||
component_size
|
component_size
|
||||||
For arrays with data redundancy (i.e. not raid0, linear, faulty,
|
For arrays with data redundancy (i.e. not raid0, linear, faulty,
|
||||||
multipath), all components must be the same size - or at least
|
multipath), all components must be the same size - or at least
|
||||||
|
@ -193,11 +208,6 @@ All md devices contain:
|
||||||
1.2 (newer format in varying locations) or "none" indicating that
|
1.2 (newer format in varying locations) or "none" indicating that
|
||||||
the kernel isn't managing metadata at all.
|
the kernel isn't managing metadata at all.
|
||||||
|
|
||||||
layout
|
|
||||||
The "layout" for the array for the particular level. This is
|
|
||||||
simply a number that is interpretted differently by different
|
|
||||||
levels. It can be written while assembling an array.
|
|
||||||
|
|
||||||
resync_start
|
resync_start
|
||||||
The point at which resync should start. If no resync is needed,
|
The point at which resync should start. If no resync is needed,
|
||||||
this will be a very large number. At array creation it will
|
this will be a very large number. At array creation it will
|
||||||
|
@ -259,29 +269,6 @@ All md devices contain:
|
||||||
like active, but no writes have been seen for a while (safe_mode_delay).
|
like active, but no writes have been seen for a while (safe_mode_delay).
|
||||||
|
|
||||||
|
|
||||||
sync_speed_min
|
|
||||||
sync_speed_max
|
|
||||||
This are similar to /proc/sys/dev/raid/speed_limit_{min,max}
|
|
||||||
however they only apply to the particular array.
|
|
||||||
If no value has been written to these, of if the word 'system'
|
|
||||||
is written, then the system-wide value is used. If a value,
|
|
||||||
in kibibytes-per-second is written, then it is used.
|
|
||||||
When the files are read, they show the currently active value
|
|
||||||
followed by "(local)" or "(system)" depending on whether it is
|
|
||||||
a locally set or system-wide value.
|
|
||||||
|
|
||||||
sync_completed
|
|
||||||
This shows the number of sectors that have been completed of
|
|
||||||
whatever the current sync_action is, followed by the number of
|
|
||||||
sectors in total that could need to be processed. The two
|
|
||||||
numbers are separated by a '/' thus effectively showing one
|
|
||||||
value, a fraction of the process that is complete.
|
|
||||||
|
|
||||||
sync_speed
|
|
||||||
This shows the current actual speed, in K/sec, of the current
|
|
||||||
sync_action. It is averaged over the last 30 seconds.
|
|
||||||
|
|
||||||
|
|
||||||
As component devices are added to an md array, they appear in the 'md'
|
As component devices are added to an md array, they appear in the 'md'
|
||||||
directory as new directories named
|
directory as new directories named
|
||||||
dev-XXX
|
dev-XXX
|
||||||
|
@ -412,6 +399,35 @@ also have
|
||||||
Note that the numbers are 'bit' numbers, not 'block' numbers.
|
Note that the numbers are 'bit' numbers, not 'block' numbers.
|
||||||
They should be scaled by the bitmap_chunksize.
|
They should be scaled by the bitmap_chunksize.
|
||||||
|
|
||||||
|
sync_speed_min
|
||||||
|
sync_speed_max
|
||||||
|
This are similar to /proc/sys/dev/raid/speed_limit_{min,max}
|
||||||
|
however they only apply to the particular array.
|
||||||
|
If no value has been written to these, of if the word 'system'
|
||||||
|
is written, then the system-wide value is used. If a value,
|
||||||
|
in kibibytes-per-second is written, then it is used.
|
||||||
|
When the files are read, they show the currently active value
|
||||||
|
followed by "(local)" or "(system)" depending on whether it is
|
||||||
|
a locally set or system-wide value.
|
||||||
|
|
||||||
|
sync_completed
|
||||||
|
This shows the number of sectors that have been completed of
|
||||||
|
whatever the current sync_action is, followed by the number of
|
||||||
|
sectors in total that could need to be processed. The two
|
||||||
|
numbers are separated by a '/' thus effectively showing one
|
||||||
|
value, a fraction of the process that is complete.
|
||||||
|
|
||||||
|
sync_speed
|
||||||
|
This shows the current actual speed, in K/sec, of the current
|
||||||
|
sync_action. It is averaged over the last 30 seconds.
|
||||||
|
|
||||||
|
suspend_lo
|
||||||
|
suspend_hi
|
||||||
|
The two values, given as numbers of sectors, indicate a range
|
||||||
|
within the array where IO will be blocked. This is currently
|
||||||
|
only supported for raid4/5/6.
|
||||||
|
|
||||||
|
|
||||||
Each active md device may also have attributes specific to the
|
Each active md device may also have attributes specific to the
|
||||||
personality module that manages it.
|
personality module that manages it.
|
||||||
These are specific to the implementation of the module and could
|
These are specific to the implementation of the module and could
|
||||||
|
|
|
@ -1,54 +0,0 @@
|
||||||
|
|
||||||
Pete Popov, ppopov@pacbell.net
|
|
||||||
07/11/2001
|
|
||||||
|
|
||||||
This README briefly explains how to use the pci and pci_auto
|
|
||||||
code in arch/mips/kernel. The code was ported from PowerPC and
|
|
||||||
modified slightly. It has been tested pretty well on PPC on some
|
|
||||||
rather complex systems with multiple bridges and devices behind
|
|
||||||
each bridge. However, at the time this README was written, the
|
|
||||||
mips port was tested only on boards with a single pci bus and
|
|
||||||
no P2P bridges. It's very possible that on boards with P2P
|
|
||||||
bridges some modifications have to be made. The code will
|
|
||||||
evolve, no doubt, but currently every single mips board
|
|
||||||
is doing its own pcibios thing and it has become a big
|
|
||||||
mess. This generic pci code is meant to clean up the mips
|
|
||||||
pci mess and make it easier to add pci support to new boards.
|
|
||||||
|
|
||||||
inside the define for your board in arch/mips/config.in.
|
|
||||||
For example, the Galileo EV96100 board looks like this:
|
|
||||||
|
|
||||||
if [ "$CONFIG_MIPS_EV96100" = "y" ]; then
|
|
||||||
define_bool CONFIG_PCI y
|
|
||||||
define_bool CONFIG_MIPS_GT96100 y
|
|
||||||
define_bool CONFIG_NEW_PCI y
|
|
||||||
define_bool CONFIG_SWAP_IO_SPACE y
|
|
||||||
fi
|
|
||||||
|
|
||||||
|
|
||||||
Next, if you want to use the arch/mips/kernel/pci code, which has the
|
|
||||||
pcibios_init() function, add
|
|
||||||
|
|
||||||
define_bool CONFIG_NEW_PCI y
|
|
||||||
|
|
||||||
inside the define for your board. Again, the EV96100 example above
|
|
||||||
show NEW_PCI turned on.
|
|
||||||
|
|
||||||
|
|
||||||
Now you need to add your files to hook in your pci configuration
|
|
||||||
cycles. Usually you'll need only a couple of files named something
|
|
||||||
like pci_fixups.c and pci_ops.c. You can copy the templates
|
|
||||||
provided and fill in the code.
|
|
||||||
|
|
||||||
The file pci_ops.c should contain the pci configuration cycles routines.
|
|
||||||
It also has the mips_pci_channels[] array which contains the descriptors
|
|
||||||
of each pci controller.
|
|
||||||
|
|
||||||
The file pci_fixups.c contains a few routines to do interrupt fixups,
|
|
||||||
resources fixups, and, if needed, pci bios fixups.
|
|
||||||
|
|
||||||
Usually you'll put your pci_fixups.c file in your board specific directory,
|
|
||||||
since the functions in that file are board specific. The functions in
|
|
||||||
pci_ops.c, on the other hand, are usually pci controller specific so that
|
|
||||||
file could be shared among a few different boards using the same
|
|
||||||
pci controller.
|
|
|
@ -30,7 +30,7 @@ The communication layer exists to allow NetLabel configuration and monitoring
|
||||||
from user space. The NetLabel communication layer uses a message based
|
from user space. The NetLabel communication layer uses a message based
|
||||||
protocol built on top of the Generic NETLINK transport mechanism. The exact
|
protocol built on top of the Generic NETLINK transport mechanism. The exact
|
||||||
formatting of these NetLabel messages as well as the Generic NETLINK family
|
formatting of these NetLabel messages as well as the Generic NETLINK family
|
||||||
names can be found in the the 'net/netlabel/' directory as comments in the
|
names can be found in the 'net/netlabel/' directory as comments in the
|
||||||
header files as well as in 'include/net/netlabel.h'.
|
header files as well as in 'include/net/netlabel.h'.
|
||||||
|
|
||||||
* Security Module API
|
* Security Module API
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
This is the 6pack-mini-HOWTO, written by
|
This is the 6pack-mini-HOWTO, written by
|
||||||
|
|
||||||
Andreas Könsgen DG3KQ
|
Andreas Könsgen DG3KQ
|
||||||
Internet: ajk@iehk.rwth-aachen.de
|
Internet: ajk@iehk.rwth-aachen.de
|
||||||
AMPR-net: dg3kq@db0pra.ampr.org
|
AMPR-net: dg3kq@db0pra.ampr.org
|
||||||
AX.25: dg3kq@db0ach.#nrw.deu.eu
|
AX.25: dg3kq@db0ach.#nrw.deu.eu
|
||||||
|
|
|
@ -160,7 +160,7 @@ on current cpu. This primitive is called by dev->poll(), when
|
||||||
it completes its work. The device cannot be out of poll list at this
|
it completes its work. The device cannot be out of poll list at this
|
||||||
call, if it is then clearly it is a BUG(). You'll know ;->
|
call, if it is then clearly it is a BUG(). You'll know ;->
|
||||||
|
|
||||||
All these above nethods are used below. So keep reading for clarity.
|
All of the above methods are used below, so keep reading for clarity.
|
||||||
|
|
||||||
Device driver changes to be made when porting NAPI
|
Device driver changes to be made when porting NAPI
|
||||||
==================================================
|
==================================================
|
||||||
|
|
|
@ -13,7 +13,7 @@ You can find the latest version of this document at
|
||||||
|
|
||||||
Please send me your comments to
|
Please send me your comments to
|
||||||
|
|
||||||
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
|
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
|
||||||
|
|
||||||
-------------------------------------------------------------------------------
|
-------------------------------------------------------------------------------
|
||||||
+ Why use PACKET_MMAP
|
+ Why use PACKET_MMAP
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
|
|
||||||
SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
|
SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
|
||||||
|
|
||||||
Bartók István <bartoki@itc.hu>
|
Bartók István <bartoki@itc.hu>
|
||||||
Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
|
Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
|
||||||
|
|
||||||
-----------------------------------------------------------------
|
-----------------------------------------------------------------
|
||||||
|
|
|
@ -1,9 +1,9 @@
|
||||||
|
|
||||||
SliceCOM adapter user's documentation - for the 0.51 driver version
|
SliceCOM adapter user's documentation - for the 0.51 driver version
|
||||||
|
|
||||||
Written by Bartók István <bartoki@itc.hu>
|
Written by Bartók István <bartoki@itc.hu>
|
||||||
|
|
||||||
English translation: Lakatos György <gyuri@itc.hu>
|
English translation: Lakatos György <gyuri@itc.hu>
|
||||||
Mon Dec 11 15:28:42 CET 2000
|
Mon Dec 11 15:28:42 CET 2000
|
||||||
|
|
||||||
Last modified: Wed Aug 29 17:25:37 CEST 2001
|
Last modified: Wed Aug 29 17:25:37 CEST 2001
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue