Merge /pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
Wim Van Sebroeck
commit
5c34202b8b
4626 changed files with 237138 additions and 95767 deletions
CREDITS
Documentation
ABI/removed
CodingStyleDocBook
MSI-HOWTO.txtSubmitChecklistSubmittingDriversSubmittingPatchesaccounting
arm
auxdisplay
binfmt_misc.txtblackfin
block
cciss.txtcpu-freq
cpu-hotplug.txtcrypto
device-mapper
dontdiffdriver-model
dvb
fb
feature-removal-schedule.txtfilesystems
fujitsu/frv
gpio.txthwmon
i2c
i2o
i386
ia64
input
ioctl-number.txtisdn
java.txtkbuild
kernel-docs.txtkernel-parameters.txtkprobes.txtkref.txtlaptop-mode.txtm68k
magic-number.txtmd.txtmips/pci
netlabel
networking
62
CREDITS
62
CREDITS
|
|
@ -380,7 +380,7 @@ S: FutureTV Labs Ltd
|
|||
S: Brunswick House, 61-69 Newmarket Rd, Cambridge CB5 8EG
|
||||
S: United Kingdom
|
||||
|
||||
N: Thomas Bogendörfer
|
||||
N: Thomas Bogendörfer
|
||||
E: tsbogend@alpha.franken.de
|
||||
D: PCnet32 driver, SONIC driver, JAZZ_ESP 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: Linux CD and Support Giveaway List
|
||||
|
||||
N: Erik Inge Bolsø
|
||||
N: Erik Inge Bolsø
|
||||
E: knan@mo.himolde.no
|
||||
D: Misc kernel hacks
|
||||
|
||||
|
|
@ -428,7 +428,7 @@ D: Various fixes (mostly networking)
|
|||
S: Montreal, Quebec
|
||||
S: Canada
|
||||
|
||||
N: Zoltán Böszörményi
|
||||
N: Zoltán Böszörményi
|
||||
E: zboszor@mail.externet.hu
|
||||
D: MTRR emulation with Cyrix style ARR registers, Athlon MTRR support
|
||||
|
||||
|
|
@ -661,7 +661,7 @@ N: Kees Cook
|
|||
E: kees@outflux.net
|
||||
W: http://outflux.net/
|
||||
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: USA
|
||||
|
||||
|
|
@ -1029,11 +1029,11 @@ D: Future Domain TMC-16x0 SCSI driver (author)
|
|||
D: APM driver (early port)
|
||||
D: DRM drivers (author of several)
|
||||
|
||||
N: János Farkas
|
||||
N: János Farkas
|
||||
E: chexum@shadow.banki.hu
|
||||
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
|
||||
S: Madarász Viktor utca 25
|
||||
S: Madarász Viktor utca 25
|
||||
S: 1131 Budapest
|
||||
S: Hungary
|
||||
|
||||
|
|
@ -1044,10 +1044,10 @@ D: UDF filesystem
|
|||
S: (ask for current address)
|
||||
S: USA
|
||||
|
||||
N: Jürgen Fischer
|
||||
E: fischer@norbit.de (=?iso-8859-1?q?J=FCrgen?= Fischer)
|
||||
N: Jürgen Fischer
|
||||
E: fischer@norbit.de
|
||||
D: Author of Adaptec AHA-152x SCSI driver
|
||||
S: Schulstraße 18
|
||||
S: Schulstraße 18
|
||||
S: 26506 Norden
|
||||
S: Germany
|
||||
|
||||
|
|
@ -1113,7 +1113,7 @@ E: fuganti@netbank.com.br
|
|||
D: random kernel hacker, ZF MachZ Watchdog driver
|
||||
S: Conectiva S.A.
|
||||
S: R. Tocantins, 89 - Cristo Rei
|
||||
S: 80050-430 - Curitiba - Paraná
|
||||
S: 80050-430 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Kumar Gala
|
||||
|
|
@ -1258,12 +1258,12 @@ S: 44 St. Joseph Street, Suite 506
|
|||
S: Toronto, Ontario, M4Y 2W4
|
||||
S: Canada
|
||||
|
||||
N: Richard Günther
|
||||
N: Richard Günther
|
||||
E: rguenth@tat.physik.uni-tuebingen.de
|
||||
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
|
||||
D: binfmt_misc
|
||||
S: 72074 Tübingen
|
||||
S: 72074 Tübingen
|
||||
S: Germany
|
||||
|
||||
N: Justin Guyett
|
||||
|
|
@ -1287,7 +1287,7 @@ N: Bruno Haible
|
|||
E: haible@ma2s2.mathematik.uni-karlsruhe.de
|
||||
D: SysV FS, shm swapping, memory management fixes
|
||||
S: 17 rue Danton
|
||||
S: F - 94270 Le Kremlin-Bicêtre
|
||||
S: F - 94270 Le Kremlin-Bicêtre
|
||||
S: France
|
||||
|
||||
N: Greg Hankins
|
||||
|
|
@ -1701,7 +1701,7 @@ S: Czech Republic
|
|||
N: Jakob Kemi
|
||||
E: jakob.kemi@telia.com
|
||||
D: V4L W9966 Webcam driver
|
||||
S: Forsbyvägen 33
|
||||
S: Forsbyvägen 33
|
||||
S: 74143 Knivsta
|
||||
S: Sweden
|
||||
|
||||
|
|
@ -1745,8 +1745,9 @@ S: D-64295
|
|||
S: Germany
|
||||
|
||||
N: Andi Kleen
|
||||
E: ak@muc.de
|
||||
D: network hacker, syncookies
|
||||
E: andi@firstfloor.org
|
||||
U: http://www.halobates.de
|
||||
D: network, x86, NUMA, various hacks
|
||||
S: Schwalbenstr. 96
|
||||
S: 85551 Ottobrunn
|
||||
S: Germany
|
||||
|
|
@ -2064,7 +2065,7 @@ D: misc. kernel hacking and debugging
|
|||
S: Cambridge, MA 02139
|
||||
S: USA
|
||||
|
||||
N: Martin von Löwis
|
||||
N: Martin von Löwis
|
||||
E: loewis@informatik.hu-berlin.de
|
||||
D: script binary format
|
||||
D: NTFS driver
|
||||
|
|
@ -2141,7 +2142,7 @@ S: PO BOX 220, HFX. CENTRAL
|
|||
S: Halifax, Nova Scotia
|
||||
S: Canada B3J 3C8
|
||||
|
||||
N: Kai Mäkisara
|
||||
N: Kai Mäkisara
|
||||
E: Kai.Makisara@kolumbus.fi
|
||||
D: SCSI Tape Driver
|
||||
|
||||
|
|
@ -2298,8 +2299,8 @@ E: acme@redhat.com
|
|||
W: http://oops.ghostprotocols.net:81/blog/
|
||||
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
|
||||
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
|
||||
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
||||
S: 80240-060 - Curitiba - Paraná
|
||||
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
||||
S: 80240-060 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Karsten Merker
|
||||
|
|
@ -2579,10 +2580,9 @@ S: Australia
|
|||
|
||||
N: Miguel Ojeda Sandonis
|
||||
E: maxextreme@gmail.com
|
||||
D: Author: Auxiliary LCD Controller driver (ks0108)
|
||||
D: Author: Auxiliary LCD driver (cfag12864b)
|
||||
D: Author: Auxiliary LCD framebuffer driver (cfag12864bfb)
|
||||
D: Maintainer: Auxiliary display drivers tree (drivers/auxdisplay/*)
|
||||
W: http://maxextreme.googlepages.com/
|
||||
D: Author of the ks0108, cfag12864b and cfag12864bfb auxiliary display drivers.
|
||||
D: Maintainer of the auxiliary display drivers tree (drivers/auxdisplay/*)
|
||||
S: C/ Mieses 20, 9-B
|
||||
S: Valladolid 47009
|
||||
S: Spain
|
||||
|
|
@ -2785,10 +2785,10 @@ N: Juan Quintela
|
|||
E: quintela@fi.udc.es
|
||||
D: Memory Management hacking
|
||||
S: LFCIA
|
||||
S: Departamento de Computación
|
||||
S: Universidade da Coruña
|
||||
S: Departamento de Computación
|
||||
S: Universidade da Coruña
|
||||
S: E-15071
|
||||
S: A Coruña
|
||||
S: A Coruña
|
||||
S: Spain
|
||||
|
||||
N: Augusto Cesar Radtke
|
||||
|
|
@ -2939,7 +2939,7 @@ E: aris@cathedrallabs.org
|
|||
D: Support for EtherExpress 10 ISA (i82595) in eepro driver
|
||||
D: User level driver support for input
|
||||
S: R. Jose Serrato, 130 - Santa Candida
|
||||
S: 82640-320 - Curitiba - Paraná
|
||||
S: 82640-320 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Alessandro Rubini
|
||||
|
|
@ -3345,15 +3345,15 @@ P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB
|
|||
D: rcutorture maintainer
|
||||
D: lock annotations, finding and fixing lock bugs
|
||||
|
||||
N: Winfried Trümper
|
||||
N: Winfried Trümper
|
||||
E: winni@xpilot.org
|
||||
W: http://www.shop.de/~winni/
|
||||
D: German HOWTO, Crash-Kurs Linux (German, 100 comprehensive pages)
|
||||
D: CD-Writing HOWTO, various mini-HOWTOs
|
||||
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: D-50968 Köln
|
||||
S: D-50968 Köln
|
||||
|
||||
N: Tsu-Sheng Tsao
|
||||
E: tsusheng@scf.usc.edu
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Description:
|
|||
races, contains a naming policy within the kernel that is
|
||||
against the LSB, and can be replaced by using udev.
|
||||
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.
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -41,8 +41,9 @@ psdocs: $(PS)
|
|||
PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
|
||||
pdfdocs: $(PDF)
|
||||
|
||||
HTML := $(patsubst %.xml, %.html, $(BOOKS))
|
||||
HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
|
||||
htmldocs: $(HTML)
|
||||
$(call build_main_index)
|
||||
|
||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||
mandocs: $(MAN)
|
||||
|
|
@ -132,10 +133,17 @@ quiet_cmd_db2pdf = PDF $@
|
|||
%.pdf : %.xml
|
||||
$(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 $@
|
||||
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
|
||||
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
||||
Goto $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||
|
||||
%.html: %.xml
|
||||
@(which xmlto > /dev/null 2>&1) || \
|
||||
|
|
@ -152,6 +160,7 @@ quiet_cmd_db2man = MAN $@
|
|||
@(which xmlto > /dev/null 2>&1) || \
|
||||
(echo "*** You need to install xmlto ***"; \
|
||||
exit 1)
|
||||
$(Q)mkdir -p $(obj)/man
|
||||
$(call cmd,db2man)
|
||||
@touch $@
|
||||
|
||||
|
|
@ -212,11 +221,7 @@ clean-files := $(DOCBOOKS) \
|
|||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||
$(C-procfs-example)
|
||||
|
||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS))
|
||||
|
||||
#man put files in man subdir - traverse down
|
||||
subdir- := man/
|
||||
|
||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
|
||||
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -84,6 +84,10 @@ X!Iinclude/linux/kobject.h
|
|||
!Ekernel/rcupdate.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Device Resource Management</title>
|
||||
!Edrivers/base/devres.c
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="adt">
|
||||
|
|
@ -576,4 +580,67 @@ X!Idrivers/video/console/fonts.c
|
|||
!Edrivers/input/ff-core.c
|
||||
!Edrivers/input/ff-memless.c
|
||||
</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>
|
||||
|
|
|
|||
|
|
@ -79,12 +79,12 @@
|
|||
<chapter id="usage">
|
||||
<title>Usage</title>
|
||||
<para>
|
||||
This chapter provides examples how to use the library.
|
||||
This chapter provides examples of how to use the library.
|
||||
</para>
|
||||
<sect1>
|
||||
<title>Initializing</title>
|
||||
<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
|
||||
information for encoding, decoding and error correction
|
||||
with the given polynomial. It either uses an existing
|
||||
|
|
@ -98,10 +98,10 @@
|
|||
static struct rs_control *rs_decoder;
|
||||
|
||||
/* 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
|
||||
* primitve element to generate roots = 1
|
||||
* generator polinomial degree (number of roots) = 6
|
||||
* primitive element to generate roots = 1
|
||||
* generator polynomial degree (number of roots) = 6
|
||||
*/
|
||||
rs_decoder = init_rs (10, 0x409, 0, 1, 6);
|
||||
</programlisting>
|
||||
|
|
@ -116,12 +116,12 @@ rs_decoder = init_rs (10, 0x409, 0, 1, 6);
|
|||
</para>
|
||||
<para>
|
||||
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
|
||||
ECC, where the all 0xFF is inverted to an all 0x00.
|
||||
The Reed-Solomon code for all 0x00 is all 0x00. The
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
|
|
@ -273,7 +273,7 @@ free_rs(rs_decoder);
|
|||
May be used under the terms of the GNU General Public License (GPL)
|
||||
</programlisting>
|
||||
<para>
|
||||
The wrapper functions and interfaces are written by Thomas Gleixner
|
||||
The wrapper functions and interfaces are written by Thomas Gleixner.
|
||||
</para>
|
||||
<para>
|
||||
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
|
||||
|
||||
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()
|
||||
Under some circumstances it might be required to disable MSI on a
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
injection might be appropriate.
|
||||
|
||||
22: Newly-added code has been compiled with `gcc -W'. This will generate
|
||||
lots of noise, but is good for finding bugs like "warning: comparison
|
||||
between signed and unsigned".
|
||||
22: Newly-added code has been compiled with `gcc -W' (use "make
|
||||
EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
|
||||
finding bugs like "warning: comparison between signed and unsigned".
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
the author then patches will be redirected to them unless
|
||||
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
|
||||
describe the patch which that email contains. The "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
|
||||
a globally-unique identifier for that patch. It propagates
|
||||
|
|
|
|||
|
|
@ -61,8 +61,6 @@ __u64 stime, utime;
|
|||
#define MAX_MSG_SIZE 1024
|
||||
/* Maximum number of cpus expected to be specified in a cpumask */
|
||||
#define MAX_CPUS 32
|
||||
/* Maximum length of pathname to log file */
|
||||
#define MAX_FILENAME 256
|
||||
|
||||
struct msgtemplate {
|
||||
struct nlmsghdr n;
|
||||
|
|
@ -72,6 +70,16 @@ struct msgtemplate {
|
|||
|
||||
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
|
||||
*/
|
||||
|
|
@ -221,13 +229,13 @@ int main(int argc, char *argv[])
|
|||
int count = 0;
|
||||
int write_file = 0;
|
||||
int maskset = 0;
|
||||
char logfile[128];
|
||||
char *logfile = NULL;
|
||||
int loop = 0;
|
||||
|
||||
struct msgtemplate msg;
|
||||
|
||||
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)
|
||||
break;
|
||||
|
||||
|
|
@ -241,7 +249,7 @@ int main(int argc, char *argv[])
|
|||
print_io_accounting = 1;
|
||||
break;
|
||||
case 'w':
|
||||
strncpy(logfile, optarg, MAX_FILENAME);
|
||||
logfile = strdup(optarg);
|
||||
printf("write to file %s\n", logfile);
|
||||
write_file = 1;
|
||||
break;
|
||||
|
|
@ -277,7 +285,7 @@ int main(int argc, char *argv[])
|
|||
loop = 1;
|
||||
break;
|
||||
default:
|
||||
printf("Unknown option %d\n", c);
|
||||
usage();
|
||||
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.
|
||||
|
||||
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
|
||||
parent IRQ via the correct chip specific function. For instance, if
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Support
|
|||
|
||||
http://handhelds.org/moin/moin.cgi/HpIpaqH1940
|
||||
|
||||
Herbert Pötzl pages:
|
||||
Herbert Pötzl pages:
|
||||
|
||||
http://vserver.13thfloor.at/H1940/
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ Maintainers
|
|||
-----------
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -78,9 +78,9 @@ Select (17)------------------------------(16) Data / Instruction
|
|||
Ground (18)---[GND] [+5v]---(19) LED +
|
||||
Ground (19)---[GND]
|
||||
Ground (20)---[GND] E A Values:
|
||||
Ground (21)---[GND] [GND]---[P1]---(18) Vee · R = Resistor = 22 ohm
|
||||
Ground (22)---[GND] | · P1 = Preset = 10 Kohm
|
||||
Ground (23)---[GND] ---- S ------( 3) V0 · P2 = Preset = 1 Kohm
|
||||
Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm
|
||||
Ground (22)---[GND] | - P1 = Preset = 10 Kohm
|
||||
Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm
|
||||
Ground (24)---[GND] | |
|
||||
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
|
||||
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>
|
||||
|
|
|
|||
11
Documentation/blackfin/00-INDEX
Normal file
11
Documentation/blackfin/00-INDEX
Normal file
|
|
@ -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.
|
||||
169
Documentation/blackfin/Filesystems
Normal file
169
Documentation/blackfin/Filesystems
Normal file
|
|
@ -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
|
||||
48
Documentation/blackfin/cache-lock.txt
Normal file
48
Documentation/blackfin/cache-lock.txt
Normal file
|
|
@ -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.
|
||||
65
Documentation/blackfin/cachefeatures.txt
Normal file
65
Documentation/blackfin/cachefeatures.txt
Normal file
|
|
@ -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
|
||||
priorities is supported for reads on files. This enables users to io nice
|
||||
processes or process groups, similar to what has been possible to cpu
|
||||
scheduling for ages. This document mainly details the current possibilites
|
||||
with cfq, other io schedulers do not support io priorities so far.
|
||||
priorities are supported for reads on files. This enables users to io nice
|
||||
processes or process groups, similar to what has been possible with cpu
|
||||
scheduling for ages. This document mainly details the current possibilities
|
||||
with cfq; other io schedulers do not support io priorities thus far.
|
||||
|
||||
Scheduling classes
|
||||
------------------
|
||||
|
|
|
|||
|
|
@ -22,14 +22,21 @@ This driver is known to work with the following cards:
|
|||
* SA E200i
|
||||
* 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:
|
||||
|
||||
# cd /dev
|
||||
# ./MAKEDEV cciss
|
||||
|
||||
Device Naming:
|
||||
--------------
|
||||
|
||||
You need some entries in /dev for the cciss device. The MAKEDEV script
|
||||
can make device nodes for you automatically. Currently the device setup
|
||||
is as follows:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Contents
|
|||
|
||||
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
|
||||
interface (when configured) will appear in a separate directory under cpufreq
|
||||
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 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 interrupts targeted to this CPU is 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
|
||||
__cpu_disable() to perform arch specific cleanup.
|
||||
- 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
|
||||
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) {
|
||||
case CPU_ONLINE:
|
||||
case CPU_ONLINE_FROZEN:
|
||||
foobar_online_action(cpu);
|
||||
break;
|
||||
case CPU_DEAD:
|
||||
case CPU_DEAD_FROZEN:
|
||||
foobar_dead_action(cpu);
|
||||
break;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ Portions of this API were derived from the following projects:
|
|||
and;
|
||||
|
||||
Nettle (http://www.lysator.liu.se/~nisse/nettle/)
|
||||
Niels Möller
|
||||
Niels Möller
|
||||
|
||||
Original developers of the crypto algorithms:
|
||||
|
||||
|
|
@ -200,8 +200,8 @@ SHA1 algorithm contributors:
|
|||
|
||||
DES algorithm contributors:
|
||||
Raimar Falke
|
||||
Gisle Sælensminde
|
||||
Niels Möller
|
||||
Gisle Sælensminde
|
||||
Niels Möller
|
||||
|
||||
Blowfish algorithm contributors:
|
||||
Herbert Valerio Riedel
|
||||
|
|
|
|||
26
Documentation/device-mapper/delay.txt
Normal file
26
Documentation/device-mapper/delay.txt
Normal file
|
|
@ -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
|
||||
aicdb.h*
|
||||
asm
|
||||
asm-offsets.*
|
||||
asm_offsets.*
|
||||
asm-offsets.h
|
||||
asm_offsets.h
|
||||
autoconf.h*
|
||||
bbootsect
|
||||
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;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ host bridges to peripheral buses, and most controllers integrated
|
|||
into system-on-chip platforms. What they usually have in common
|
||||
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
|
||||
registers will still be directly addressible.
|
||||
registers will still be directly addressable.
|
||||
|
||||
Platform devices are given a name, used in driver binding, and a
|
||||
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.
|
||||
|
||||
- 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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Michael Dreher <michael@5dot1.de>
|
|||
Andreas 'randy' Weinberger
|
||||
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
|
||||
|
||||
Ernst Peinlich <e.peinlich@inode.at>
|
||||
|
|
|
|||
68
Documentation/fb/arkfb.txt
Normal file
68
Documentation/fb/arkfb.txt
Normal file
|
|
@ -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.
|
||||
accel - use acceleration engine. Not finished.
|
||||
vmode:x - chooses PowerMacintosh video mode <x>. Depreciated.
|
||||
cmode:x - chooses PowerMacintosh colour mode <x>. Depreciated.
|
||||
vmode:x - chooses PowerMacintosh video mode <x>. Deprecated.
|
||||
cmode:x - chooses PowerMacintosh colour mode <x>. Deprecated.
|
||||
<XxX@X> - selects startup videomode. See modedb.txt for detailed
|
||||
explanation. Default is 640x480x8bpp.
|
||||
|
||||
|
|
|
|||
75
Documentation/fb/deferred_io.txt
Normal file
75
Documentation/fb/deferred_io.txt
Normal file
|
|
@ -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.
|
||||
|
||||
+----------+---------------------------------------------+----------+-------+
|
||||
| | ^ | | |
|
||||
| | ↑ | | |
|
||||
| | |upper_margin | | |
|
||||
| | ･ | | |
|
||||
| | ↓ | | |
|
||||
+----------###############################################----------+-------+
|
||||
| # ^ # | |
|
||||
| # ↑ # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
|
|
@ -238,15 +238,15 @@ vsync length.
|
|||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # ･ # | |
|
||||
| # ↓ # | |
|
||||
+----------###############################################----------+-------+
|
||||
| | ^ | | |
|
||||
| | ↑ | | |
|
||||
| | |lower_margin | | |
|
||||
| | ･ | | |
|
||||
| | ↓ | | |
|
||||
+----------+---------------------------------------------+----------+-------+
|
||||
| | ^ | | |
|
||||
| | ↑ | | |
|
||||
| | |vsync_len | | |
|
||||
| | ･ | | |
|
||||
| | ↓ | | |
|
||||
+----------+---------------------------------------------+----------+-------+
|
||||
|
||||
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.
|
||||
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 :
|
||||
video=imacfb:macbook
|
||||
MacMini :
|
||||
|
|
|
|||
|
|
@ -35,10 +35,12 @@ Supported Features
|
|||
* suspend/resume support
|
||||
* DPMS support
|
||||
|
||||
Text mode is supported even in higher resolutions, but there is limitation
|
||||
to lower pixclocks (maximum between 50-60 MHz, depending 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).
|
||||
Text mode is supported even in higher resolutions, but there is limitation to
|
||||
lower pixclocks (maximum usually between 50-60 MHz, depending on specific
|
||||
hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This
|
||||
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
|
||||
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
|
||||
* text mode broken on S3 Trio64 V2/DX
|
||||
|
||||
|
||||
--
|
||||
Ondrej Zajicek <santiago@crfreenet.org>
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
Introduction
|
||||
|
||||
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
|
||||
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
|
||||
combinations and it seems that it works.
|
||||
The main page is located at <http://sstfb.sourceforge.net>, and if
|
||||
|
|
|
|||
64
Documentation/fb/vt8623fb.txt
Normal file
64
Documentation/fb/vt8623fb.txt
Normal file
|
|
@ -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
|
||||
When: October 2007
|
||||
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.
|
||||
When: December 2006
|
||||
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
|
||||
(temporary transition config option provided until then)
|
||||
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
|
||||
When: Januar 2007
|
||||
When: September 2007
|
||||
Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
|
||||
out of the signal namespace.
|
||||
|
||||
|
|
@ -190,18 +188,10 @@ Who: Jean Delvare <khali@linux-fr.org>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: i2c_adapter.dev
|
||||
i2c_adapter.list
|
||||
What: i2c_adapter.list
|
||||
When: July 2007
|
||||
Why: Superfluous, given i2c_adapter.class_dev:
|
||||
* The "dev" was a stand-in for the physical device node that legacy
|
||||
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.)
|
||||
Why: Superfluous, this list duplicates the one maintained by the driver
|
||||
core.
|
||||
Who: Jean Delvare <khali@linux-fr.org>,
|
||||
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>
|
||||
|
||||
---------------------------
|
||||
|
||||
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 *);
|
||||
void (*d_release)(struct dentry *);
|
||||
void (*d_iput)(struct dentry *, struct inode *);
|
||||
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
||||
|
||||
locking rules:
|
||||
none have BKL
|
||||
|
|
@ -25,6 +26,7 @@ d_compare: no yes no no
|
|||
d_delete: yes no yes no
|
||||
d_release: no no no yes
|
||||
d_iput: no no no yes
|
||||
d_dname: no no no no
|
||||
|
||||
--------------------------- inode_operations ---------------------------
|
||||
prototypes:
|
||||
|
|
@ -52,7 +54,7 @@ ata *);
|
|||
|
||||
locking rules:
|
||||
all may block, none have BKL
|
||||
i_sem(inode)
|
||||
i_mutex(inode)
|
||||
lookup: yes
|
||||
create: yes
|
||||
link: yes (both)
|
||||
|
|
@ -72,7 +74,7 @@ setxattr: yes
|
|||
getxattr: no
|
||||
listxattr: no
|
||||
removexattr: yes
|
||||
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_sem on
|
||||
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
|
||||
victim.
|
||||
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
|
||||
->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
|
||||
in sys_read() and friends.
|
||||
|
||||
->fsync() has i_sem on inode.
|
||||
->fsync() has i_mutex on inode.
|
||||
|
||||
--------------------------- dquot_operations -------------------------------
|
||||
prototypes:
|
||||
|
|
|
|||
|
|
@ -290,7 +290,7 @@ History
|
|||
2.07 More fixes for Warp Server. Now it really works
|
||||
2.08 Creating new files is not so slow on large disks
|
||||
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:
|
||||
|
|
|
|||
|
|
@ -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=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
|
||||
"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
|
||||
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"
|
||||
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
|
||||
them.
|
||||
|
||||
|
|
|
|||
|
|
@ -122,21 +122,22 @@ subdirectory has the entries listed in Table 1-1.
|
|||
|
||||
Table 1-1: Process specific entries in /proc
|
||||
..............................................................................
|
||||
File Content
|
||||
cmdline Command line arguments
|
||||
cpu Current and last cpu in which it was executed (2.4)(smp)
|
||||
cwd Link to the current working directory
|
||||
environ Values of environment variables
|
||||
exe Link to the executable of this process
|
||||
fd Directory, which contains all file descriptors
|
||||
maps Memory maps to executables and library files (2.4)
|
||||
mem Memory held by this process
|
||||
root Link to the root directory of this process
|
||||
stat Process status
|
||||
statm Process memory status information
|
||||
status Process status in human readable form
|
||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||
smaps Extension based on maps, presenting the rss size for each mapped file
|
||||
File Content
|
||||
clear_refs Clears page referenced bits shown in smaps output
|
||||
cmdline Command line arguments
|
||||
cpu Current and last cpu in which it was executed (2.4)(smp)
|
||||
cwd Link to the current working directory
|
||||
environ Values of environment variables
|
||||
exe Link to the executable of this process
|
||||
fd Directory, which contains all file descriptors
|
||||
maps Memory maps to executables and library files (2.4)
|
||||
mem Memory held by this process
|
||||
root Link to the root directory of this process
|
||||
stat Process status
|
||||
statm Process memory status information
|
||||
status Process status in human readable form
|
||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||
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
|
||||
|
|
@ -228,7 +229,7 @@ Table 1-3: Kernel info in /proc
|
|||
mounts Mounted filesystems
|
||||
net Networking info (see text)
|
||||
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)
|
||||
rtc Real time clock
|
||||
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
|
||||
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
|
||||
-----------------------------------------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
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
|
||||
relay_subbufs_consumed(). Any subsequent attempts to write into the
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
individual filesystem implementations. Device drivers have no business
|
||||
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:
|
||||
|
||||
struct dentry_operations {
|
||||
|
|
@ -837,6 +837,7 @@ struct dentry_operations {
|
|||
int (*d_delete)(struct dentry *);
|
||||
void (*d_release)(struct dentry *);
|
||||
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
|
||||
|
|
@ -859,6 +860,26 @@ struct dentry_operations {
|
|||
VFS calls iput(). If you define this method, you must call
|
||||
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
|
||||
of child dentries. Child dentries are basically like files in a
|
||||
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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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. Write the minimum PWM or DAC value to the appropriate control
|
||||
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
|
||||
the control output. See the datasheet for several example circuits for
|
||||
controlling fan speed with the PWM and DAC outputs. The fan speed sensors
|
||||
|
|
|
|||
36
Documentation/hwmon/coretemp
Normal file
36
Documentation/hwmon/coretemp
Normal file
|
|
@ -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:
|
||||
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>
|
||||
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
|
||||
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.
|
||||
|
||||
The fact that the LM83 is only scarcely used can be easily explained.
|
||||
|
|
|
|||
53
Documentation/hwmon/max6650
Normal file
53
Documentation/hwmon/max6650
Normal file
|
|
@ -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.
|
||||
|
||||
Authors:
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||
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/tools/discontinued/47m15x.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
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Prefix: 'smsc47m1'
|
||||
|
|
@ -32,9 +36,10 @@ Description
|
|||
The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
|
||||
contain monitoring and PWM control circuitry for two fans.
|
||||
|
||||
The 47M15x and 47M192 chips contain a full 'hardware monitoring block'
|
||||
in addition to the fan monitoring and control. The hardware monitoring
|
||||
block is not supported by the driver.
|
||||
The LPC47M15x, LPC47M192 and LPC47M292 chips contain a full 'hardware
|
||||
monitoring block' in addition to the fan monitoring and control. The
|
||||
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
|
||||
ID as the 47M15x and 47M192 chips and seems to be compatible.
|
||||
|
|
|
|||
|
|
@ -2,12 +2,13 @@ Kernel driver smsc47m192
|
|||
========================
|
||||
|
||||
Supported chips:
|
||||
* SMSC LPC47M192 and LPC47M997
|
||||
* SMSC LPC47M192, LPC47M15x, LPC47M292 and LPC47M997
|
||||
Prefix: 'smsc47m192'
|
||||
Addresses scanned: I2C 0x2c - 0x2d
|
||||
Datasheet: The datasheet for LPC47M192 is publicly available from
|
||||
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>
|
||||
Special thanks to Jean Delvare for careful checking
|
||||
|
|
@ -18,7 +19,7 @@ Description
|
|||
-----------
|
||||
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Supported chips:
|
|||
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
|
||||
|
||||
Authors:
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||
Bob Dougherty <bobd@stanford.edu>
|
||||
(Some conversion-factor data were contributed by
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ Known problems:
|
|||
by CR[0x49h].
|
||||
- The function of vid and vrm has not been finished, because I'm NOT
|
||||
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
|
||||
need to upgrade to latest (or beta) BIOS. If it does not help please
|
||||
contact us.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Supported adapters:
|
|||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
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>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,8 @@ Supported adapters:
|
|||
* nForce4 MCP-04 10de:0034
|
||||
* nForce4 MCP51 10de:0264
|
||||
* nForce4 MCP55 10de:0368
|
||||
* nForce4 MCP61 10de:03EB
|
||||
* nForce4 MCP65 10de:0446
|
||||
|
||||
Datasheet: not publicly available, but seems to be similar to the
|
||||
AMD-8111 SMBus 2.0 adapter.
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Mark D. Studebaker <mdsxyz123@yahoo.com>
|
|||
- design hints and bug fixes
|
||||
Alexander Maylsh <amalysh@web.de>
|
||||
- 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
|
||||
Robert Zwerus <arzie@dds.nl>
|
||||
- testing for SiS645DX
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Supported adapters:
|
|||
* VIA Technologies, InC. VT82C586B
|
||||
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
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Supported adapters:
|
|||
Datasheet: available on request and under NDA from VIA
|
||||
|
||||
Authors:
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||
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
|
||||
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.
|
||||
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>
|
||||
Greg KH <greg@kroah.com>
|
||||
|
||||
|
|
@ -20,6 +20,10 @@ yours for best results.
|
|||
|
||||
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 typically look like that:
|
||||
#include <linux/module.h>
|
||||
|
|
@ -27,12 +31,10 @@ Technical changes:
|
|||
#include <linux/slab.h>
|
||||
#include <linux/jiffies.h>
|
||||
#include <linux/i2c.h>
|
||||
#include <linux/i2c-isa.h> /* for ISA drivers */
|
||||
#include <linux/hwmon.h> /* for hardware monitoring drivers */
|
||||
#include <linux/hwmon-sysfs.h>
|
||||
#include <linux/hwmon-vid.h> /* if you need VRM support */
|
||||
#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
|
||||
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
|
||||
patch to the Documentation/hwmon/sysfs-interface file.
|
||||
|
||||
* [Attach] For I2C drivers, the attach function should make sure
|
||||
that the adapter's class has I2C_CLASS_HWMON (or whatever class is
|
||||
suitable for your driver), using the following construct:
|
||||
* [Attach] The attach function should make sure that the adapter's
|
||||
class has I2C_CLASS_HWMON (or whatever class is suitable for your
|
||||
driver), using the following construct:
|
||||
if (!(adapter->class & I2C_CLASS_HWMON))
|
||||
return 0;
|
||||
ISA-only drivers of course don't need this.
|
||||
Call i2c_probe() instead of i2c_detect().
|
||||
|
||||
* [Detect] As mentioned earlier, the flags parameter is gone.
|
||||
The type_name and client_name strings are replaced by a single
|
||||
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.
|
||||
It is advised that the labels are given descriptive names such as
|
||||
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
|
||||
slow two-wire protocol (10-400 kHz), but it suffices for many types of
|
||||
devices.
|
||||
slow two-wire protocol (variable speed, up to 400 kHz), with a high speed
|
||||
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
|
||||
modern mainboards have a System Management Bus. There are a lot of
|
||||
devices which can be connected to a SMBus; the most notable are modern
|
||||
memory chips with EEPROM memories and chips for hardware monitoring.
|
||||
SMBus (System Management Bus) is based on the I2C protocol, and is mostly
|
||||
a subset of I2C protocols and signaling. Many I2C devices will work on an
|
||||
SMBus, but some SMBus protocols add semantics beyond what is required to
|
||||
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
|
||||
can simulate the SMBus protocol on plain I2C busses. The reverse is
|
||||
regretfully impossible.
|
||||
Because the SMBus is mostly a subset of the generalized I2C bus, we can
|
||||
use its protocols on many I2C systems. However, there are systems that don't
|
||||
meet both SMBus and I2C electrical constraints; and others which can't
|
||||
implement all the common SMBus protocol semantics or messages.
|
||||
|
||||
|
||||
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
|
||||
of I2C adapters. Each specific adapter driver depends on one algorithm
|
||||
driver.
|
||||
|
||||
A Driver driver (yes, this sounds ridiculous, sorry) contains the general
|
||||
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
|
||||
|
|
@ -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
|
||||
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
|
||||
====================
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
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
|
||||
some things can be done slightly or completely different. Use this as a
|
||||
|
|
@ -29,8 +29,16 @@ static struct i2c_driver foo_driver = {
|
|||
.driver = {
|
||||
.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,
|
||||
.detach_client = foo_detach_client,
|
||||
|
||||
/* these may be used regardless of the driver binding model */
|
||||
.shutdown = foo_shutdown, /* optional */
|
||||
.suspend = foo_suspend, /* 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
|
||||
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
|
||||
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
|
||||
below.
|
||||
|
|
@ -65,16 +74,13 @@ An example structure is below.
|
|||
|
||||
struct foo_data {
|
||||
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. */
|
||||
|
||||
/* 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).
|
||||
It depends of course on the device whether this is really worthwhile
|
||||
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
|
||||
below information */
|
||||
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.
|
||||
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
|
||||
be encapsulated. Also, some chips have both ISA and I2C interfaces, and
|
||||
it useful to abstract from this (only for `sensors' drivers).
|
||||
be encapsulated.
|
||||
|
||||
The below functions are simple examples, and should not be copied
|
||||
literally.
|
||||
|
|
@ -119,28 +124,101 @@ literally.
|
|||
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
|
||||
=====================
|
||||
|
||||
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
|
||||
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
|
||||
|
|
@ -157,13 +235,9 @@ detection algorithm.
|
|||
You do not have to use this parameter interface; but don't try to use
|
||||
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
|
||||
---------------
|
||||
Probing classes (Legacy model)
|
||||
------------------------------
|
||||
|
||||
All parameters are given as lists of unsigned 16-bit integers. Lists are
|
||||
terminated by I2C_CLIENT_END.
|
||||
|
|
@ -210,8 +284,8 @@ Note that you *have* to call the defined variable `normal_i2c',
|
|||
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
|
||||
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.
|
||||
|
||||
|
||||
The detect client function
|
||||
--------------------------
|
||||
The detect client function (Legacy model)
|
||||
-----------------------------------------
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
@ -256,64 +326,20 @@ shortage or i2c_attach_client failing.
|
|||
For now, you can ignore the `flags' parameter. It is there for future use.
|
||||
|
||||
int foo_detect_client(struct i2c_adapter *adapter, int address,
|
||||
unsigned short flags, int kind)
|
||||
int kind)
|
||||
{
|
||||
int err = 0;
|
||||
int i;
|
||||
struct i2c_client *new_client;
|
||||
struct i2c_client *client;
|
||||
struct foo_data *data;
|
||||
const char *client_name = ""; /* For non-`sensors' drivers, put the real
|
||||
name here! */
|
||||
const char *name = "";
|
||||
|
||||
/* Let's see whether this adapter can support what we need.
|
||||
Please substitute the things you need here!
|
||||
For `sensors' drivers, add `! is_isa &&' to the if statement */
|
||||
Please substitute the things you need here! */
|
||||
if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
|
||||
I2C_FUNC_SMBUS_WRITE_BYTE))
|
||||
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
|
||||
client structure, even though we cannot fill it completely yet.
|
||||
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;
|
||||
}
|
||||
|
||||
new_client = &data->client;
|
||||
i2c_set_clientdata(new_client, data);
|
||||
client = &data->client;
|
||||
i2c_set_clientdata(client, data);
|
||||
|
||||
new_client->addr = address;
|
||||
new_client->adapter = adapter;
|
||||
new_client->driver = &foo_driver;
|
||||
new_client->flags = 0;
|
||||
client->addr = address;
|
||||
client->adapter = adapter;
|
||||
client->driver = &foo_driver;
|
||||
|
||||
/* 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. */
|
||||
if (kind < 0) {
|
||||
/* 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;
|
||||
}
|
||||
|
||||
/* SENSORS ONLY START */
|
||||
|
||||
/* Next, specific detection. This is especially important for `sensors'
|
||||
devices. */
|
||||
|
||||
/* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter
|
||||
was used. */
|
||||
if (kind <= 0) {
|
||||
i = foo_read(new_client,FOO_REG_CHIPTYPE);
|
||||
i = foo_read(client, FOO_REG_CHIPTYPE);
|
||||
if (i == FOO_TYPE_1)
|
||||
kind = chip1; /* As defined in the enum */
|
||||
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 */
|
||||
if (kind == chip1) {
|
||||
type_name = "chip1"; /* For /proc entry */
|
||||
client_name = "CHIP 1";
|
||||
name = "chip1";
|
||||
} else if (kind == chip2) {
|
||||
type_name = "chip2"; /* For /proc entry */
|
||||
client_name = "CHIP 2";
|
||||
name = "chip2";
|
||||
}
|
||||
|
||||
/* Reserve the ISA region */
|
||||
if (is_isa)
|
||||
request_region(address,FOO_EXTENT,type_name);
|
||||
|
||||
/* SENSORS ONLY END */
|
||||
|
||||
/* Fill in the remaining client fields. */
|
||||
strcpy(new_client->name,client_name);
|
||||
|
||||
/* SENSORS ONLY BEGIN */
|
||||
strlcpy(client->name, name, I2C_NAME_SIZE);
|
||||
data->type = kind;
|
||||
/* SENSORS ONLY END */
|
||||
|
||||
data->valid = 0; /* Only if you use this field */
|
||||
init_MUTEX(&data->update_lock); /* Only if you use this field */
|
||||
mutex_init(&data->update_lock); /* Only if you use this field */
|
||||
|
||||
/* 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
|
||||
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;
|
||||
|
||||
/* OK, this is not exactly good programming practice, usually. But it is
|
||||
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:
|
||||
kfree(data);
|
||||
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
|
||||
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 err,i;
|
||||
|
||||
/* SENSORS ONLY START */
|
||||
/* Deregister with the `i2c-proc' module. */
|
||||
i2c_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id);
|
||||
/* SENSORS ONLY END */
|
||||
int err;
|
||||
|
||||
/* Try to detach the client from i2c space */
|
||||
if ((err = i2c_detach_client(client)))
|
||||
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));
|
||||
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)
|
||||
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)
|
||||
{
|
||||
int res;
|
||||
printk("foo version %s (%s)\n",FOO_VERSION,FOO_DATE);
|
||||
|
||||
if ((res = i2c_add_driver(&foo_driver))) {
|
||||
printk("foo: Driver registration failed, module not inserted.\n");
|
||||
foo_cleanup();
|
||||
return res;
|
||||
}
|
||||
foo_initialized ++;
|
||||
return 0;
|
||||
}
|
||||
|
||||
void foo_cleanup(void)
|
||||
static void __exit foo_cleanup(void)
|
||||
{
|
||||
if (foo_initialized == 1) {
|
||||
if ((res = i2c_del_driver(&foo_driver))) {
|
||||
printk("foo: Driver registration failed, module not removed.\n");
|
||||
return;
|
||||
}
|
||||
foo_initialized --;
|
||||
}
|
||||
i2c_del_driver(&foo_driver);
|
||||
}
|
||||
|
||||
/* Substitute your own name and email address */
|
||||
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
|
||||
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_exit(foo_cleanup);
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
|
@ -632,110 +602,7 @@ General purpose routines
|
|||
Below all general purpose routines are listed, that were not mentioned
|
||||
before.
|
||||
|
||||
/* This call returns a unique low identifier for each registered adapter,
|
||||
* or -1 if the adapter was not registered.
|
||||
/* This call returns a unique low identifier for each registered adapter.
|
||||
*/
|
||||
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
|
||||
Core code extensions
|
||||
|
||||
Auvo Häkkinen, University of Helsinki Finland
|
||||
Auvo Häkkinen, University of Helsinki Finland
|
||||
LAN OSM code
|
||||
/Proc interface to LAN class
|
||||
Bug fixes
|
||||
Core code extensions
|
||||
|
||||
Taneli Vähäkangas, University of Helsinki Finland
|
||||
Taneli Vähäkangas, University of Helsinki Finland
|
||||
Fixes to i2o_config
|
||||
|
||||
CREDITS
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
----------------------------
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
|
|
@ -133,6 +137,8 @@ Offset Proto Name Meaning
|
|||
022C/4 2.03+ initrd_addr_max Highest legal initrd address
|
||||
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
|
||||
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
|
||||
real value is 4.
|
||||
|
|
@ -177,9 +183,9 @@ filled out, however:
|
|||
a version number. Otherwise, enter 0xFF here.
|
||||
|
||||
Assigned boot loader ids:
|
||||
0 LILO
|
||||
0 LILO (0x00 reserved for pre-2.00 bootloader)
|
||||
1 Loadlin
|
||||
2 bootsect-loader
|
||||
2 bootsect-loader (0x20, all other values reserved)
|
||||
3 SYSLINUX
|
||||
4 EtherBoot
|
||||
5 ELILO
|
||||
|
|
@ -204,6 +210,9 @@ filled out, however:
|
|||
additional data (such as the kernel command line) moved in
|
||||
addition to the real-mode kernel itself.
|
||||
|
||||
The unit is bytes starting with the beginning of the boot
|
||||
sector.
|
||||
|
||||
ramdisk_image, ramdisk_size:
|
||||
If your boot loader has loaded an initial ramdisk (initrd),
|
||||
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
|
||||
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
|
||||
|
||||
|
|
@ -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"
|
||||
below.
|
||||
|
||||
The kernel command line is a null-terminated string currently up to
|
||||
255 characters long, plus the final null. A string that is too long
|
||||
will be automatically truncated by the kernel, a boot loader may allow
|
||||
a longer command line to be passed to permit future kernels to extend
|
||||
this limit.
|
||||
The kernel command line is a null-terminated string. The maximum
|
||||
length can be retrieved from the field cmdline_size. Before protocol
|
||||
version 2.06, the maximum was 255 characters. A string that is too
|
||||
long will be automatically truncated by the kernel.
|
||||
|
||||
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
|
||||
|
|
@ -267,14 +281,54 @@ command line is entered using the following protocol:
|
|||
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
|
||||
|
||||
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
|
||||
0x8000-0x8FFF Stack and heap
|
||||
0x9000-0x90FF Kernel command line
|
||||
When loading below 0x90000, use the entire segment:
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -290,22 +344,33 @@ Such a boot loader should enter the following fields in the header:
|
|||
ramdisk_image = <initrd_address>;
|
||||
ramdisk_size = <initrd_size>;
|
||||
}
|
||||
|
||||
if ( protocol >= 0x0202 && loadflags & 0x01 )
|
||||
heap_end = 0xe000;
|
||||
else
|
||||
heap_end = 0x9800;
|
||||
|
||||
if ( protocol >= 0x0201 ) {
|
||||
heap_end_ptr = 0x9000 - 0x200;
|
||||
heap_end_ptr = heap_end - 0x200;
|
||||
loadflags |= 0x80; /* CAN_USE_HEAP */
|
||||
}
|
||||
|
||||
if ( protocol >= 0x0202 ) {
|
||||
cmd_line_ptr = base_ptr + 0x9000;
|
||||
cmd_line_ptr = base_ptr + heap_end;
|
||||
strcpy(cmd_line_ptr, cmdline);
|
||||
} else {
|
||||
cmd_line_magic = 0xA33F;
|
||||
cmd_line_offset = 0x9000;
|
||||
setup_move_size = 0x9100;
|
||||
cmd_line_offset = heap_end;
|
||||
setup_move_size = heap_end + strlen(cmdline)+1;
|
||||
strcpy(base_ptr+cmd_line_offset, cmdline);
|
||||
}
|
||||
} else {
|
||||
/* Very old kernel */
|
||||
|
||||
heap_end = 0x9800;
|
||||
|
||||
cmd_line_magic = 0xA33F;
|
||||
cmd_line_offset = 0x9000;
|
||||
cmd_line_offset = heap_end;
|
||||
|
||||
/* A very old kernel MUST have its real-mode code
|
||||
loaded at 0x90000 */
|
||||
|
|
@ -313,12 +378,11 @@ Such a boot loader should enter the following fields in the header:
|
|||
if ( base_ptr != 0x90000 ) {
|
||||
/* Copy the real-mode kernel */
|
||||
memcpy(0x90000, base_ptr, (setup_sects+1)*512);
|
||||
/* Copy the command line */
|
||||
memcpy(0x99000, base_ptr+0x9000, 256);
|
||||
|
||||
base_ptr = 0x90000; /* Relocated */
|
||||
}
|
||||
|
||||
strcpy(0x90000+cmd_line_offset, cmdline);
|
||||
|
||||
/* It is recommended to clear memory up to the 32K mark */
|
||||
memset(0x90000 + (setup_sects+1)*512, 0,
|
||||
(64-(setup_sects+1))*512);
|
||||
|
|
@ -364,10 +428,11 @@ conflict with actual kernel options now or in the future.
|
|||
line is parsed.
|
||||
|
||||
mem=<size>
|
||||
<size> is an integer in C notation optionally followed by K, M
|
||||
or G (meaning << 10, << 20 or << 30). This specifies the end
|
||||
of memory to the kernel. This affects the possible placement
|
||||
of an initrd, since an initrd should be placed near end of
|
||||
<size> is an integer in C notation optionally followed by
|
||||
(case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
|
||||
<< 30, << 40, << 50 or << 60). This specifies the 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
|
||||
the bootloader!
|
||||
|
||||
|
|
@ -417,7 +482,7 @@ In our example from above, we would do:
|
|||
|
||||
/* Set up the real-mode kernel stack */
|
||||
_SS = seg;
|
||||
_SP = 0x9000; /* Load SP immediately after loading SS! */
|
||||
_SP = heap_end;
|
||||
|
||||
_DS = _ES = _FS = _GS = seg;
|
||||
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:
|
||||
A 32-bit flat-mode routine *jumped* to immediately after the
|
||||
transition to protected mode, but before the kernel is
|
||||
uncompressed. No segments, except CS, are set up; you should
|
||||
set them up to KERNEL_DS (0x18) yourself.
|
||||
uncompressed. No segments, except CS, are guaranteed to be
|
||||
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
|
||||
that was in this field before your boot loader overwrote it.
|
||||
|
|
|
|||
247
Documentation/ia64/aliasing-test.c
Normal file
247
Documentation/ia64/aliasing-test.c
Normal file
|
|
@ -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.
|
||||
|
||||
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
|
||||
|
||||
This uses copy_from_user(), which implicitly uses a kernel
|
||||
|
|
@ -138,14 +128,20 @@ POTENTIAL ATTRIBUTE ALIASING CASES
|
|||
|
||||
ioremap()
|
||||
|
||||
This returns a kernel identity mapping for use inside the
|
||||
kernel.
|
||||
This returns a mapping for use inside the kernel.
|
||||
|
||||
If the region is in kern_memmap, we should use the attribute
|
||||
specified there. Otherwise, if the EFI memory map reports that
|
||||
the entire granule supports WB, we should use that (granules
|
||||
that are partially reserved or occupied by firmware do not appear
|
||||
in kern_memmap). Otherwise, we should use a UC mapping.
|
||||
specified there.
|
||||
|
||||
If the EFI memory map reports that the entire granule supports
|
||||
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
|
||||
|
||||
|
|
@ -158,7 +154,7 @@ PAST PROBLEM CASES
|
|||
succeed. It may create either WB or UC user mappings, depending
|
||||
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.
|
||||
|
||||
|
|
@ -171,28 +167,25 @@ PAST PROBLEM CASES
|
|||
so it is safe to use WB mappings.
|
||||
|
||||
The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
|
||||
which will use a granule-sized UC mapping covering 0-0xFFFFF. This
|
||||
granule covers some WB-only memory, but since UC is non-speculative,
|
||||
the processor will never generate an uncacheable reference to the
|
||||
WB-only areas unless the driver explicitly touches them.
|
||||
which uses a granule-sized UC mapping. This granule will cover some
|
||||
WB-only memory, but since UC is non-speculative, the processor will
|
||||
never generate an uncacheable reference to the WB-only areas unless
|
||||
the driver explicitly touches them.
|
||||
|
||||
mmap of 0x0-0xFFFFF legacy_mem by "X"
|
||||
|
||||
If the EFI memory map reports this entire range as WB, there
|
||||
is no VGA MMIO hole, and the mmap should fail or be done with
|
||||
a WB mapping.
|
||||
If the EFI memory map reports that the entire range supports the
|
||||
same attributes, we can allow the mmap (and we will prefer WB if
|
||||
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
|
||||
region is a frame buffer or just memory, so I think it's best to
|
||||
just fail this mmap request rather than using a WB mapping. As
|
||||
far as I know, there's no need to map legacy_mem with WB
|
||||
mappings.
|
||||
If EFI reports the range as partly WB and partly UC (as on sx[12]000
|
||||
machines with VGA enabled), we must fail the mmap because there's no
|
||||
safe attribute to use.
|
||||
|
||||
Otherwise, a UC mapping of the entire region is probably safe.
|
||||
The VGA hole means the region will not be in kern_memmap. The
|
||||
HP sx1000 chipset doesn't support UC access to the memory surrounding
|
||||
the VGA hole, but X doesn't need that area anyway and should not
|
||||
reference it.
|
||||
If EFI reports some of the range but not all (as on Intel firmware
|
||||
that doesn't report the VGA frame buffer at all), we should fail the
|
||||
mmap and force the user to map just the specific region of interest.
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
[1] SDM rev 2.2, vol 2, sec 4.4.1.
|
||||
|
|
|
|||
1068
Documentation/ia64/err_inject.txt
Normal file
1068
Documentation/ia64/err_inject.txt
Normal file
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
|
||||
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
|
||||
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
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,3 @@
|
|||
$Id: input-programming.txt,v 1.4 2001/05/04 09:47:14 vojtech Exp $
|
||||
|
||||
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/io.h>
|
||||
|
||||
static struct input_dev *button_dev;
|
||||
|
||||
static void button_interrupt(int irq, void *dummy, struct pt_regs *fp)
|
||||
{
|
||||
input_report_key(&button_dev, BTN_1, inb(BUTTON_PORT) & 1);
|
||||
input_sync(&button_dev);
|
||||
input_report_key(button_dev, BTN_1, inb(BUTTON_PORT) & 1);
|
||||
input_sync(button_dev);
|
||||
}
|
||||
|
||||
static int __init button_init(void)
|
||||
{
|
||||
int error;
|
||||
|
||||
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
|
||||
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
|
||||
return -EBUSY;
|
||||
}
|
||||
|
||||
button_dev.evbit[0] = BIT(EV_KEY);
|
||||
button_dev.keybit[LONG(BTN_0)] = BIT(BTN_0);
|
||||
|
||||
input_register_device(&button_dev);
|
||||
|
||||
button_dev = input_allocate_device();
|
||||
if (!button_dev) {
|
||||
printk(KERN_ERR "button.c: Not enough memory\n");
|
||||
error = -ENOMEM;
|
||||
goto err_free_irq;
|
||||
}
|
||||
|
||||
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)
|
||||
{
|
||||
input_unregister_device(&button_dev);
|
||||
input_unregister_device(button_dev);
|
||||
free_irq(BUTTON_IRQ, button_interrupt);
|
||||
}
|
||||
|
||||
|
|
@ -58,17 +79,18 @@ 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
|
||||
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
|
||||
accepted by this input device. Our example device can only generate EV_KEY type
|
||||
events, and from those only BTN_0 event code. Thus we only set these two
|
||||
bits. We could have used
|
||||
accepted by this input device. Our example device can only generate EV_KEY
|
||||
type events, and from those only BTN_0 event code. Thus we only set these
|
||||
two bits. We could have used
|
||||
|
||||
set_bit(EV_KEY, button_dev.evbit);
|
||||
set_bit(BTN_0, button_dev.keybit);
|
||||
|
||||
as well, but with more than single bits the first approach tends to be
|
||||
shorter.
|
||||
shorter.
|
||||
|
||||
Then the example driver registers the input device structure by calling
|
||||
|
||||
|
|
@ -76,16 +98,15 @@ 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
|
||||
calls device handler modules _connect functions to tell them a new input
|
||||
device has appeared. Because the _connect functions may call kmalloc(,
|
||||
GFP_KERNEL), which can sleep, input_register_device() must not be called
|
||||
from an interrupt or with a spinlock held.
|
||||
device has appeared. input_register_device() may sleep and therefore must
|
||||
not be called from an interrupt or with a spinlock held.
|
||||
|
||||
While in use, the only used function of the driver is
|
||||
|
||||
button_interrupt()
|
||||
|
||||
which upon every interrupt from the button checks its state and reports it
|
||||
via the
|
||||
via the
|
||||
|
||||
input_report_key()
|
||||
|
||||
|
|
@ -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
|
||||
again. To do that, we would add this to our example driver:
|
||||
|
||||
int button_used = 0;
|
||||
|
||||
static int button_open(struct input_dev *dev)
|
||||
{
|
||||
if (button_used++)
|
||||
return 0;
|
||||
|
||||
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
|
||||
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
|
||||
button_used--;
|
||||
return -EBUSY;
|
||||
}
|
||||
|
||||
|
|
@ -131,20 +146,21 @@ static int button_open(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)
|
||||
{
|
||||
...
|
||||
button_dev.open = button_open;
|
||||
button_dev.close = button_close;
|
||||
button_dev->open = button_open;
|
||||
button_dev->close = button_close;
|
||||
...
|
||||
}
|
||||
|
||||
Note the button_used variable - we have to track how many times the open
|
||||
function was called to know when exactly our device stops being used.
|
||||
Note that input core keeps track of number of users for the device and
|
||||
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
|
||||
in case of failure. The close() callback (which is void) must always succeed.
|
||||
|
|
@ -175,7 +191,7 @@ set the corresponding bits and call the
|
|||
|
||||
input_report_rel(struct input_dev *dev, int code, int value)
|
||||
|
||||
function. Events are generated only for nonzero value.
|
||||
function. Events are generated only for nonzero value.
|
||||
|
||||
However EV_ABS requires a little special care. Before calling
|
||||
input_register_device, you have to fill additional fields in the input_dev
|
||||
|
|
@ -187,6 +203,10 @@ the ABS_X axis:
|
|||
button_dev.absfuzz[ABS_X] = 4;
|
||||
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
|
||||
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
|
||||
|
|
@ -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
|
||||
(if it has any).
|
||||
|
||||
1.4 The void *private field
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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()
|
||||
1.4 NBITS(), LONG(), BIT()
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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
|
||||
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
|
||||
device driver. It's a string like 'Generic button device' containing a
|
||||
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.
|
||||
|
||||
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
|
||||
as scancodes. If not all scancodes can be known by autodetection, they may
|
||||
need to be set by userland utilities. The keycode array then is an array
|
||||
used to map from scancodes to input system keycodes. The keycode max will
|
||||
contain the size of the array and keycodesize the size of each entry in it
|
||||
(in bytes).
|
||||
These three fields should be used by input devices that have dense keymaps.
|
||||
The keycode is an array used to map from scancodes to input system keycodes.
|
||||
The keycode max should 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
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -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,
|
||||
*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);
|
||||
{
|
||||
|
|
|
|||
|
|
@ -65,15 +65,15 @@ of buttons, see section 0.3 - Unknown Controllers
|
|||
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.
|
||||
|
||||
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.
|
||||
|
||||
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,
|
||||
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
|
||||
|
|
|
|||
|
|
@ -138,7 +138,8 @@ Code Seq# Include File Comments
|
|||
'm' 00-1F net/irda/irmod.h conflict!
|
||||
'n' 00-7F linux/ncp_fs.h
|
||||
'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' 80-9F user-space parport
|
||||
<mailto:tim@cyberelk.net>
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
I want to thank all who contributed to this project and especially to:
|
||||
(in alphabetical order)
|
||||
|
||||
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
|
||||
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
|
||||
Tester, lots of bugfixes and hints.
|
||||
|
||||
Alan Cox (alan@redhat.com)
|
||||
|
|
@ -11,7 +11,7 @@ Alan Cox (alan@redhat.com)
|
|||
Henner Eisen (eis@baty.hanse.de)
|
||||
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
|
||||
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
|
||||
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
|
||||
contributed by Michael Knigge (imon), Volker Götz (imontty) and
|
||||
contributed by Michael Knigge (imon), Volker Götz (imontty) and
|
||||
Andreas Kool (isdnmon).
|
||||
|
||||
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:
|
||||
|
||||
Thinking Objects Software GmbH
|
||||
Versbacher Röthe 159
|
||||
97078 Würzburg
|
||||
Versbacher Röthe 159
|
||||
97078 Würzburg
|
||||
Tel: +49 931 2877950
|
||||
Fax: +49 931 2877951
|
||||
|
||||
|
|
|
|||
|
|
@ -390,7 +390,7 @@ the execution bit, then just do
|
|||
|
||||
|
||||
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>
|
||||
added executable Jar file support by Kurt Huwig <kurt@iku-netz.de>
|
||||
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ following files:
|
|||
--> filename: Makefile
|
||||
KERNELDIR := /lib/modules/`uname -r`/build
|
||||
all::
|
||||
$(MAKE) -C $KERNELDIR M=`pwd` $@
|
||||
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
|
||||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
|
|
|
|||
|
|
@ -236,7 +236,7 @@
|
|||
|
||||
* Title: "Design and Implementation of the Second Extended
|
||||
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
|
||||
Keywords: ext2, linux fs history, inode, directory, link, devices,
|
||||
VFS, physical structure, performance, benchmarks, ext2fs library,
|
||||
|
|
|
|||
|
|
@ -64,6 +64,7 @@ parameter is applicable:
|
|||
GENERIC_TIME The generic timeofday code is enabled.
|
||||
NFS Appropriate NFS support is enabled.
|
||||
OSS OSS sound support is enabled.
|
||||
PV_OPS A paravirtualized kernel
|
||||
PARIDE The ParIDE subsystem is enabled.
|
||||
PARISC The PA-RISC architecture 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>]
|
||||
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]
|
||||
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
|
||||
See Documentation/ide.txt.
|
||||
|
||||
idle= [HW]
|
||||
Format: idle=poll or idle=halt
|
||||
idle= [X86]
|
||||
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 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
|
||||
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]
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
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]
|
||||
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-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.
|
||||
|
||||
vdso= [IA-32,SH]
|
||||
vdso=2: enable compat VDSO (default with COMPAT_VDSO)
|
||||
vdso=1: enable VDSO (default)
|
||||
vdso=0: disable VDSO mapping
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ CONTENTS
|
|||
8. Kprobes Example
|
||||
9. Jprobes Example
|
||||
10. Kretprobes Example
|
||||
Appendix A: The kprobes debugfs interface
|
||||
|
||||
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
|
||||
of times it returns, registering a return probe on that function may
|
||||
produce undesirable results. 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.
|
||||
produce undesirable results. In such a case, a line:
|
||||
kretprobe BUG!: Processing kretprobe d000000000041aa8 @ c00000000004f48c
|
||||
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
|
||||
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-users.cs.umn.edu/~boutcher/kprobes/
|
||||
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
|
||||
.
|
||||
kref_put(data, data_release);
|
||||
kref_put(&data->refcount, data_release);
|
||||
}
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
Buddha.
|
||||
|
||||
Jens Schönfeld february 19th, 1997
|
||||
Jens Schönfeld february 19th, 1997
|
||||
updated may 27th, 1997
|
||||
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
|
||||
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
||||
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
|
||||
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.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
|
||||
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
|
||||
For arrays with data redundancy (i.e. not raid0, linear, faulty,
|
||||
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
|
||||
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
|
||||
The point at which resync should start. If no resync is needed,
|
||||
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).
|
||||
|
||||
|
||||
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'
|
||||
directory as new directories named
|
||||
dev-XXX
|
||||
|
|
@ -412,6 +399,35 @@ also have
|
|||
Note that the numbers are 'bit' numbers, not 'block' numbers.
|
||||
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
|
||||
personality module that manages it.
|
||||
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
|
||||
protocol built on top of the Generic NETLINK transport mechanism. The exact
|
||||
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'.
|
||||
|
||||
* Security Module API
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
This is the 6pack-mini-HOWTO, written by
|
||||
|
||||
Andreas Könsgen DG3KQ
|
||||
Andreas Könsgen DG3KQ
|
||||
Internet: ajk@iehk.rwth-aachen.de
|
||||
AMPR-net: dg3kq@db0pra.ampr.org
|
||||
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
|
||||
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
|
||||
==================================================
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ You can find the latest version of this document at
|
|||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
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
|
||||
|
||||
-----------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
|
||||
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
|
||||
|
||||
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
Loading…
Add table
Reference in a new issue