Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into avr32-arch
This commit is contained in:
commit
b92efa9abf
4
.mailmap
4
.mailmap
|
@ -92,6 +92,7 @@ Rudolf Marek <R.Marek@sh.cvut.cz>
|
|||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
Sam Ravnborg <sam@mars.ravnborg.org>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
|
@ -100,6 +101,7 @@ Tejun Heo <htejun@gmail.com>
|
|||
Thomas Graf <tgraf@suug.ch>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
|
|
3
CREDITS
3
CREDITS
|
@ -2166,7 +2166,6 @@ D: Initial implementation of VC's, pty's and select()
|
|||
|
||||
N: Pavel Machek
|
||||
E: pavel@ucw.cz
|
||||
E: pavel@suse.cz
|
||||
D: Softcursor for vga, hypertech cdrom support, vcsa bugfix, nbd
|
||||
D: sun4/330 port, capabilities for elf, speedup for rm on ext2, USB,
|
||||
D: work on suspend-to-ram/disk, killing duplicates from ioctl32
|
||||
|
@ -3739,7 +3738,7 @@ S: 93149 Nittenau
|
|||
S: Germany
|
||||
|
||||
N: Gertjan van Wingerde
|
||||
E: gwingerde@home.nl
|
||||
E: gwingerde@gmail.com
|
||||
D: Ralink rt2x00 WLAN driver
|
||||
D: Minix V2 file-system
|
||||
D: Misc fixes
|
||||
|
|
61
Documentation/ABI/testing/ima_policy
Normal file
61
Documentation/ABI/testing/ima_policy
Normal file
|
@ -0,0 +1,61 @@
|
|||
What: security/ima/policy
|
||||
Date: May 2008
|
||||
Contact: Mimi Zohar <zohar@us.ibm.com>
|
||||
Description:
|
||||
The Trusted Computing Group(TCG) runtime Integrity
|
||||
Measurement Architecture(IMA) maintains a list of hash
|
||||
values of executables and other sensitive system files
|
||||
loaded into the run-time of this system. At runtime,
|
||||
the policy can be constrained based on LSM specific data.
|
||||
Policies are loaded into the securityfs file ima/policy
|
||||
by opening the file, writing the rules one at a time and
|
||||
then closing the file. The new policy takes effect after
|
||||
the file ima/policy is closed.
|
||||
|
||||
rule format: action [condition ...]
|
||||
|
||||
action: measure | dont_measure
|
||||
condition:= base | lsm
|
||||
base: [[func=] [mask=] [fsmagic=] [uid=]]
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
|
||||
base: func:= [BPRM_CHECK][FILE_MMAP][INODE_PERMISSION]
|
||||
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
uid:= decimal value
|
||||
lsm: are LSM specific
|
||||
|
||||
default policy:
|
||||
# PROC_SUPER_MAGIC
|
||||
dont_measure fsmagic=0x9fa0
|
||||
# SYSFS_MAGIC
|
||||
dont_measure fsmagic=0x62656572
|
||||
# DEBUGFS_MAGIC
|
||||
dont_measure fsmagic=0x64626720
|
||||
# TMPFS_MAGIC
|
||||
dont_measure fsmagic=0x01021994
|
||||
# SECURITYFS_MAGIC
|
||||
dont_measure fsmagic=0x73636673
|
||||
|
||||
measure func=BPRM_CHECK
|
||||
measure func=FILE_MMAP mask=MAY_EXEC
|
||||
measure func=INODE_PERM mask=MAY_READ uid=0
|
||||
|
||||
The default policy measures all executables in bprm_check,
|
||||
all files mmapped executable in file_mmap, and all files
|
||||
open for read by root in inode_permission.
|
||||
|
||||
Examples of LSM specific definitions:
|
||||
|
||||
SELinux:
|
||||
# SELINUX_MAGIC
|
||||
dont_measure fsmagic=0xF97CFF8C
|
||||
|
||||
dont_measure obj_type=var_log_t
|
||||
dont_measure obj_type=auditd_log_t
|
||||
measure subj_user=system_u func=INODE_PERM mask=MAY_READ
|
||||
measure subj_role=system_r func=INODE_PERM mask=MAY_READ
|
||||
|
||||
Smack:
|
||||
measure subj_user=_ func=INODE_PERM mask=MAY_READ
|
|
@ -1,3 +1,46 @@
|
|||
What: /sys/bus/pci/drivers/.../bind
|
||||
Date: December 2003
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
Writing a device location to this file will cause
|
||||
the driver to attempt to bind to the device found at
|
||||
this location. This is useful for overriding default
|
||||
bindings. The format for the location is: DDDD:BB:DD.F.
|
||||
That is Domain:Bus:Device.Function and is the same as
|
||||
found in /sys/bus/pci/devices/. For example:
|
||||
# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
|
||||
(Note: kernels before 2.6.28 may require echo -n).
|
||||
|
||||
What: /sys/bus/pci/drivers/.../unbind
|
||||
Date: December 2003
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
Writing a device location to this file will cause the
|
||||
driver to attempt to unbind from the device found at
|
||||
this location. This may be useful when overriding default
|
||||
bindings. The format for the location is: DDDD:BB:DD.F.
|
||||
That is Domain:Bus:Device.Function and is the same as
|
||||
found in /sys/bus/pci/devices/. For example:
|
||||
# echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
|
||||
(Note: kernels before 2.6.28 may require echo -n).
|
||||
|
||||
What: /sys/bus/pci/drivers/.../new_id
|
||||
Date: December 2003
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
Writing a device ID to this file will attempt to
|
||||
dynamically add a new device ID to a PCI device driver.
|
||||
This may allow the driver to support more hardware than
|
||||
was included in the driver's static device ID support
|
||||
table at compile time. The format for the device ID is:
|
||||
VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID,
|
||||
Device ID, Subsystem Vendor ID, Subsystem Device ID,
|
||||
Class, Class Mask, and Private Driver Data. The Vendor ID
|
||||
and Device ID fields are required, the rest are optional.
|
||||
Upon successfully adding an ID, the driver will probe
|
||||
for the device and attempt to bind to it. For example:
|
||||
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
|
||||
|
||||
What: /sys/bus/pci/devices/.../vpd
|
||||
Date: February 2008
|
||||
Contact: Ben Hutchings <bhutchings@solarflare.com>
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/firmware/memmap/
|
||||
Date: June 2008
|
||||
Contact: Bernhard Walle <bwalle@suse.de>
|
||||
Contact: Bernhard Walle <bernhard.walle@gmx.de>
|
||||
Description:
|
||||
On all platforms, the firmware provides a memory map which the
|
||||
kernel reads. The resources from that memory map are registered
|
||||
|
|
|
@ -33,10 +33,12 @@ o Gnu make 3.79.1 # make --version
|
|||
o binutils 2.12 # ld -v
|
||||
o util-linux 2.10o # fdformat --version
|
||||
o module-init-tools 0.9.10 # depmod -V
|
||||
o e2fsprogs 1.29 # tune2fs
|
||||
o e2fsprogs 1.41.4 # e2fsck -V
|
||||
o jfsutils 1.1.3 # fsck.jfs -V
|
||||
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
|
||||
o xfsprogs 2.6.0 # xfs_db -V
|
||||
o squashfs-tools 4.0 # mksquashfs -version
|
||||
o btrfs-progs 0.18 # btrfsck
|
||||
o pcmciautils 004 # pccardctl -V
|
||||
o quota-tools 3.09 # quota -V
|
||||
o PPP 2.4.0 # pppd --version
|
||||
|
|
|
@ -483,17 +483,25 @@ values. To do the latter, you can stick the following in your .emacs file:
|
|||
(* (max steps 1)
|
||||
c-basic-offset)))
|
||||
|
||||
(add-hook 'c-mode-common-hook
|
||||
(lambda ()
|
||||
;; Add kernel style
|
||||
(c-add-style
|
||||
"linux-tabs-only"
|
||||
'("linux" (c-offsets-alist
|
||||
(arglist-cont-nonempty
|
||||
c-lineup-gcc-asm-reg
|
||||
c-lineup-arglist-tabs-only))))))
|
||||
|
||||
(add-hook 'c-mode-hook
|
||||
(lambda ()
|
||||
(let ((filename (buffer-file-name)))
|
||||
;; Enable kernel mode for the appropriate files
|
||||
(when (and filename
|
||||
(string-match "~/src/linux-trees" filename))
|
||||
(string-match (expand-file-name "~/src/linux-trees")
|
||||
filename))
|
||||
(setq indent-tabs-mode t)
|
||||
(c-set-style "linux")
|
||||
(c-set-offset 'arglist-cont-nonempty
|
||||
'(c-lineup-gcc-asm-reg
|
||||
c-lineup-arglist-tabs-only))))))
|
||||
(c-set-style "linux-tabs-only")))))
|
||||
|
||||
This will make emacs go better with the kernel coding style for C
|
||||
files below ~/src/linux-trees.
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
This document describes the DMA API. For a more gentle introduction
|
||||
phrased in terms of the pci_ equivalents (and actual examples) see
|
||||
DMA-mapping.txt
|
||||
Documentation/PCI/PCI-DMA-mapping.txt.
|
||||
|
||||
This API is split into two pieces. Part I describes the API and the
|
||||
corresponding pci_ API. Part II describes the extensions to the API
|
||||
|
|
|
@ -6,13 +6,14 @@
|
|||
# To add a new book the only step required is to add the book to the
|
||||
# list of DOCBOOKS.
|
||||
|
||||
DOCBOOKS := z8530book.xml mcabook.xml \
|
||||
DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
|
||||
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
||||
procfs-guide.xml writing_usb_driver.xml networking.xml \
|
||||
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
|
||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
mac80211.xml debugobjects.xml sh.xml regulator.xml
|
||||
mac80211.xml debugobjects.xml sh.xml regulator.xml \
|
||||
alsa-driver-api.xml writing-an-alsa-driver.xml
|
||||
|
||||
###
|
||||
# The build process is as follows (targets):
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
|
||||
|
||||
<book>
|
||||
<?dbhtml filename="index.html">
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<!-- ****************************************************** -->
|
||||
<!-- Header -->
|
||||
<!-- ****************************************************** -->
|
||||
<book id="ALSA-Driver-API">
|
||||
<bookinfo>
|
||||
<title>The ALSA Driver API</title>
|
||||
|
||||
|
@ -35,6 +35,8 @@
|
|||
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter><title>Management of Cards and Devices</title>
|
||||
<sect1><title>Card Management</title>
|
||||
!Esound/core/init.c
|
||||
|
@ -71,6 +73,10 @@
|
|||
!Esound/pci/ac97/ac97_codec.c
|
||||
!Esound/pci/ac97/ac97_pcm.c
|
||||
</sect1>
|
||||
<sect1><title>Virtual Master Control API</title>
|
||||
!Esound/core/vmaster.c
|
||||
!Iinclude/sound/control.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter><title>MIDI API</title>
|
||||
<sect1><title>Raw MIDI API</title>
|
||||
|
@ -88,6 +94,9 @@
|
|||
<chapter><title>Miscellaneous Functions</title>
|
||||
<sect1><title>Hardware-Dependent Devices API</title>
|
||||
!Esound/core/hwdep.c
|
||||
</sect1>
|
||||
<sect1><title>Jack Abstraction Layer API</title>
|
||||
!Esound/core/jack.c
|
||||
</sect1>
|
||||
<sect1><title>ISA DMA Helpers</title>
|
||||
!Esound/core/isadma.c
|
418
Documentation/DocBook/device-drivers.tmpl
Normal file
418
Documentation/DocBook/device-drivers.tmpl
Normal file
|
@ -0,0 +1,418 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="LinuxDriversAPI">
|
||||
<bookinfo>
|
||||
<title>Linux Device Drivers</title>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is free software; you can redistribute
|
||||
it and/or modify it under the terms of the GNU General Public
|
||||
License as published by the Free Software Foundation; either
|
||||
version 2 of the License, or (at your option) any later
|
||||
version.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This program is distributed in the hope that it will be
|
||||
useful, but WITHOUT ANY WARRANTY; without even the implied
|
||||
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||||
See the GNU General Public License for more details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You should have received a copy of the GNU General Public
|
||||
License along with this program; if not, write to the Free
|
||||
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
||||
MA 02111-1307 USA
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more details see the file COPYING in the source
|
||||
distribution of Linux.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="Basics">
|
||||
<title>Driver Basics</title>
|
||||
<sect1><title>Driver Entry and Exit points</title>
|
||||
!Iinclude/linux/init.h
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Atomic and pointer manipulation</title>
|
||||
!Iarch/x86/include/asm/atomic_32.h
|
||||
!Iarch/x86/include/asm/unaligned.h
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Delaying, scheduling, and timer routines</title>
|
||||
!Iinclude/linux/sched.h
|
||||
!Ekernel/sched.c
|
||||
!Ekernel/timer.c
|
||||
</sect1>
|
||||
<sect1><title>High-resolution timers</title>
|
||||
!Iinclude/linux/ktime.h
|
||||
!Iinclude/linux/hrtimer.h
|
||||
!Ekernel/hrtimer.c
|
||||
</sect1>
|
||||
<sect1><title>Workqueues and Kevents</title>
|
||||
!Ekernel/workqueue.c
|
||||
</sect1>
|
||||
<sect1><title>Internal Functions</title>
|
||||
!Ikernel/exit.c
|
||||
!Ikernel/signal.c
|
||||
!Iinclude/linux/kthread.h
|
||||
!Ekernel/kthread.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Kernel objects manipulation</title>
|
||||
<!--
|
||||
X!Iinclude/linux/kobject.h
|
||||
-->
|
||||
!Elib/kobject.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Kernel utility functions</title>
|
||||
!Iinclude/linux/kernel.h
|
||||
!Ekernel/printk.c
|
||||
!Ekernel/panic.c
|
||||
!Ekernel/sys.c
|
||||
!Ekernel/rcupdate.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Device Resource Management</title>
|
||||
!Edrivers/base/devres.c
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="devdrivers">
|
||||
<title>Device drivers infrastructure</title>
|
||||
<sect1><title>Device Drivers Base</title>
|
||||
<!--
|
||||
X!Iinclude/linux/device.h
|
||||
-->
|
||||
!Edrivers/base/driver.c
|
||||
!Edrivers/base/core.c
|
||||
!Edrivers/base/class.c
|
||||
!Edrivers/base/firmware_class.c
|
||||
!Edrivers/base/transport_class.c
|
||||
<!-- Cannot be included, because
|
||||
attribute_container_add_class_device_adapter
|
||||
and attribute_container_classdev_to_container
|
||||
exceed allowed 44 characters maximum
|
||||
X!Edrivers/base/attribute_container.c
|
||||
-->
|
||||
!Edrivers/base/sys.c
|
||||
<!--
|
||||
X!Edrivers/base/interface.c
|
||||
-->
|
||||
!Edrivers/base/platform.c
|
||||
!Edrivers/base/bus.c
|
||||
</sect1>
|
||||
<sect1><title>Device Drivers Power Management</title>
|
||||
!Edrivers/base/power/main.c
|
||||
</sect1>
|
||||
<sect1><title>Device Drivers ACPI Support</title>
|
||||
<!-- Internal functions only
|
||||
X!Edrivers/acpi/sleep/main.c
|
||||
X!Edrivers/acpi/sleep/wakeup.c
|
||||
X!Edrivers/acpi/motherboard.c
|
||||
X!Edrivers/acpi/bus.c
|
||||
-->
|
||||
!Edrivers/acpi/scan.c
|
||||
!Idrivers/acpi/scan.c
|
||||
<!-- No correct structured comments
|
||||
X!Edrivers/acpi/pci_bind.c
|
||||
-->
|
||||
</sect1>
|
||||
<sect1><title>Device drivers PnP support</title>
|
||||
!Idrivers/pnp/core.c
|
||||
<!-- No correct structured comments
|
||||
X!Edrivers/pnp/system.c
|
||||
-->
|
||||
!Edrivers/pnp/card.c
|
||||
!Idrivers/pnp/driver.c
|
||||
!Edrivers/pnp/manager.c
|
||||
!Edrivers/pnp/support.c
|
||||
</sect1>
|
||||
<sect1><title>Userspace IO devices</title>
|
||||
!Edrivers/uio/uio.c
|
||||
!Iinclude/linux/uio_driver.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="parportdev">
|
||||
<title>Parallel Port Devices</title>
|
||||
!Iinclude/linux/parport.h
|
||||
!Edrivers/parport/ieee1284.c
|
||||
!Edrivers/parport/share.c
|
||||
!Idrivers/parport/daisy.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="message_devices">
|
||||
<title>Message-based devices</title>
|
||||
<sect1><title>Fusion message devices</title>
|
||||
!Edrivers/message/fusion/mptbase.c
|
||||
!Idrivers/message/fusion/mptbase.c
|
||||
!Edrivers/message/fusion/mptscsih.c
|
||||
!Idrivers/message/fusion/mptscsih.c
|
||||
!Idrivers/message/fusion/mptctl.c
|
||||
!Idrivers/message/fusion/mptspi.c
|
||||
!Idrivers/message/fusion/mptfc.c
|
||||
!Idrivers/message/fusion/mptlan.c
|
||||
</sect1>
|
||||
<sect1><title>I2O message devices</title>
|
||||
!Iinclude/linux/i2o.h
|
||||
!Idrivers/message/i2o/core.h
|
||||
!Edrivers/message/i2o/iop.c
|
||||
!Idrivers/message/i2o/iop.c
|
||||
!Idrivers/message/i2o/config-osm.c
|
||||
!Edrivers/message/i2o/exec-osm.c
|
||||
!Idrivers/message/i2o/exec-osm.c
|
||||
!Idrivers/message/i2o/bus-osm.c
|
||||
!Edrivers/message/i2o/device.c
|
||||
!Idrivers/message/i2o/device.c
|
||||
!Idrivers/message/i2o/driver.c
|
||||
!Idrivers/message/i2o/pci.c
|
||||
!Idrivers/message/i2o/i2o_block.c
|
||||
!Idrivers/message/i2o/i2o_scsi.c
|
||||
!Idrivers/message/i2o/i2o_proc.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="snddev">
|
||||
<title>Sound Devices</title>
|
||||
!Iinclude/sound/core.h
|
||||
!Esound/sound_core.c
|
||||
!Iinclude/sound/pcm.h
|
||||
!Esound/core/pcm.c
|
||||
!Esound/core/device.c
|
||||
!Esound/core/info.c
|
||||
!Esound/core/rawmidi.c
|
||||
!Esound/core/sound.c
|
||||
!Esound/core/memory.c
|
||||
!Esound/core/pcm_memory.c
|
||||
!Esound/core/init.c
|
||||
!Esound/core/isadma.c
|
||||
!Esound/core/control.c
|
||||
!Esound/core/pcm_lib.c
|
||||
!Esound/core/hwdep.c
|
||||
!Esound/core/pcm_native.c
|
||||
!Esound/core/memalloc.c
|
||||
<!-- FIXME: Removed for now since no structured comments in source
|
||||
X!Isound/sound_firmware.c
|
||||
-->
|
||||
</chapter>
|
||||
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Iinclude/linux/serial_core.h
|
||||
!Edrivers/serial/serial_core.c
|
||||
!Edrivers/serial/8250.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="fbdev">
|
||||
<title>Frame Buffer Library</title>
|
||||
|
||||
<para>
|
||||
The frame buffer drivers depend heavily on four data structures.
|
||||
These structures are declared in include/linux/fb.h. They are
|
||||
fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs.
|
||||
The last three can be made available to and from userland.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
fb_info defines the current state of a particular video card.
|
||||
Inside fb_info, there exists a fb_ops structure which is a
|
||||
collection of needed functions to make fbdev and fbcon work.
|
||||
fb_info is only visible to the kernel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
fb_var_screeninfo is used to describe the features of a video card
|
||||
that are user defined. With fb_var_screeninfo, things such as
|
||||
depth and the resolution may be defined.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The next structure is fb_fix_screeninfo. This defines the
|
||||
properties of a card that are created when a mode is set and can't
|
||||
be changed otherwise. A good example of this is the start of the
|
||||
frame buffer memory. This "locks" the address of the frame buffer
|
||||
memory, so that it cannot be changed or moved.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The last structure is fb_monospecs. In the old API, there was
|
||||
little importance for fb_monospecs. This allowed for forbidden things
|
||||
such as setting a mode of 800x600 on a fix frequency monitor. With
|
||||
the new API, fb_monospecs prevents such things, and if used
|
||||
correctly, can prevent a monitor from being cooked. fb_monospecs
|
||||
will not be useful until kernels 2.5.x.
|
||||
</para>
|
||||
|
||||
<sect1><title>Frame Buffer Memory</title>
|
||||
!Edrivers/video/fbmem.c
|
||||
</sect1>
|
||||
<!--
|
||||
<sect1><title>Frame Buffer Console</title>
|
||||
X!Edrivers/video/console/fbcon.c
|
||||
</sect1>
|
||||
-->
|
||||
<sect1><title>Frame Buffer Colormap</title>
|
||||
!Edrivers/video/fbcmap.c
|
||||
</sect1>
|
||||
<!-- FIXME:
|
||||
drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment
|
||||
out until somebody adds docs. KAO
|
||||
<sect1><title>Frame Buffer Generic Functions</title>
|
||||
X!Idrivers/video/fbgen.c
|
||||
</sect1>
|
||||
KAO -->
|
||||
<sect1><title>Frame Buffer Video Mode Database</title>
|
||||
!Idrivers/video/modedb.c
|
||||
!Edrivers/video/modedb.c
|
||||
</sect1>
|
||||
<sect1><title>Frame Buffer Macintosh Video Mode Database</title>
|
||||
!Edrivers/video/macmodes.c
|
||||
</sect1>
|
||||
<sect1><title>Frame Buffer Fonts</title>
|
||||
<para>
|
||||
Refer to the file drivers/video/console/fonts.c for more information.
|
||||
</para>
|
||||
<!-- FIXME: Removed for now since no structured comments in source
|
||||
X!Idrivers/video/console/fonts.c
|
||||
-->
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="input_subsystem">
|
||||
<title>Input Subsystem</title>
|
||||
!Iinclude/linux/input.h
|
||||
!Edrivers/input/input.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>
|
||||
|
||||
<chapter id="i2c">
|
||||
<title>I<superscript>2</superscript>C and SMBus Subsystem</title>
|
||||
|
||||
<para>
|
||||
I<superscript>2</superscript>C (or without fancy typography, "I2C")
|
||||
is an acronym for the "Inter-IC" bus, a simple bus protocol which is
|
||||
widely used where low data rate communications suffice.
|
||||
Since it's also a licensed trademark, some vendors use another
|
||||
name (such as "Two-Wire Interface", TWI) for the same bus.
|
||||
I2C only needs two signals (SCL for clock, SDA for data), conserving
|
||||
board real estate and minimizing signal quality issues.
|
||||
Most I2C devices use seven bit addresses, and bus speeds of up
|
||||
to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
|
||||
found wide use.
|
||||
I2C is a multi-master bus; open drain signaling is used to
|
||||
arbitrate between masters, as well as to handshake and to
|
||||
synchronize clocks from slower clients.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Linux I2C programming interfaces support only the master
|
||||
side of bus interactions, not the slave side.
|
||||
The programming interface is structured around two kinds of driver,
|
||||
and two kinds of device.
|
||||
An I2C "Adapter Driver" abstracts the controller hardware; it binds
|
||||
to a physical device (perhaps a PCI device or platform_device) and
|
||||
exposes a <structname>struct i2c_adapter</structname> representing
|
||||
each I2C bus segment it manages.
|
||||
On each I2C bus segment will be I2C devices represented by a
|
||||
<structname>struct i2c_client</structname>. Those devices will
|
||||
be bound to a <structname>struct i2c_driver</structname>,
|
||||
which should follow the standard Linux driver model.
|
||||
(At this writing, a legacy model is more widely used.)
|
||||
There are functions to perform various I2C protocol operations; at
|
||||
this writing all such functions are usable only from task context.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The System Management Bus (SMBus) is a sibling protocol. Most SMBus
|
||||
systems are also I2C conformant. The electrical constraints are
|
||||
tighter for SMBus, and it standardizes particular protocol messages
|
||||
and idioms. Controllers that support I2C can also support most
|
||||
SMBus operations, but SMBus controllers don't support all the protocol
|
||||
options that an I2C controller will.
|
||||
There are functions to perform various SMBus protocol operations,
|
||||
either using I2C primitives or by issuing SMBus commands to
|
||||
i2c_adapter devices which don't support those I2C operations.
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/i2c.h
|
||||
!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
|
||||
!Edrivers/i2c/i2c-core.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
|
@ -440,6 +440,7 @@ desc->chip->end();
|
|||
used in the generic IRQ layer.
|
||||
</para>
|
||||
!Iinclude/linux/irq.h
|
||||
!Iinclude/linux/interrupt.h
|
||||
</chapter>
|
||||
|
||||
<chapter id="pubfunctions">
|
||||
|
|
|
@ -38,58 +38,6 @@
|
|||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="Basics">
|
||||
<title>Driver Basics</title>
|
||||
<sect1><title>Driver Entry and Exit points</title>
|
||||
!Iinclude/linux/init.h
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Atomic and pointer manipulation</title>
|
||||
!Iarch/x86/include/asm/atomic_32.h
|
||||
!Iarch/x86/include/asm/unaligned.h
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Delaying, scheduling, and timer routines</title>
|
||||
!Iinclude/linux/sched.h
|
||||
!Ekernel/sched.c
|
||||
!Ekernel/timer.c
|
||||
</sect1>
|
||||
<sect1><title>High-resolution timers</title>
|
||||
!Iinclude/linux/ktime.h
|
||||
!Iinclude/linux/hrtimer.h
|
||||
!Ekernel/hrtimer.c
|
||||
</sect1>
|
||||
<sect1><title>Workqueues and Kevents</title>
|
||||
!Ekernel/workqueue.c
|
||||
</sect1>
|
||||
<sect1><title>Internal Functions</title>
|
||||
!Ikernel/exit.c
|
||||
!Ikernel/signal.c
|
||||
!Iinclude/linux/kthread.h
|
||||
!Ekernel/kthread.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Kernel objects manipulation</title>
|
||||
<!--
|
||||
X!Iinclude/linux/kobject.h
|
||||
-->
|
||||
!Elib/kobject.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Kernel utility functions</title>
|
||||
!Iinclude/linux/kernel.h
|
||||
!Ekernel/printk.c
|
||||
!Ekernel/panic.c
|
||||
!Ekernel/sys.c
|
||||
!Ekernel/rcupdate.c
|
||||
</sect1>
|
||||
|
||||
<sect1><title>Device Resource Management</title>
|
||||
!Edrivers/base/devres.c
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="adt">
|
||||
<title>Data Types</title>
|
||||
<sect1><title>Doubly Linked Lists</title>
|
||||
|
@ -298,62 +246,6 @@ X!Earch/x86/kernel/mca_32.c
|
|||
!Ikernel/acct.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="devdrivers">
|
||||
<title>Device drivers infrastructure</title>
|
||||
<sect1><title>Device Drivers Base</title>
|
||||
<!--
|
||||
X!Iinclude/linux/device.h
|
||||
-->
|
||||
!Edrivers/base/driver.c
|
||||
!Edrivers/base/core.c
|
||||
!Edrivers/base/class.c
|
||||
!Edrivers/base/firmware_class.c
|
||||
!Edrivers/base/transport_class.c
|
||||
<!-- Cannot be included, because
|
||||
attribute_container_add_class_device_adapter
|
||||
and attribute_container_classdev_to_container
|
||||
exceed allowed 44 characters maximum
|
||||
X!Edrivers/base/attribute_container.c
|
||||
-->
|
||||
!Edrivers/base/sys.c
|
||||
<!--
|
||||
X!Edrivers/base/interface.c
|
||||
-->
|
||||
!Edrivers/base/platform.c
|
||||
!Edrivers/base/bus.c
|
||||
</sect1>
|
||||
<sect1><title>Device Drivers Power Management</title>
|
||||
!Edrivers/base/power/main.c
|
||||
</sect1>
|
||||
<sect1><title>Device Drivers ACPI Support</title>
|
||||
<!-- Internal functions only
|
||||
X!Edrivers/acpi/sleep/main.c
|
||||
X!Edrivers/acpi/sleep/wakeup.c
|
||||
X!Edrivers/acpi/motherboard.c
|
||||
X!Edrivers/acpi/bus.c
|
||||
-->
|
||||
!Edrivers/acpi/scan.c
|
||||
!Idrivers/acpi/scan.c
|
||||
<!-- No correct structured comments
|
||||
X!Edrivers/acpi/pci_bind.c
|
||||
-->
|
||||
</sect1>
|
||||
<sect1><title>Device drivers PnP support</title>
|
||||
!Idrivers/pnp/core.c
|
||||
<!-- No correct structured comments
|
||||
X!Edrivers/pnp/system.c
|
||||
-->
|
||||
!Edrivers/pnp/card.c
|
||||
!Idrivers/pnp/driver.c
|
||||
!Edrivers/pnp/manager.c
|
||||
!Edrivers/pnp/support.c
|
||||
</sect1>
|
||||
<sect1><title>Userspace IO devices</title>
|
||||
!Edrivers/uio/uio.c
|
||||
!Iinclude/linux/uio_driver.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="blkdev">
|
||||
<title>Block Devices</title>
|
||||
!Eblock/blk-core.c
|
||||
|
@ -381,275 +273,6 @@ X!Edrivers/pnp/system.c
|
|||
!Edrivers/char/misc.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="parportdev">
|
||||
<title>Parallel Port Devices</title>
|
||||
!Iinclude/linux/parport.h
|
||||
!Edrivers/parport/ieee1284.c
|
||||
!Edrivers/parport/share.c
|
||||
!Idrivers/parport/daisy.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="message_devices">
|
||||
<title>Message-based devices</title>
|
||||
<sect1><title>Fusion message devices</title>
|
||||
!Edrivers/message/fusion/mptbase.c
|
||||
!Idrivers/message/fusion/mptbase.c
|
||||
!Edrivers/message/fusion/mptscsih.c
|
||||
!Idrivers/message/fusion/mptscsih.c
|
||||
!Idrivers/message/fusion/mptctl.c
|
||||
!Idrivers/message/fusion/mptspi.c
|
||||
!Idrivers/message/fusion/mptfc.c
|
||||
!Idrivers/message/fusion/mptlan.c
|
||||
</sect1>
|
||||
<sect1><title>I2O message devices</title>
|
||||
!Iinclude/linux/i2o.h
|
||||
!Idrivers/message/i2o/core.h
|
||||
!Edrivers/message/i2o/iop.c
|
||||
!Idrivers/message/i2o/iop.c
|
||||
!Idrivers/message/i2o/config-osm.c
|
||||
!Edrivers/message/i2o/exec-osm.c
|
||||
!Idrivers/message/i2o/exec-osm.c
|
||||
!Idrivers/message/i2o/bus-osm.c
|
||||
!Edrivers/message/i2o/device.c
|
||||
!Idrivers/message/i2o/device.c
|
||||
!Idrivers/message/i2o/driver.c
|
||||
!Idrivers/message/i2o/pci.c
|
||||
!Idrivers/message/i2o/i2o_block.c
|
||||
!Idrivers/message/i2o/i2o_scsi.c
|
||||
!Idrivers/message/i2o/i2o_proc.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="snddev">
|
||||
<title>Sound Devices</title>
|
||||
!Iinclude/sound/core.h
|
||||
!Esound/sound_core.c
|
||||
!Iinclude/sound/pcm.h
|
||||
!Esound/core/pcm.c
|
||||
!Esound/core/device.c
|
||||
!Esound/core/info.c
|
||||
!Esound/core/rawmidi.c
|
||||
!Esound/core/sound.c
|
||||
!Esound/core/memory.c
|
||||
!Esound/core/pcm_memory.c
|
||||
!Esound/core/init.c
|
||||
!Esound/core/isadma.c
|
||||
!Esound/core/control.c
|
||||
!Esound/core/pcm_lib.c
|
||||
!Esound/core/hwdep.c
|
||||
!Esound/core/pcm_native.c
|
||||
!Esound/core/memalloc.c
|
||||
<!-- FIXME: Removed for now since no structured comments in source
|
||||
X!Isound/sound_firmware.c
|
||||
-->
|
||||
</chapter>
|
||||
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Iinclude/linux/serial_core.h
|
||||
!Edrivers/serial/serial_core.c
|
||||
!Edrivers/serial/8250.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="fbdev">
|
||||
<title>Frame Buffer Library</title>
|
||||
|
||||
<para>
|
||||
The frame buffer drivers depend heavily on four data structures.
|
||||
These structures are declared in include/linux/fb.h. They are
|
||||
fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs.
|
||||
The last three can be made available to and from userland.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
fb_info defines the current state of a particular video card.
|
||||
Inside fb_info, there exists a fb_ops structure which is a
|
||||
collection of needed functions to make fbdev and fbcon work.
|
||||
fb_info is only visible to the kernel.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
fb_var_screeninfo is used to describe the features of a video card
|
||||
that are user defined. With fb_var_screeninfo, things such as
|
||||
depth and the resolution may be defined.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The next structure is fb_fix_screeninfo. This defines the
|
||||
properties of a card that are created when a mode is set and can't
|
||||
be changed otherwise. A good example of this is the start of the
|
||||
frame buffer memory. This "locks" the address of the frame buffer
|
||||
memory, so that it cannot be changed or moved.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The last structure is fb_monospecs. In the old API, there was
|
||||
little importance for fb_monospecs. This allowed for forbidden things
|
||||
such as setting a mode of 800x600 on a fix frequency monitor. With
|
||||
the new API, fb_monospecs prevents such things, and if used
|
||||
correctly, can prevent a monitor from being cooked. fb_monospecs
|
||||
will not be useful until kernels 2.5.x.
|
||||
</para>
|
||||
|
||||
<sect1><title>Frame Buffer Memory</title>
|
||||
!Edrivers/video/fbmem.c
|
||||
</sect1>
|
||||
<!--
|
||||
<sect1><title>Frame Buffer Console</title>
|
||||
X!Edrivers/video/console/fbcon.c
|
||||
</sect1>
|
||||
-->
|
||||
<sect1><title>Frame Buffer Colormap</title>
|
||||
!Edrivers/video/fbcmap.c
|
||||
</sect1>
|
||||
<!-- FIXME:
|
||||
drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment
|
||||
out until somebody adds docs. KAO
|
||||
<sect1><title>Frame Buffer Generic Functions</title>
|
||||
X!Idrivers/video/fbgen.c
|
||||
</sect1>
|
||||
KAO -->
|
||||
<sect1><title>Frame Buffer Video Mode Database</title>
|
||||
!Idrivers/video/modedb.c
|
||||
!Edrivers/video/modedb.c
|
||||
</sect1>
|
||||
<sect1><title>Frame Buffer Macintosh Video Mode Database</title>
|
||||
!Edrivers/video/macmodes.c
|
||||
</sect1>
|
||||
<sect1><title>Frame Buffer Fonts</title>
|
||||
<para>
|
||||
Refer to the file drivers/video/console/fonts.c for more information.
|
||||
</para>
|
||||
<!-- FIXME: Removed for now since no structured comments in source
|
||||
X!Idrivers/video/console/fonts.c
|
||||
-->
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="input_subsystem">
|
||||
<title>Input Subsystem</title>
|
||||
!Iinclude/linux/input.h
|
||||
!Edrivers/input/input.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>
|
||||
|
||||
<chapter id="i2c">
|
||||
<title>I<superscript>2</superscript>C and SMBus Subsystem</title>
|
||||
|
||||
<para>
|
||||
I<superscript>2</superscript>C (or without fancy typography, "I2C")
|
||||
is an acronym for the "Inter-IC" bus, a simple bus protocol which is
|
||||
widely used where low data rate communications suffice.
|
||||
Since it's also a licensed trademark, some vendors use another
|
||||
name (such as "Two-Wire Interface", TWI) for the same bus.
|
||||
I2C only needs two signals (SCL for clock, SDA for data), conserving
|
||||
board real estate and minimizing signal quality issues.
|
||||
Most I2C devices use seven bit addresses, and bus speeds of up
|
||||
to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
|
||||
found wide use.
|
||||
I2C is a multi-master bus; open drain signaling is used to
|
||||
arbitrate between masters, as well as to handshake and to
|
||||
synchronize clocks from slower clients.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Linux I2C programming interfaces support only the master
|
||||
side of bus interactions, not the slave side.
|
||||
The programming interface is structured around two kinds of driver,
|
||||
and two kinds of device.
|
||||
An I2C "Adapter Driver" abstracts the controller hardware; it binds
|
||||
to a physical device (perhaps a PCI device or platform_device) and
|
||||
exposes a <structname>struct i2c_adapter</structname> representing
|
||||
each I2C bus segment it manages.
|
||||
On each I2C bus segment will be I2C devices represented by a
|
||||
<structname>struct i2c_client</structname>. Those devices will
|
||||
be bound to a <structname>struct i2c_driver</structname>,
|
||||
which should follow the standard Linux driver model.
|
||||
(At this writing, a legacy model is more widely used.)
|
||||
There are functions to perform various I2C protocol operations; at
|
||||
this writing all such functions are usable only from task context.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The System Management Bus (SMBus) is a sibling protocol. Most SMBus
|
||||
systems are also I2C conformant. The electrical constraints are
|
||||
tighter for SMBus, and it standardizes particular protocol messages
|
||||
and idioms. Controllers that support I2C can also support most
|
||||
SMBus operations, but SMBus controllers don't support all the protocol
|
||||
options that an I2C controller will.
|
||||
There are functions to perform various SMBus protocol operations,
|
||||
either using I2C primitives or by issuing SMBus commands to
|
||||
i2c_adapter devices which don't support those I2C operations.
|
||||
</para>
|
||||
|
||||
!Iinclude/linux/i2c.h
|
||||
!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
|
||||
!Edrivers/i2c/i2c-core.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="clk">
|
||||
<title>Clock Framework</title>
|
||||
|
||||
|
|
|
@ -17,8 +17,7 @@
|
|||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2007</year>
|
||||
<year>2008</year>
|
||||
<year>2007-2009</year>
|
||||
<holder>Johannes Berg</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -165,8 +164,8 @@ usage should require reading the full document.
|
|||
!Pinclude/net/mac80211.h Frame format
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Alignment issues</title>
|
||||
<para>TBD</para>
|
||||
<title>Packet alignment</title>
|
||||
!Pnet/mac80211/rx.c Packet alignment
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Calling into mac80211 from interrupts</title>
|
||||
|
@ -223,6 +222,11 @@ usage should require reading the full document.
|
|||
!Finclude/net/mac80211.h ieee80211_key_flags
|
||||
</chapter>
|
||||
|
||||
<chapter id="powersave">
|
||||
<title>Powersave support</title>
|
||||
!Pinclude/net/mac80211.h Powersave support
|
||||
</chapter>
|
||||
|
||||
<chapter id="qos">
|
||||
<title>Multiple queues and QoS support</title>
|
||||
<para>TBD</para>
|
||||
|
|
|
@ -41,6 +41,19 @@ GPL version 2.
|
|||
</abstract>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.8</revnumber>
|
||||
<date>2008-12-24</date>
|
||||
<authorinitials>hjk</authorinitials>
|
||||
<revremark>Added name attributes in mem and portio sysfs directories.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.7</revnumber>
|
||||
<date>2008-12-23</date>
|
||||
<authorinitials>hjk</authorinitials>
|
||||
<revremark>Added generic platform drivers and offset attribute.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.6</revnumber>
|
||||
<date>2008-12-05</date>
|
||||
|
@ -297,10 +310,17 @@ interested in translating it, please email me
|
|||
appear if the size of the mapping is not 0.
|
||||
</para>
|
||||
<para>
|
||||
Each <filename>mapX/</filename> directory contains two read-only files
|
||||
that show start address and size of the memory:
|
||||
Each <filename>mapX/</filename> directory contains four read-only files
|
||||
that show attributes of the memory:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>name</filename>: A string identifier for this mapping. This
|
||||
is optional, the string can be empty. Drivers can set this to make it
|
||||
easier for userspace to find the correct mapping.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>addr</filename>: The address of memory that can be mapped.
|
||||
|
@ -312,6 +332,16 @@ interested in translating it, please email me
|
|||
pointed to by addr.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>offset</filename>: The offset, in bytes, that has to be
|
||||
added to the pointer returned by <function>mmap()</function> to get
|
||||
to the actual device memory. This is important if the device's memory
|
||||
is not page aligned. Remember that pointers returned by
|
||||
<function>mmap()</function> are always page aligned, so it is good
|
||||
style to always add this offset.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
|
@ -350,10 +380,17 @@ offset = N * getpagesize();
|
|||
<filename>/sys/class/uio/uioX/portio/</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Each <filename>portX/</filename> directory contains three read-only
|
||||
files that show start, size, and type of the port region:
|
||||
Each <filename>portX/</filename> directory contains four read-only
|
||||
files that show name, start, size, and type of the port region:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>name</filename>: A string identifier for this port region.
|
||||
The string is optional and can be empty. Drivers can set it to make it
|
||||
easier for userspace to find a certain port region.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>start</filename>: The first port of this region.
|
||||
|
@ -594,6 +631,78 @@ framework to set up sysfs files for this region. Simply leave it alone.
|
|||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="using_uio_pdrv">
|
||||
<title>Using uio_pdrv for platform devices</title>
|
||||
<para>
|
||||
In many cases, UIO drivers for platform devices can be handled in a
|
||||
generic way. In the same place where you define your
|
||||
<varname>struct platform_device</varname>, you simply also implement
|
||||
your interrupt handler and fill your
|
||||
<varname>struct uio_info</varname>. A pointer to this
|
||||
<varname>struct uio_info</varname> is then used as
|
||||
<varname>platform_data</varname> for your platform device.
|
||||
</para>
|
||||
<para>
|
||||
You also need to set up an array of <varname>struct resource</varname>
|
||||
containing addresses and sizes of your memory mappings. This
|
||||
information is passed to the driver using the
|
||||
<varname>.resource</varname> and <varname>.num_resources</varname>
|
||||
elements of <varname>struct platform_device</varname>.
|
||||
</para>
|
||||
<para>
|
||||
You now have to set the <varname>.name</varname> element of
|
||||
<varname>struct platform_device</varname> to
|
||||
<varname>"uio_pdrv"</varname> to use the generic UIO platform device
|
||||
driver. This driver will fill the <varname>mem[]</varname> array
|
||||
according to the resources given, and register the device.
|
||||
</para>
|
||||
<para>
|
||||
The advantage of this approach is that you only have to edit a file
|
||||
you need to edit anyway. You do not have to create an extra driver.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="using_uio_pdrv_genirq">
|
||||
<title>Using uio_pdrv_genirq for platform devices</title>
|
||||
<para>
|
||||
Especially in embedded devices, you frequently find chips where the
|
||||
irq pin is tied to its own dedicated interrupt line. In such cases,
|
||||
where you can be really sure the interrupt is not shared, we can take
|
||||
the concept of <varname>uio_pdrv</varname> one step further and use a
|
||||
generic interrupt handler. That's what
|
||||
<varname>uio_pdrv_genirq</varname> does.
|
||||
</para>
|
||||
<para>
|
||||
The setup for this driver is the same as described above for
|
||||
<varname>uio_pdrv</varname>, except that you do not implement an
|
||||
interrupt handler. The <varname>.handler</varname> element of
|
||||
<varname>struct uio_info</varname> must remain
|
||||
<varname>NULL</varname>. The <varname>.irq_flags</varname> element
|
||||
must not contain <varname>IRQF_SHARED</varname>.
|
||||
</para>
|
||||
<para>
|
||||
You will set the <varname>.name</varname> element of
|
||||
<varname>struct platform_device</varname> to
|
||||
<varname>"uio_pdrv_genirq"</varname> to use this driver.
|
||||
</para>
|
||||
<para>
|
||||
The generic interrupt handler of <varname>uio_pdrv_genirq</varname>
|
||||
will simply disable the interrupt line using
|
||||
<function>disable_irq_nosync()</function>. After doing its work,
|
||||
userspace can reenable the interrupt by writing 0x00000001 to the UIO
|
||||
device file. The driver already implements an
|
||||
<function>irq_control()</function> to make this possible, you must not
|
||||
implement your own.
|
||||
</para>
|
||||
<para>
|
||||
Using <varname>uio_pdrv_genirq</varname> not only saves a few lines of
|
||||
interrupt handler code. You also do not need to know anything about
|
||||
the chip's internal registers to create the kernel part of the driver.
|
||||
All you need to know is the irq number of the pin the chip is
|
||||
connected to.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="userspace_driver" xreflabel="Writing a driver in user space">
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
|
||||
|
||||
<book>
|
||||
<?dbhtml filename="index.html">
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<!-- ****************************************************** -->
|
||||
<!-- Header -->
|
||||
<!-- ****************************************************** -->
|
||||
<book id="Writing-an-ALSA-Driver">
|
||||
<bookinfo>
|
||||
<title>Writing an ALSA Driver</title>
|
||||
<author>
|
||||
|
@ -492,9 +492,9 @@
|
|||
}
|
||||
|
||||
/* (2) */
|
||||
card = snd_card_new(index[dev], id[dev], THIS_MODULE, 0);
|
||||
if (card == NULL)
|
||||
return -ENOMEM;
|
||||
err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
|
||||
if (err < 0)
|
||||
return err;
|
||||
|
||||
/* (3) */
|
||||
err = snd_mychip_create(card, pci, &chip);
|
||||
|
@ -590,8 +590,9 @@
|
|||
<programlisting>
|
||||
<![CDATA[
|
||||
struct snd_card *card;
|
||||
int err;
|
||||
....
|
||||
card = snd_card_new(index[dev], id[dev], THIS_MODULE, 0);
|
||||
err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
@ -809,26 +810,28 @@
|
|||
|
||||
<para>
|
||||
As mentioned above, to create a card instance, call
|
||||
<function>snd_card_new()</function>.
|
||||
<function>snd_card_create()</function>.
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
struct snd_card *card;
|
||||
card = snd_card_new(index, id, module, extra_size);
|
||||
int err;
|
||||
err = snd_card_create(index, id, module, extra_size, &card);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The function takes four arguments, the card-index number, the
|
||||
The function takes five arguments, the card-index number, the
|
||||
id string, the module pointer (usually
|
||||
<constant>THIS_MODULE</constant>),
|
||||
and the size of extra-data space. The last argument is used to
|
||||
the size of extra-data space, and the pointer to return the
|
||||
card instance. The extra_size argument is used to
|
||||
allocate card->private_data for the
|
||||
chip-specific data. Note that these data
|
||||
are allocated by <function>snd_card_new()</function>.
|
||||
are allocated by <function>snd_card_create()</function>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
@ -915,15 +918,16 @@
|
|||
</para>
|
||||
|
||||
<section id="card-management-chip-specific-snd-card-new">
|
||||
<title>1. Allocating via <function>snd_card_new()</function>.</title>
|
||||
<title>1. Allocating via <function>snd_card_create()</function>.</title>
|
||||
<para>
|
||||
As mentioned above, you can pass the extra-data-length
|
||||
to the 4th argument of <function>snd_card_new()</function>, i.e.
|
||||
to the 4th argument of <function>snd_card_create()</function>, i.e.
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
card = snd_card_new(index[dev], id[dev], THIS_MODULE, sizeof(struct mychip));
|
||||
err = snd_card_create(index[dev], id[dev], THIS_MODULE,
|
||||
sizeof(struct mychip), &card);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
@ -952,8 +956,8 @@
|
|||
|
||||
<para>
|
||||
After allocating a card instance via
|
||||
<function>snd_card_new()</function> (with
|
||||
<constant>NULL</constant> on the 4th arg), call
|
||||
<function>snd_card_create()</function> (with
|
||||
<constant>0</constant> on the 4th arg), call
|
||||
<function>kzalloc()</function>.
|
||||
|
||||
<informalexample>
|
||||
|
@ -961,7 +965,7 @@
|
|||
<![CDATA[
|
||||
struct snd_card *card;
|
||||
struct mychip *chip;
|
||||
card = snd_card_new(index[dev], id[dev], THIS_MODULE, NULL);
|
||||
err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
|
||||
.....
|
||||
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
|
||||
]]>
|
||||
|
@ -5750,8 +5754,9 @@ struct _snd_pcm_runtime {
|
|||
....
|
||||
struct snd_card *card;
|
||||
struct mychip *chip;
|
||||
int err;
|
||||
....
|
||||
card = snd_card_new(index[dev], id[dev], THIS_MODULE, NULL);
|
||||
err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
|
||||
....
|
||||
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
|
||||
....
|
||||
|
@ -5763,7 +5768,7 @@ struct _snd_pcm_runtime {
|
|||
</informalexample>
|
||||
|
||||
When you created the chip data with
|
||||
<function>snd_card_new()</function>, it's anyway accessible
|
||||
<function>snd_card_create()</function>, it's anyway accessible
|
||||
via <structfield>private_data</structfield> field.
|
||||
|
||||
<informalexample>
|
||||
|
@ -5775,9 +5780,10 @@ struct _snd_pcm_runtime {
|
|||
....
|
||||
struct snd_card *card;
|
||||
struct mychip *chip;
|
||||
int err;
|
||||
....
|
||||
card = snd_card_new(index[dev], id[dev], THIS_MODULE,
|
||||
sizeof(struct mychip));
|
||||
err = snd_card_create(index[dev], id[dev], THIS_MODULE,
|
||||
sizeof(struct mychip), &card);
|
||||
....
|
||||
chip = card->private_data;
|
||||
....
|
|
@ -1,6 +1,6 @@
|
|||
[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
|
||||
superseded by the functionality provided by the PCI DMA
|
||||
interface (see Documentation/DMA-mapping.txt). They continue
|
||||
superseded by the functionality provided by the PCI DMA interface
|
||||
(see Documentation/PCI/PCI-DMA-mapping.txt). They continue
|
||||
to be documented below for historical purposes, but new code
|
||||
must not use them. --davidm 00/12/12 ]
|
||||
|
||||
|
|
|
@ -93,7 +93,7 @@ the PCI Express Port Bus driver from loading a service driver.
|
|||
|
||||
int pcie_port_service_register(struct pcie_port_service_driver *new)
|
||||
|
||||
This API replaces the Linux Driver Model's pci_module_init API. A
|
||||
This API replaces the Linux Driver Model's pci_register_driver API. A
|
||||
service driver should always calls pcie_port_service_register at
|
||||
module init. Note that after service driver being loaded, calls
|
||||
such as pci_enable_device(dev) and pci_set_master(dev) are no longer
|
||||
|
|
|
@ -298,3 +298,15 @@ over a rather long period of time, but improvements are always welcome!
|
|||
|
||||
Note that, rcu_assign_pointer() and rcu_dereference() relate to
|
||||
SRCU just as they do to other forms of RCU.
|
||||
|
||||
15. The whole point of call_rcu(), synchronize_rcu(), and friends
|
||||
is to wait until all pre-existing readers have finished before
|
||||
carrying out some otherwise-destructive operation. It is
|
||||
therefore critically important to -first- remove any path
|
||||
that readers can follow that could be affected by the
|
||||
destructive operation, and -only- -then- invoke call_rcu(),
|
||||
synchronize_rcu(), or friends.
|
||||
|
||||
Because these primitives only wait for pre-existing readers,
|
||||
it is the caller's responsibility to guarantee safety to
|
||||
any subsequent readers.
|
||||
|
|
|
@ -186,8 +186,9 @@ a virtual address mapping (unlike the earlier scheme of virtual address
|
|||
do not have a corresponding kernel virtual address space mapping) and
|
||||
low-memory pages.
|
||||
|
||||
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
|
||||
aspects and mapping of scatter gather lists, and support for 64 bit PCI.
|
||||
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
|
||||
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
|
||||
for 64 bit PCI.
|
||||
|
||||
Special handling is required only for cases where i/o needs to happen on
|
||||
pages at physical memory addresses beyond what the device can support. In these
|
||||
|
@ -953,14 +954,14 @@ elevator_allow_merge_fn called whenever the block layer determines
|
|||
results in some sort of conflict internally,
|
||||
this hook allows it to do that.
|
||||
|
||||
elevator_dispatch_fn fills the dispatch queue with ready requests.
|
||||
elevator_dispatch_fn* fills the dispatch queue with ready requests.
|
||||
I/O schedulers are free to postpone requests by
|
||||
not filling the dispatch queue unless @force
|
||||
is non-zero. Once dispatched, I/O schedulers
|
||||
are not allowed to manipulate the requests -
|
||||
they belong to generic dispatch queue.
|
||||
|
||||
elevator_add_req_fn called to add a new request into the scheduler
|
||||
elevator_add_req_fn* called to add a new request into the scheduler
|
||||
|
||||
elevator_queue_empty_fn returns true if the merge queue is empty.
|
||||
Drivers shouldn't use this, but rather check
|
||||
|
@ -990,7 +991,7 @@ elevator_activate_req_fn Called when device driver first sees a request.
|
|||
elevator_deactivate_req_fn Called when device driver decides to delay
|
||||
a request by requeueing it.
|
||||
|
||||
elevator_init_fn
|
||||
elevator_init_fn*
|
||||
elevator_exit_fn Allocate and free any elevator specific storage
|
||||
for a queue.
|
||||
|
||||
|
|
63
Documentation/block/queue-sysfs.txt
Normal file
63
Documentation/block/queue-sysfs.txt
Normal file
|
@ -0,0 +1,63 @@
|
|||
Queue sysfs files
|
||||
=================
|
||||
|
||||
This text file will detail the queue files that are located in the sysfs tree
|
||||
for each block device. Note that stacked devices typically do not export
|
||||
any settings, since their queue merely functions are a remapping target.
|
||||
These files are the ones found in the /sys/block/xxx/queue/ directory.
|
||||
|
||||
Files denoted with a RO postfix are readonly and the RW postfix means
|
||||
read-write.
|
||||
|
||||
hw_sector_size (RO)
|
||||
-------------------
|
||||
This is the hardware sector size of the device, in bytes.
|
||||
|
||||
max_hw_sectors_kb (RO)
|
||||
----------------------
|
||||
This is the maximum number of kilobytes supported in a single data transfer.
|
||||
|
||||
max_sectors_kb (RW)
|
||||
-------------------
|
||||
This is the maximum number of kilobytes that the block layer will allow
|
||||
for a filesystem request. Must be smaller than or equal to the maximum
|
||||
size allowed by the hardware.
|
||||
|
||||
nomerges (RW)
|
||||
-------------
|
||||
This enables the user to disable the lookup logic involved with IO merging
|
||||
requests in the block layer. Merging may still occur through a direct
|
||||
1-hit cache, since that comes for (almost) free. The IO scheduler will not
|
||||
waste cycles doing tree/hash lookups for merges if nomerges is 1. Defaults
|
||||
to 0, enabling all merges.
|
||||
|
||||
nr_requests (RW)
|
||||
----------------
|
||||
This controls how many requests may be allocated in the block layer for
|
||||
read or write requests. Note that the total allocated number may be twice
|
||||
this amount, since it applies only to reads or writes (not the accumulated
|
||||
sum).
|
||||
|
||||
read_ahead_kb (RW)
|
||||
------------------
|
||||
Maximum number of kilobytes to read-ahead for filesystems on this block
|
||||
device.
|
||||
|
||||
rq_affinity (RW)
|
||||
----------------
|
||||
If this option is enabled, the block layer will migrate request completions
|
||||
to the CPU that originally submitted the request. For some workloads
|
||||
this provides a significant reduction in CPU cycles due to caching effects.
|
||||
|
||||
scheduler (RW)
|
||||
--------------
|
||||
When read, this file will display the current and available IO schedulers
|
||||
for this block device. The currently active IO scheduler will be enclosed
|
||||
in [] brackets. Writing an IO scheduler name to this file will switch
|
||||
control of this block device to that new IO scheduler. Note that writing
|
||||
an IO scheduler name to this file will attempt to load that IO scheduler
|
||||
module, if it isn't already present in the system.
|
||||
|
||||
|
||||
|
||||
Jens Axboe <jens.axboe@oracle.com>, February 2009
|
|
@ -35,9 +35,3 @@ noop anticipatory deadline [cfq]
|
|||
# echo anticipatory > /sys/block/hda/queue/scheduler
|
||||
# cat /sys/block/hda/queue/scheduler
|
||||
noop [anticipatory] deadline cfq
|
||||
|
||||
Each io queue has a set of io scheduler tunables associated with it. These
|
||||
tunables control how the io scheduler works. You can find these entries
|
||||
in:
|
||||
|
||||
/sys/block/<device>/queue/iosched
|
||||
|
|
|
@ -252,10 +252,8 @@ cgroup file system directories.
|
|||
When a task is moved from one cgroup to another, it gets a new
|
||||
css_set pointer - if there's an already existing css_set with the
|
||||
desired collection of cgroups then that group is reused, else a new
|
||||
css_set is allocated. Note that the current implementation uses a
|
||||
linear search to locate an appropriate existing css_set, so isn't
|
||||
very efficient. A future version will use a hash table for better
|
||||
performance.
|
||||
css_set is allocated. The appropriate existing css_set is located by
|
||||
looking into a hash table.
|
||||
|
||||
To allow access from a cgroup to the css_sets (and hence tasks)
|
||||
that comprise it, a set of cg_cgroup_link objects form a lattice;
|
||||
|
|
|
@ -142,7 +142,7 @@ into the rest of the kernel, none in performance critical paths:
|
|||
- in fork and exit, to attach and detach a task from its cpuset.
|
||||
- in sched_setaffinity, to mask the requested CPUs by what's
|
||||
allowed in that tasks cpuset.
|
||||
- in sched.c migrate_all_tasks(), to keep migrating tasks within
|
||||
- in sched.c migrate_live_tasks(), to keep migrating tasks within
|
||||
the CPUs allowed by their cpuset, if possible.
|
||||
- in the mbind and set_mempolicy system calls, to mask the requested
|
||||
Memory Nodes by what's allowed in that tasks cpuset.
|
||||
|
@ -175,6 +175,10 @@ files describing that cpuset:
|
|||
- mem_exclusive flag: is memory placement exclusive?
|
||||
- mem_hardwall flag: is memory allocation hardwalled
|
||||
- memory_pressure: measure of how much paging pressure in cpuset
|
||||
- memory_spread_page flag: if set, spread page cache evenly on allowed nodes
|
||||
- memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
|
||||
- sched_load_balance flag: if set, load balance within CPUs on that cpuset
|
||||
- sched_relax_domain_level: the searching range when migrating tasks
|
||||
|
||||
In addition, the root cpuset only has the following file:
|
||||
- memory_pressure_enabled flag: compute memory_pressure?
|
||||
|
@ -252,7 +256,7 @@ is causing.
|
|||
|
||||
This is useful both on tightly managed systems running a wide mix of
|
||||
submitted jobs, which may choose to terminate or re-prioritize jobs that
|
||||
are trying to use more memory than allowed on the nodes assigned them,
|
||||
are trying to use more memory than allowed on the nodes assigned to them,
|
||||
and with tightly coupled, long running, massively parallel scientific
|
||||
computing jobs that will dramatically fail to meet required performance
|
||||
goals if they start to use more memory than allowed to them.
|
||||
|
@ -378,7 +382,7 @@ as cpusets and sched_setaffinity.
|
|||
The algorithmic cost of load balancing and its impact on key shared
|
||||
kernel data structures such as the task list increases more than
|
||||
linearly with the number of CPUs being balanced. So the scheduler
|
||||
has support to partition the systems CPUs into a number of sched
|
||||
has support to partition the systems CPUs into a number of sched
|
||||
domains such that it only load balances within each sched domain.
|
||||
Each sched domain covers some subset of the CPUs in the system;
|
||||
no two sched domains overlap; some CPUs might not be in any sched
|
||||
|
@ -485,17 +489,22 @@ of CPUs allowed to a cpuset having 'sched_load_balance' enabled.
|
|||
The internal kernel cpuset to scheduler interface passes from the
|
||||
cpuset code to the scheduler code a partition of the load balanced
|
||||
CPUs in the system. This partition is a set of subsets (represented
|
||||
as an array of cpumask_t) of CPUs, pairwise disjoint, that cover all
|
||||
the CPUs that must be load balanced.
|
||||
as an array of struct cpumask) of CPUs, pairwise disjoint, that cover
|
||||
all the CPUs that must be load balanced.
|
||||
|
||||
Whenever the 'sched_load_balance' flag changes, or CPUs come or go
|
||||
from a cpuset with this flag enabled, or a cpuset with this flag
|
||||
enabled is removed, the cpuset code builds a new such partition and
|
||||
passes it to the scheduler sched domain setup code, to have the sched
|
||||
domains rebuilt as necessary.
|
||||
The cpuset code builds a new such partition and passes it to the
|
||||
scheduler sched domain setup code, to have the sched domains rebuilt
|
||||
as necessary, whenever:
|
||||
- the 'sched_load_balance' flag of a cpuset with non-empty CPUs changes,
|
||||
- or CPUs come or go from a cpuset with this flag enabled,
|
||||
- or 'sched_relax_domain_level' value of a cpuset with non-empty CPUs
|
||||
and with this flag enabled changes,
|
||||
- or a cpuset with non-empty CPUs and with this flag enabled is removed,
|
||||
- or a cpu is offlined/onlined.
|
||||
|
||||
This partition exactly defines what sched domains the scheduler should
|
||||
setup - one sched domain for each element (cpumask_t) in the partition.
|
||||
setup - one sched domain for each element (struct cpumask) in the
|
||||
partition.
|
||||
|
||||
The scheduler remembers the currently active sched domain partitions.
|
||||
When the scheduler routine partition_sched_domains() is invoked from
|
||||
|
@ -559,7 +568,7 @@ domain, the largest value among those is used. Be careful, if one
|
|||
requests 0 and others are -1 then 0 is used.
|
||||
|
||||
Note that modifying this file will have both good and bad effects,
|
||||
and whether it is acceptable or not will be depend on your situation.
|
||||
and whether it is acceptable or not depends on your situation.
|
||||
Don't modify this file if you are not sure.
|
||||
|
||||
If your situation is:
|
||||
|
@ -600,19 +609,15 @@ to allocate a page of memory for that task.
|
|||
|
||||
If a cpuset has its 'cpus' modified, then each task in that cpuset
|
||||
will have its allowed CPU placement changed immediately. Similarly,
|
||||
if a tasks pid is written to a cpusets 'tasks' file, in either its
|
||||
current cpuset or another cpuset, then its allowed CPU placement is
|
||||
changed immediately. If such a task had been bound to some subset
|
||||
of its cpuset using the sched_setaffinity() call, the task will be
|
||||
allowed to run on any CPU allowed in its new cpuset, negating the
|
||||
affect of the prior sched_setaffinity() call.
|
||||
if a tasks pid is written to another cpusets 'tasks' file, then its
|
||||
allowed CPU placement is changed immediately. If such a task had been
|
||||
bound to some subset of its cpuset using the sched_setaffinity() call,
|
||||
the task will be allowed to run on any CPU allowed in its new cpuset,
|
||||
negating the effect of the prior sched_setaffinity() call.
|
||||
|
||||
In summary, the memory placement of a task whose cpuset is changed is
|
||||
updated by the kernel, on the next allocation of a page for that task,
|
||||
but the processor placement is not updated, until that tasks pid is
|
||||
rewritten to the 'tasks' file of its cpuset. This is done to avoid
|
||||
impacting the scheduler code in the kernel with a check for changes
|
||||
in a tasks processor placement.
|
||||
and the processor placement is updated immediately.
|
||||
|
||||
Normally, once a page is allocated (given a physical page
|
||||
of main memory) then that page stays on whatever node it
|
||||
|
@ -681,10 +686,14 @@ and then start a subshell 'sh' in that cpuset:
|
|||
# The next line should display '/Charlie'
|
||||
cat /proc/self/cpuset
|
||||
|
||||
In the future, a C library interface to cpusets will likely be
|
||||
available. For now, the only way to query or modify cpusets is
|
||||
via the cpuset file system, using the various cd, mkdir, echo, cat,
|
||||
rmdir commands from the shell, or their equivalent from C.
|
||||
There are ways to query or modify cpusets:
|
||||
- via the cpuset file system directly, using the various cd, mkdir, echo,
|
||||
cat, rmdir commands from the shell, or their equivalent from C.
|
||||
- via the C library libcpuset.
|
||||
- via the C library libcgroup.
|
||||
(http://sourceforge.net/proects/libcg/)
|
||||
- via the python application cset.
|
||||
(http://developer.novell.com/wiki/index.php/Cpuset)
|
||||
|
||||
The sched_setaffinity calls can also be done at the shell prompt using
|
||||
SGI's runon or Robert Love's taskset. The mbind and set_mempolicy
|
||||
|
@ -756,7 +765,7 @@ mount -t cpuset X /dev/cpuset
|
|||
|
||||
is equivalent to
|
||||
|
||||
mount -t cgroup -ocpuset X /dev/cpuset
|
||||
mount -t cgroup -ocpuset,noprefix X /dev/cpuset
|
||||
echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent
|
||||
|
||||
2.2 Adding/removing cpus
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
Memory Resource Controller(Memcg) Implementation Memo.
|
||||
Last Updated: 2008/12/15
|
||||
Base Kernel Version: based on 2.6.28-rc8-mm.
|
||||
Last Updated: 2009/1/19
|
||||
Base Kernel Version: based on 2.6.29-rc2.
|
||||
|
||||
Because VM is getting complex (one of reasons is memcg...), memcg's behavior
|
||||
is complex. This is a document for memcg's internal behavior.
|
||||
|
@ -340,3 +340,23 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||
# mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices
|
||||
|
||||
and do task move, mkdir, rmdir etc...under this.
|
||||
|
||||
9.7 swapoff.
|
||||
Besides management of swap is one of complicated parts of memcg,
|
||||
call path of swap-in at swapoff is not same as usual swap-in path..
|
||||
It's worth to be tested explicitly.
|
||||
|
||||
For example, test like following is good.
|
||||
(Shell-A)
|
||||
# mount -t cgroup none /cgroup -t memory
|
||||
# mkdir /cgroup/test
|
||||
# echo 40M > /cgroup/test/memory.limit_in_bytes
|
||||
# echo 0 > /cgroup/test/tasks
|
||||
Run malloc(100M) program under this. You'll see 60M of swaps.
|
||||
(Shell-B)
|
||||
# move all tasks in /cgroup/test to /cgroup
|
||||
# /sbin/swapoff -a
|
||||
# rmdir /test/cgroup
|
||||
# kill malloc task.
|
||||
|
||||
Of course, tmpfs v.s. swapoff test should be tested, too.
|
||||
|
|
|
@ -137,7 +137,7 @@ static void cn_test_timer_func(unsigned long __data)
|
|||
|
||||
memcpy(m + 1, data, m->len);
|
||||
|
||||
cn_netlink_send(m, 0, gfp_any());
|
||||
cn_netlink_send(m, 0, GFP_ATOMIC);
|
||||
kfree(m);
|
||||
}
|
||||
|
||||
|
@ -160,10 +160,8 @@ static int cn_test_init(void)
|
|||
goto err_out;
|
||||
}
|
||||
|
||||
init_timer(&cn_test_timer);
|
||||
cn_test_timer.function = cn_test_timer_func;
|
||||
setup_timer(&cn_test_timer, cn_test_timer_func, 0);
|
||||
cn_test_timer.expires = jiffies + HZ;
|
||||
cn_test_timer.data = 0;
|
||||
add_timer(&cn_test_timer);
|
||||
|
||||
return 0;
|
||||
|
|
|
@ -117,10 +117,28 @@ accessible parameters:
|
|||
sampling_rate: measured in uS (10^-6 seconds), this is how often you
|
||||
want the kernel to look at the CPU usage and to make decisions on
|
||||
what to do about the frequency. Typically this is set to values of
|
||||
around '10000' or more.
|
||||
around '10000' or more. It's default value is (cmp. with users-guide.txt):
|
||||
transition_latency * 1000
|
||||
The lowest value you can set is:
|
||||
transition_latency * 100 or it may get restricted to a value where it
|
||||
makes not sense for the kernel anymore to poll that often which depends
|
||||
on your HZ config variable (HZ=1000: max=20000us, HZ=250: max=5000).
|
||||
Be aware that transition latency is in ns and sampling_rate is in us, so you
|
||||
get the same sysfs value by default.
|
||||
Sampling rate should always get adjusted considering the transition latency
|
||||
To set the sampling rate 750 times as high as the transition latency
|
||||
in the bash (as said, 1000 is default), do:
|
||||
echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
|
||||
>ondemand/sampling_rate
|
||||
|
||||
show_sampling_rate_(min|max): the minimum and maximum sampling rates
|
||||
available that you may set 'sampling_rate' to.
|
||||
show_sampling_rate_(min|max): THIS INTERFACE IS DEPRECATED, DON'T USE IT.
|
||||
You can use wider ranges now and the general
|
||||
cpuinfo_transition_latency variable (cmp. with user-guide.txt) can be
|
||||
used to obtain exactly the same info:
|
||||
show_sampling_rate_min = transtition_latency * 500 / 1000
|
||||
show_sampling_rate_max = transtition_latency * 500000 / 1000
|
||||
(divided by 1000 is to illustrate that sampling rate is in us and
|
||||
transition latency is exported ns).
|
||||
|
||||
up_threshold: defines what the average CPU usage between the samplings
|
||||
of 'sampling_rate' needs to be for the kernel to make a decision on
|
||||
|
|
|
@ -152,6 +152,18 @@ cpuinfo_min_freq : this file shows the minimum operating
|
|||
frequency the processor can run at(in kHz)
|
||||
cpuinfo_max_freq : this file shows the maximum operating
|
||||
frequency the processor can run at(in kHz)
|
||||
cpuinfo_transition_latency The time it takes on this CPU to
|
||||
switch between two frequencies in nano
|
||||
seconds. If unknown or known to be
|
||||
that high that the driver does not
|
||||
work with the ondemand governor, -1
|
||||
(CPUFREQ_ETERNAL) will be returned.
|
||||
Using this information can be useful
|
||||
to choose an appropriate polling
|
||||
frequency for a kernel governor or
|
||||
userspace daemon. Make sure to not
|
||||
switch the frequency too often
|
||||
resulting in performance loss.
|
||||
scaling_driver : this file shows what cpufreq driver is
|
||||
used to set the frequency on this CPU
|
||||
|
||||
|
@ -195,19 +207,3 @@ scaling_setspeed. By "echoing" a new frequency into this
|
|||
you can change the speed of the CPU,
|
||||
but only within the limits of
|
||||
scaling_min_freq and scaling_max_freq.
|
||||
|
||||
|
||||
3.2 Deprecated Interfaces
|
||||
-------------------------
|
||||
|
||||
Depending on your kernel configuration, you might find the following
|
||||
cpufreq-related files:
|
||||
/proc/cpufreq
|
||||
/proc/sys/cpu/*/speed
|
||||
/proc/sys/cpu/*/speed-min
|
||||
/proc/sys/cpu/*/speed-max
|
||||
|
||||
These are files for deprecated interfaces to cpufreq, which offer far
|
||||
less functionality. Because of this, these interfaces aren't described
|
||||
here.
|
||||
|
||||
|
|
|
@ -62,7 +62,6 @@ aic7*reg_print.c*
|
|||
aic7*seq.h*
|
||||
aicasm
|
||||
aicdb.h*
|
||||
asm
|
||||
asm-offsets.h
|
||||
asm_offsets.h
|
||||
autoconf.h*
|
||||
|
|
|
@ -127,9 +127,11 @@ void unlock_device(struct device * dev);
|
|||
Attributes
|
||||
~~~~~~~~~~
|
||||
struct device_attribute {
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off);
|
||||
ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off);
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device *dev, struct device_attribute *attr,
|
||||
char *buf);
|
||||
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
|
||||
const char *buf, size_t count);
|
||||
};
|
||||
|
||||
Attributes of devices can be exported via drivers using a simple
|
||||
|
|
|
@ -1,205 +0,0 @@
|
|||
This README escorted the skystar2-driver rewriting procedure. It describes the
|
||||
state of the new flexcop-driver set and some internals are written down here
|
||||
too.
|
||||
|
||||
This document hopefully describes things about the flexcop and its
|
||||
device-offsprings. Goal was to write an easy-to-write and easy-to-read set of
|
||||
drivers based on the skystar2.c and other information.
|
||||
|
||||
Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been
|
||||
touched and rewritten.
|
||||
|
||||
History & News
|
||||
==============
|
||||
2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana)
|
||||
|
||||
|
||||
|
||||
|
||||
General coding processing
|
||||
=========================
|
||||
|
||||
We should proceed as follows (as long as no one complains):
|
||||
|
||||
0) Think before start writing code!
|
||||
|
||||
1) rewriting the skystar2.c with the help of the flexcop register descriptions
|
||||
and splitting up the files to a pci-bus-part and a flexcop-part.
|
||||
The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the
|
||||
device-specific part and b2c2-flexcop.ko for the common flexcop-functions.
|
||||
|
||||
2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c
|
||||
and other pci drivers)
|
||||
|
||||
3) make some beautification (see 'Improvements when rewriting (refactoring) is
|
||||
done')
|
||||
|
||||
4) Testing the new driver and maybe substitute the skystar2.c with it, to reach
|
||||
a wider tester audience.
|
||||
|
||||
5) creating an usb-bus-part using the already written flexcop code for the pci
|
||||
card.
|
||||
|
||||
Idea: create a kernel-object for the flexcop and export all important
|
||||
functions. This option saves kernel-memory, but maybe a lot of functions have
|
||||
to be exported to kernel namespace.
|
||||
|
||||
|
||||
Current situation
|
||||
=================
|
||||
|
||||
0) Done :)
|
||||
1) Done (some minor issues left)
|
||||
2) Done
|
||||
3) Not ready yet, more information is necessary
|
||||
4) next to be done (see the table below)
|
||||
5) USB driver is working (yes, there are some minor issues)
|
||||
|
||||
What seems to be ready?
|
||||
-----------------------
|
||||
|
||||
1) Rewriting
|
||||
1a) i2c is cut off from the flexcop-pci.c and seems to work
|
||||
1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c
|
||||
1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c
|
||||
1e) eeprom (reading MAC address)
|
||||
1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me))
|
||||
1f) misc. register accesses for reading parameters (e.g. resetting, revision)
|
||||
1g) pid/mac filter (flexcop-hw-filter.c)
|
||||
1i) dvb-stuff initialization in flexcop.c (done)
|
||||
1h) dma stuff (now just using the size-irq, instead of all-together, to be done)
|
||||
1j) remove flexcop initialization from flexcop-pci.c completely (done)
|
||||
1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO')
|
||||
1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from
|
||||
non-static where possible, moved code to proper places)
|
||||
|
||||
2) Search for errors in the leftover of flexcop-pci.c (partially done)
|
||||
5a) add MAC address reading
|
||||
5c) feeding of ISOC data to the software demux (format of the isochronous data
|
||||
and speed optimization, no real error) (thanks to Vadim Catana)
|
||||
|
||||
What to do in the near future?
|
||||
--------------------------------------
|
||||
(no special order here)
|
||||
|
||||
5) USB driver
|
||||
5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting)
|
||||
|
||||
Testing changes
|
||||
---------------
|
||||
|
||||
O = item is working
|
||||
P = item is partially working
|
||||
X = item is not working
|
||||
N = item does not apply here
|
||||
<empty field> = item need to be examined
|
||||
|
||||
| PCI | USB
|
||||
item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312
|
||||
-------+-------+---------+---------+-------+-------+---------+---------+-------
|
||||
1a) | O | | | | N | N | N | N
|
||||
1b) | O | | | | | | O |
|
||||
1c) | N | N | | | N | N | O |
|
||||
1d) | O | O
|
||||
1e) | O | O
|
||||
1f) | P
|
||||
1g) | O
|
||||
1h) | P |
|
||||
1i) | O | N
|
||||
1j) | O | N
|
||||
1l) | O | N
|
||||
2) | O | N
|
||||
5a) | N | O
|
||||
5b)* | N |
|
||||
5c) | N | O
|
||||
|
||||
* - not done yet
|
||||
|
||||
Known bugs and problems and TODO
|
||||
--------------------------------
|
||||
|
||||
1g/h/l) when pid filtering is enabled on the pci card
|
||||
|
||||
DMA usage currently:
|
||||
The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first
|
||||
address and triggers an IRQ when it's full and starts writing to the second
|
||||
address. When the second address is full, the IRQ is triggered again, and
|
||||
the flexcop writes to first address again, and so on.
|
||||
The buffersize of each address is currently 640*188 bytes.
|
||||
|
||||
Problem is, when using hw-pid-filtering and doing some low-bandwidth
|
||||
operation (like scanning) the buffers won't be filled enough to trigger
|
||||
the IRQ. That's why:
|
||||
|
||||
When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ
|
||||
is triggered. Is the current write address of DMA1 different to the one
|
||||
during the last IRQ, then the data is passed to the demuxer.
|
||||
|
||||
There is an additional DMA-IRQ-method: packet count IRQ. This isn't
|
||||
implemented correctly yet.
|
||||
|
||||
The solution is to disable HW PID filtering, but I don't know how the DVB
|
||||
API software demux behaves on slow systems with 45MBit/s TS.
|
||||
|
||||
Solved bugs :)
|
||||
--------------
|
||||
1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't
|
||||
working)
|
||||
SOLUTION: also index 0 was affected, because net_translation is done for
|
||||
these indexes by default
|
||||
|
||||
5b) isochronous transfer does only work in the first attempt (for the Sky2PC
|
||||
USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really
|
||||
woke up again (don't know if this need fixes, see
|
||||
flexcop-fe-tuner.c:flexcop_sleep)
|
||||
|
||||
NEWS: when the driver is loaded and unloaded and loaded again (w/o doing
|
||||
anything in the while the driver is loaded the first time), no transfers take
|
||||
place anymore.
|
||||
|
||||
Improvements when rewriting (refactoring) is done
|
||||
=================================================
|
||||
|
||||
- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control
|
||||
(enable sleeping for other demods than dvb-s)
|
||||
- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA)
|
||||
|
||||
Debugging
|
||||
---------
|
||||
- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it
|
||||
with this flexcop, this is important, because i2c is now using the
|
||||
flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for
|
||||
that, please tell us so).
|
||||
|
||||
Everything which is identical in the following table, can be put into a common
|
||||
flexcop-module.
|
||||
|
||||
PCI USB
|
||||
-------------------------------------------------------------------------------
|
||||
Different:
|
||||
Register access: accessing IO memory USB control message
|
||||
I2C bus: I2C bus of the FC USB control message
|
||||
Data transfer: DMA isochronous transfer
|
||||
EEPROM transfer: through i2c bus not clear yet
|
||||
|
||||
Identical:
|
||||
Streaming: accessing registers
|
||||
PID Filtering: accessing registers
|
||||
Sram destinations: accessing registers
|
||||
Tuner/Demod: I2C bus
|
||||
DVB-stuff: can be written for common use
|
||||
|
||||
Acknowledgements (just for the rewriting part)
|
||||
================
|
||||
|
||||
Bjarne Steinsbo thought a lot in the first place of the pci part for this code
|
||||
sharing idea.
|
||||
|
||||
Andreas Oberritter for providing a recent PCI initialization template
|
||||
(pluto2.c).
|
||||
|
||||
Boleslaw Ciesielski for pointing out a problem with firmware loader.
|
||||
|
||||
Vadim Catana for correcting the USB transfer.
|
||||
|
||||
comments, critics and ideas to linux-dvb@linuxtv.org.
|
|
@ -1,5 +1,5 @@
|
|||
How to set up the Technisat devices
|
||||
===================================
|
||||
How to set up the Technisat/B2C2 Flexcop devices
|
||||
================================================
|
||||
|
||||
1) Find out what device you have
|
||||
================================
|
||||
|
@ -16,54 +16,60 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)...
|
|||
|
||||
If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one:
|
||||
"Multimedia devices" => "Customise analog and hybrid tuner modules to build"
|
||||
In this directory uncheck every driver which is activated there.
|
||||
In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only).
|
||||
|
||||
Then please activate:
|
||||
2a) Main module part:
|
||||
|
||||
a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
|
||||
b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR
|
||||
b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card
|
||||
OR
|
||||
c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter
|
||||
d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers"
|
||||
Notice: d.) is helpful for troubleshooting
|
||||
|
||||
2b) Frontend module part:
|
||||
|
||||
1.) Revision 2.3:
|
||||
1.) SkyStar DVB-S Revision 2.3:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based"
|
||||
|
||||
2.) Revision 2.6:
|
||||
2.) SkyStar DVB-S Revision 2.6:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based"
|
||||
|
||||
3.) Revision 2.7:
|
||||
3.) SkyStar DVB-S Revision 2.7:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
|
||||
d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
|
||||
|
||||
4.) Revision 2.8:
|
||||
4.) SkyStar DVB-S Revision 2.8:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based"
|
||||
d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
|
||||
|
||||
5.) DVB-T card:
|
||||
5.) AirStar DVB-T card:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based"
|
||||
|
||||
6.) DVB-C card:
|
||||
6.) CableStar DVB-C card:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based"
|
||||
|
||||
7.) ATSC card 1st generation:
|
||||
7.) AirStar ATSC card 1st generation:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510"
|
||||
|
||||
8.) ATSC card 2nd generation:
|
||||
8.) AirStar ATSC card 2nd generation:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
|
||||
c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners"
|
||||
|
||||
Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008
|
||||
9.) AirStar ATSC card 3rd generation:
|
||||
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||
b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
|
||||
c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support"
|
||||
|
||||
Author: Uwe Bugla <uwe.bugla@gmx.de> February 2009
|
||||
|
|
240
Documentation/dynamic-debug-howto.txt
Normal file
240
Documentation/dynamic-debug-howto.txt
Normal file
|
@ -0,0 +1,240 @@
|
|||
|
||||
Introduction
|
||||
============
|
||||
|
||||
This document describes how to use the dynamic debug (ddebug) feature.
|
||||
|
||||
Dynamic debug is designed to allow you to dynamically enable/disable kernel
|
||||
code to obtain additional kernel information. Currently, if
|
||||
CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_debug() calls can be
|
||||
dynamically enabled per-callsite.
|
||||
|
||||
Dynamic debug has even more useful features:
|
||||
|
||||
* Simple query language allows turning on and off debugging statements by
|
||||
matching any combination of:
|
||||
|
||||
- source filename
|
||||
- function name
|
||||
- line number (including ranges of line numbers)
|
||||
- module name
|
||||
- format string
|
||||
|
||||
* Provides a debugfs control file: <debugfs>/dynamic_debug/control which can be
|
||||
read to display the complete list of known debug statements, to help guide you
|
||||
|
||||
Controlling dynamic debug Behaviour
|
||||
===============================
|
||||
|
||||
The behaviour of pr_debug()/dev_debug()s are controlled via writing to a
|
||||
control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs
|
||||
filesystem, in order to make use of this feature. Subsequently, we refer to the
|
||||
control file as: <debugfs>/dynamic_debug/control. For example, if you want to
|
||||
enable printing from source file 'svcsock.c', line 1603 you simply do:
|
||||
|
||||
nullarbor:~ # echo 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
If you make a mistake with the syntax, the write will fail thus:
|
||||
|
||||
nullarbor:~ # echo 'file svcsock.c wtf 1 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
-bash: echo: write error: Invalid argument
|
||||
|
||||
Viewing Dynamic Debug Behaviour
|
||||
===========================
|
||||
|
||||
You can view the currently configured behaviour of all the debug statements
|
||||
via:
|
||||
|
||||
nullarbor:~ # cat <debugfs>/dynamic_debug/control
|
||||
# filename:lineno [module]function flags format
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup - "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init - "\011max_inline : %d\012"
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init - "\011sq_depth : %d\012"
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init - "\011max_requests : %d\012"
|
||||
...
|
||||
|
||||
|
||||
You can also apply standard Unix text manipulation filters to this
|
||||
data, e.g.
|
||||
|
||||
nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control | wc -l
|
||||
62
|
||||
|
||||
nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l
|
||||
42
|
||||
|
||||
Note in particular that the third column shows the enabled behaviour
|
||||
flags for each debug statement callsite (see below for definitions of the
|
||||
flags). The default value, no extra behaviour enabled, is "-". So
|
||||
you can view all the debug statement callsites with any non-default flags:
|
||||
|
||||
nullarbor:~ # awk '$3 != "-"' <debugfs>/dynamic_debug/control
|
||||
# filename:lineno [module]function flags format
|
||||
/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012"
|
||||
|
||||
|
||||
Command Language Reference
|
||||
==========================
|
||||
|
||||
At the lexical level, a command comprises a sequence of words separated
|
||||
by whitespace characters. Note that newlines are treated as word
|
||||
separators and do *not* end a command or allow multiple commands to
|
||||
be done together. So these are all equivalent:
|
||||
|
||||
nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -c ' file svcsock.c line 1603 +p ' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
Commands are bounded by a write() system call. If you want to do
|
||||
multiple commands you need to do a separate "echo" for each, like:
|
||||
|
||||
nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\
|
||||
> echo 'file svcsock.c line 1563 +p' > /proc/dprintk
|
||||
|
||||
or even like:
|
||||
|
||||
nullarbor:~ # (
|
||||
> echo 'file svcsock.c line 1603 +p' ;\
|
||||
> echo 'file svcsock.c line 1563 +p' ;\
|
||||
> ) > /proc/dprintk
|
||||
|
||||
At the syntactical level, a command comprises a sequence of match
|
||||
specifications, followed by a flags change specification.
|
||||
|
||||
command ::= match-spec* flags-spec
|
||||
|
||||
The match-spec's are used to choose a subset of the known dprintk()
|
||||
callsites to which to apply the flags-spec. Think of them as a query
|
||||
with implicit ANDs between each pair. Note that an empty list of
|
||||
match-specs is possible, but is not very useful because it will not
|
||||
match any debug statement callsites.
|
||||
|
||||
A match specification comprises a keyword, which controls the attribute
|
||||
of the callsite to be compared, and a value to compare against. Possible
|
||||
keywords are:
|
||||
|
||||
match-spec ::= 'func' string |
|
||||
'file' string |
|
||||
'module' string |
|
||||
'format' string |
|
||||
'line' line-range
|
||||
|
||||
line-range ::= lineno |
|
||||
'-'lineno |
|
||||
lineno'-' |
|
||||
lineno'-'lineno
|
||||
// Note: line-range cannot contain space, e.g.
|
||||
// "1-30" is valid range but "1 - 30" is not.
|
||||
|
||||
lineno ::= unsigned-int
|
||||
|
||||
The meanings of each keyword are:
|
||||
|
||||
func
|
||||
The given string is compared against the function name
|
||||
of each callsite. Example:
|
||||
|
||||
func svc_tcp_accept
|
||||
|
||||
file
|
||||
The given string is compared against either the full
|
||||
pathname or the basename of the source file of each
|
||||
callsite. Examples:
|
||||
|
||||
file svcsock.c
|
||||
file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
|
||||
|
||||
module
|
||||
The given string is compared against the module name
|
||||
of each callsite. The module name is the string as
|
||||
seen in "lsmod", i.e. without the directory or the .ko
|
||||
suffix and with '-' changed to '_'. Examples:
|
||||
|
||||
module sunrpc
|
||||
module nfsd
|
||||
|
||||
format
|
||||
The given string is searched for in the dynamic debug format
|
||||
string. Note that the string does not need to match the
|
||||
entire format, only some part. Whitespace and other
|
||||
special characters can be escaped using C octal character
|
||||
escape \ooo notation, e.g. the space character is \040.
|
||||
Alternatively, the string can be enclosed in double quote
|
||||
characters (") or single quote characters (').
|
||||
Examples:
|
||||
|
||||
format svcrdma: // many of the NFS/RDMA server dprintks
|
||||
format readahead // some dprintks in the readahead cache
|
||||
format nfsd:\040SETATTR // one way to match a format with whitespace
|
||||
format "nfsd: SETATTR" // a neater way to match a format with whitespace
|
||||
format 'nfsd: SETATTR' // yet another way to match a format with whitespace
|
||||
|
||||
line
|
||||
The given line number or range of line numbers is compared
|
||||
against the line number of each dprintk() callsite. A single
|
||||
line number matches the callsite line number exactly. A
|
||||
range of line numbers matches any callsite between the first
|
||||
and last line number inclusive. An empty first number means
|
||||
the first line in the file, an empty line number means the
|
||||
last number in the file. Examples:
|
||||
|
||||
line 1603 // exactly line 1603
|
||||
line 1600-1605 // the six lines from line 1600 to line 1605
|
||||
line -1605 // the 1605 lines from line 1 to line 1605
|
||||
line 1600- // all lines from line 1600 to the end of the file
|
||||
|
||||
The flags specification comprises a change operation followed
|
||||
by one or more flag characters. The change operation is one
|
||||
of the characters:
|
||||
|
||||
-
|
||||
remove the given flags
|
||||
|
||||
+
|
||||
add the given flags
|
||||
|
||||
=
|
||||
set the flags to the given flags
|
||||
|
||||
The flags are:
|
||||
|
||||
p
|
||||
Causes a printk() message to be emitted to dmesg
|
||||
|
||||
Note the regexp ^[-+=][scp]+$ matches a flags specification.
|
||||
Note also that there is no convenient syntax to remove all
|
||||
the flags at once, you need to use "-psc".
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
// enable the message at line 1603 of file svcsock.c
|
||||
nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
// enable all the messages in file svcsock.c
|
||||
nullarbor:~ # echo -n 'file svcsock.c +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
// enable all the messages in the NFS server module
|
||||
nullarbor:~ # echo -n 'module nfsd +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
// enable all 12 messages in the function svc_process()
|
||||
nullarbor:~ # echo -n 'func svc_process +p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
// disable all 12 messages in the function svc_process()
|
||||
nullarbor:~ # echo -n 'func svc_process -p' >
|
||||
<debugfs>/dynamic_debug/control
|
||||
|
||||
// enable messages for NFS calls READ, READLINK, READDIR and READDIR+.
|
||||
nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
|
||||
<debugfs>/dynamic_debug/control
|
|
@ -229,7 +229,9 @@ Who: Jan Engelhardt <jengelh@computergmbh.de>
|
|||
---------------------------
|
||||
|
||||
What: b43 support for firmware revision < 410
|
||||
When: July 2008
|
||||
When: The schedule was July 2008, but it was decided that we are going to keep the
|
||||
code as long as there are no major maintanance headaches.
|
||||
So it _could_ be removed _any_ time now, if it conflicts with something new.
|
||||
Why: The support code for the old firmware hurts code readability/maintainability
|
||||
and slightly hurts runtime performance. Bugfixes for the old firmware
|
||||
are not provided by Broadcom anymore.
|
||||
|
@ -335,3 +337,29 @@ Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
|
|||
Secmark, it is time to deprecate the older mechanism and start the
|
||||
process of removing the old code.
|
||||
Who: Paul Moore <paul.moore@hp.com>
|
||||
---------------------------
|
||||
|
||||
What: sysfs ui for changing p4-clockmod parameters
|
||||
When: September 2009
|
||||
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
|
||||
e088e4c9cdb618675874becb91b2fd581ee707e6.
|
||||
Removal is subject to fixing any remaining bugs in ACPI which may
|
||||
cause the thermal throttling not to happen at the right time.
|
||||
Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
|
||||
|
||||
-----------------------------
|
||||
|
||||
What: __do_IRQ all in one fits nothing interrupt handler
|
||||
When: 2.6.32
|
||||
Why: __do_IRQ was kept for easy migration to the type flow handlers.
|
||||
More than two years of migration time is enough.
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
-----------------------------
|
||||
|
||||
What: obsolete generic irq defines and typedefs
|
||||
When: 2.6.30
|
||||
Why: The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t)
|
||||
have been kept around for migration reasons. After more than two years
|
||||
it's time to remove them finally
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
|
|
@ -437,8 +437,11 @@ grab BKL for cases when we close a file that had been opened r/w, but that
|
|||
can and should be done using the internal locking with smaller critical areas).
|
||||
Current worst offender is ext2_get_block()...
|
||||
|
||||
->fasync() is a mess. This area needs a big cleanup and that will probably
|
||||
affect locking.
|
||||
->fasync() is called without BKL protection, and is responsible for
|
||||
maintaining the FASYNC bit in filp->f_flags. Most instances call
|
||||
fasync_helper(), which does that maintenance, so it's not normally
|
||||
something one needs to worry about. Return values > 0 will be mapped to
|
||||
zero in the VFS layer.
|
||||
|
||||
->readdir() and ->ioctl() on directories must be changed. Ideally we would
|
||||
move ->readdir() to inode_operations and use a separate method for directory
|
||||
|
|
|
@ -373,10 +373,11 @@ Filesystem Resizing http://ext2resize.sourceforge.net/
|
|||
Compression (*) http://e2compr.sourceforge.net/
|
||||
|
||||
Implementations for:
|
||||
Windows 95/98/NT/2000 http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htm
|
||||
Windows 95 (*) http://www.yipton.demon.co.uk/content.html#FSDEXT2
|
||||
Windows 95/98/NT/2000 http://www.chrysocome.net/explore2fs
|
||||
Windows 95 (*) http://www.yipton.net/content.html#FSDEXT2
|
||||
DOS client (*) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/
|
||||
OS/2 http://perso.wanadoo.fr/matthieu.willm/ext2-os2/
|
||||
RISC OS client ftp://ftp.barnet.ac.uk/pub/acorn/armlinux/iscafs/
|
||||
OS/2 (+) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/
|
||||
RISC OS client http://www.esw-heim.tu-clausthal.de/~marco/smorbrod/IscaFS/
|
||||
|
||||
(*) no longer actively developed/supported (as of Apr 2001)
|
||||
(+) no longer actively developed/supported (as of Mar 2009)
|
||||
|
|
|
@ -198,5 +198,5 @@ kernel source: <file:fs/ext3/>
|
|||
programs: http://e2fsprogs.sourceforge.net/
|
||||
http://ext2resize.sourceforge.net
|
||||
|
||||
useful links: http://www-106.ibm.com/developerworks/linux/library/l-fs7/
|
||||
http://www-106.ibm.com/developerworks/linux/library/l-fs8/
|
||||
useful links: http://www.ibm.com/developerworks/library/l-fs7.html
|
||||
http://www.ibm.com/developerworks/library/l-fs8.html
|
||||
|
|
|
@ -251,7 +251,7 @@ NFS/RDMA Setup
|
|||
|
||||
Instruct the server to listen on the RDMA transport:
|
||||
|
||||
$ echo rdma 2050 > /proc/fs/nfsd/portlist
|
||||
$ echo rdma 20049 > /proc/fs/nfsd/portlist
|
||||
|
||||
- On the client system
|
||||
|
||||
|
@ -263,7 +263,7 @@ NFS/RDMA Setup
|
|||
Regardless of how the client was built (module or built-in), use this
|
||||
command to mount the NFS/RDMA server:
|
||||
|
||||
$ mount -o rdma,port=2050 <IPoIB-server-name-or-address>:/<export> /mnt
|
||||
$ mount -o rdma,port=20049 <IPoIB-server-name-or-address>:/<export> /mnt
|
||||
|
||||
To verify that the mount is using RDMA, run "cat /proc/mounts" and check
|
||||
the "proto" field for the given mount.
|
||||
|
|
|
@ -1478,6 +1478,13 @@ of problems on the network like duplicate address or bad checksums. Normally,
|
|||
this should be enabled, but if the problem persists the messages can be
|
||||
disabled.
|
||||
|
||||
netdev_budget
|
||||
-------------
|
||||
|
||||
Maximum number of packets taken from all interfaces in one polling cycle (NAPI
|
||||
poll). In one polling cycle interfaces which are registered to polling are
|
||||
probed in a round-robin manner. The limit of packets in one such probe can be
|
||||
set per-device via sysfs class/net/<device>/weight .
|
||||
|
||||
netdev_max_backlog
|
||||
------------------
|
||||
|
@ -2027,6 +2034,34 @@ increase the likelihood of this process being killed by the oom-killer. Valid
|
|||
values are in the range -16 to +15, plus the special value -17, which disables
|
||||
oom-killing altogether for this process.
|
||||
|
||||
The process to be killed in an out-of-memory situation is selected among all others
|
||||
based on its badness score. This value equals the original memory size of the process
|
||||
and is then updated according to its CPU time (utime + stime) and the
|
||||
run time (uptime - start time). The longer it runs the smaller is the score.
|
||||
Badness score is divided by the square root of the CPU time and then by
|
||||
the double square root of the run time.
|
||||
|
||||
Swapped out tasks are killed first. Half of each child's memory size is added to
|
||||
the parent's score if they do not share the same memory. Thus forking servers
|
||||
are the prime candidates to be killed. Having only one 'hungry' child will make
|
||||
parent less preferable than the child.
|
||||
|
||||
/proc/<pid>/oom_score shows process' current badness score.
|
||||
|
||||
The following heuristics are then applied:
|
||||
* if the task was reniced, its score doubles
|
||||
* superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE
|
||||
or CAP_SYS_RAWIO) have their score divided by 4
|
||||
* if oom condition happened in one cpuset and checked task does not belong
|
||||
to it, its score is divided by 8
|
||||
* the resulting score is multiplied by two to the power of oom_adj, i.e.
|
||||
points <<= oom_adj when it is positive and
|
||||
points >>= -(oom_adj) otherwise
|
||||
|
||||
The task with the highest badness score is then selected and its children
|
||||
are killed, process itself will be killed in an OOM situation when it does
|
||||
not have children or some of them disabled oom like described above.
|
||||
|
||||
2.13 /proc/<pid>/oom_score - Display current oom-killer score
|
||||
-------------------------------------------------------------
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ Squashfs filesystem features versus Cramfs:
|
|||
|
||||
Squashfs Cramfs
|
||||
|
||||
Max filesystem size: 2^64 16 MiB
|
||||
Max filesystem size: 2^64 256 MiB
|
||||
Max file size: ~ 2 TiB 16 MiB
|
||||
Max files: unlimited unlimited
|
||||
Max directories: unlimited unlimited
|
||||
|
|
|
@ -9,6 +9,7 @@ that support it. For example, a given bus might look like this:
|
|||
| |-- class
|
||||
| |-- config
|
||||
| |-- device
|
||||
| |-- enable
|
||||
| |-- irq
|
||||
| |-- local_cpus
|
||||
| |-- resource
|
||||
|
@ -32,6 +33,7 @@ files, each with their own function.
|
|||
class PCI class (ascii, ro)
|
||||
config PCI config space (binary, rw)
|
||||
device PCI device (ascii, ro)
|
||||
enable Whether the device is enabled (ascii, rw)
|
||||
irq IRQ number (ascii, ro)
|
||||
local_cpus nearby CPU mask (cpumask, ro)
|
||||
resource PCI resource host addresses (ascii, ro)
|
||||
|
@ -57,10 +59,19 @@ used to do actual device programming from userspace. Note that some platforms
|
|||
don't support mmapping of certain resources, so be sure to check the return
|
||||
value from any attempted mmap.
|
||||
|
||||
The 'enable' file provides a counter that indicates how many times the device
|
||||
has been enabled. If the 'enable' file currently returns '4', and a '1' is
|
||||
echoed into it, it will then return '5'. Echoing a '0' into it will decrease
|
||||
the count. Even when it returns to 0, though, some of the initialisation
|
||||
may not be reversed.
|
||||
|
||||
The 'rom' file is special in that it provides read-only access to the device's
|
||||
ROM file, if available. It's disabled by default, however, so applications
|
||||
should write the string "1" to the file to enable it before attempting a read
|
||||
call, and disable it following the access by writing "0" to the file.
|
||||
call, and disable it following the access by writing "0" to the file. Note
|
||||
that the device must be enabled for a rom read to return data succesfully.
|
||||
In the event a driver is not bound to the device, it can be enabled using the
|
||||
'enable' file, documented above.
|
||||
|
||||
Accessing legacy resources through sysfs
|
||||
----------------------------------------
|
||||
|
|
|
@ -2,8 +2,10 @@
|
|||
sysfs - _The_ filesystem for exporting kernel objects.
|
||||
|
||||
Patrick Mochel <mochel@osdl.org>
|
||||
Mike Murphy <mamurph@cs.clemson.edu>
|
||||
|
||||
10 January 2003
|
||||
Revised: 22 February 2009
|
||||
Original: 10 January 2003
|
||||
|
||||
|
||||
What it is:
|
||||
|
@ -64,12 +66,13 @@ An attribute definition is simply:
|
|||
|
||||
struct attribute {
|
||||
char * name;
|
||||
struct module *owner;
|
||||
mode_t mode;
|
||||
};
|
||||
|
||||
|
||||
int sysfs_create_file(struct kobject * kobj, struct attribute * attr);
|
||||
void sysfs_remove_file(struct kobject * kobj, struct attribute * attr);
|
||||
int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
|
||||
void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
|
||||
|
||||
|
||||
A bare attribute contains no means to read or write the value of the
|
||||
|
@ -80,9 +83,11 @@ a specific object type.
|
|||
For example, the driver model defines struct device_attribute like:
|
||||
|
||||
struct device_attribute {
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device * dev, char * buf);
|
||||
ssize_t (*store)(struct device * dev, const char * buf);
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device *dev, struct device_attribute *attr,
|
||||
char *buf);
|
||||
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
|
||||
const char *buf, size_t count);
|
||||
};
|
||||
|
||||
int device_create_file(struct device *, struct device_attribute *);
|
||||
|
@ -90,12 +95,8 @@ void device_remove_file(struct device *, struct device_attribute *);
|
|||
|
||||
It also defines this helper for defining device attributes:
|
||||
|
||||
#define DEVICE_ATTR(_name, _mode, _show, _store) \
|
||||
struct device_attribute dev_attr_##_name = { \
|
||||
.attr = {.name = __stringify(_name) , .mode = _mode }, \
|
||||
.show = _show, \
|
||||
.store = _store, \
|
||||
};
|
||||
#define DEVICE_ATTR(_name, _mode, _show, _store) \
|
||||
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
|
||||
|
||||
For example, declaring
|
||||
|
||||
|
@ -107,9 +108,9 @@ static struct device_attribute dev_attr_foo = {
|
|||
.attr = {
|
||||
.name = "foo",
|
||||
.mode = S_IWUSR | S_IRUGO,
|
||||
.show = show_foo,
|
||||
.store = store_foo,
|
||||
},
|
||||
.show = show_foo,
|
||||
.store = store_foo,
|
||||
};
|
||||
|
||||
|
||||
|
@ -161,10 +162,12 @@ To read or write attributes, show() or store() methods must be
|
|||
specified when declaring the attribute. The method types should be as
|
||||
simple as those defined for device attributes:
|
||||
|
||||
ssize_t (*show)(struct device * dev, char * buf);
|
||||
ssize_t (*store)(struct device * dev, const char * buf);
|
||||
ssize_t (*show)(struct device * dev, struct device_attribute * attr,
|
||||
char * buf);
|
||||
ssize_t (*store)(struct device * dev, struct device_attribute * attr,
|
||||
const char * buf);
|
||||
|
||||
IOW, they should take only an object and a buffer as parameters.
|
||||
IOW, they should take only an object, an attribute, and a buffer as parameters.
|
||||
|
||||
|
||||
sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the
|
||||
|
@ -299,14 +302,16 @@ The following interface layers currently exist in sysfs:
|
|||
Structure:
|
||||
|
||||
struct device_attribute {
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device * dev, char * buf);
|
||||
ssize_t (*store)(struct device * dev, const char * buf);
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device *dev, struct device_attribute *attr,
|
||||
char *buf);
|
||||
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
|
||||
const char *buf, size_t count);
|
||||
};
|
||||
|
||||
Declaring:
|
||||
|
||||
DEVICE_ATTR(_name, _str, _mode, _show, _store);
|
||||
DEVICE_ATTR(_name, _mode, _show, _store);
|
||||
|
||||
Creation/Removal:
|
||||
|
||||
|
@ -342,7 +347,8 @@ Structure:
|
|||
struct driver_attribute {
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device_driver *, char * buf);
|
||||
ssize_t (*store)(struct device_driver *, const char * buf);
|
||||
ssize_t (*store)(struct device_driver *, const char * buf,
|
||||
size_t count);
|
||||
};
|
||||
|
||||
Declaring:
|
||||
|
|
|
@ -79,13 +79,6 @@ Mount options
|
|||
|
||||
(*) == default.
|
||||
|
||||
norm_unmount (*) commit on unmount; the journal is committed
|
||||
when the file-system is unmounted so that the
|
||||
next mount does not have to replay the journal
|
||||
and it becomes very fast;
|
||||
fast_unmount do not commit on unmount; this option makes
|
||||
unmount faster, but the next mount slower
|
||||
because of the need to replay the journal.
|
||||
bulk_read read more in one go to take advantage of flash
|
||||
media that read faster sequentially
|
||||
no_bulk_read (*) do not bulk-read
|
||||
|
|
101
Documentation/hwmon/hpfall.c
Normal file
101
Documentation/hwmon/hpfall.c
Normal file
|
@ -0,0 +1,101 @@
|
|||
/* Disk protection for HP machines.
|
||||
*
|
||||
* Copyright 2008 Eric Piel
|
||||
* Copyright 2009 Pavel Machek <pavel@suse.cz>
|
||||
*
|
||||
* GPLv2.
|
||||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <unistd.h>
|
||||
#include <fcntl.h>
|
||||
#include <sys/stat.h>
|
||||
#include <sys/types.h>
|
||||
#include <string.h>
|
||||
#include <stdint.h>
|
||||
#include <errno.h>
|
||||
#include <signal.h>
|
||||
|
||||
void write_int(char *path, int i)
|
||||
{
|
||||
char buf[1024];
|
||||
int fd = open(path, O_RDWR);
|
||||
if (fd < 0) {
|
||||
perror("open");
|
||||
exit(1);
|
||||
}
|
||||
sprintf(buf, "%d", i);
|
||||
if (write(fd, buf, strlen(buf)) != strlen(buf)) {
|
||||
perror("write");
|
||||
exit(1);
|
||||
}
|
||||
close(fd);
|
||||
}
|
||||
|
||||
void set_led(int on)
|
||||
{
|
||||
write_int("/sys/class/leds/hp::hddprotect/brightness", on);
|
||||
}
|
||||
|
||||
void protect(int seconds)
|
||||
{
|
||||
write_int("/sys/block/sda/device/unload_heads", seconds*1000);
|
||||
}
|
||||
|
||||
int on_ac(void)
|
||||
{
|
||||
// /sys/class/power_supply/AC0/online
|
||||
}
|
||||
|
||||
int lid_open(void)
|
||||
{
|
||||
// /proc/acpi/button/lid/LID/state
|
||||
}
|
||||
|
||||
void ignore_me(void)
|
||||
{
|
||||
protect(0);
|
||||
set_led(0);
|
||||
|
||||
}
|
||||
|
||||
int main(int argc, char* argv[])
|
||||
{
|
||||
int fd, ret;
|
||||
|
||||
fd = open("/dev/freefall", O_RDONLY);
|
||||
if (fd < 0) {
|
||||
perror("open");
|
||||
return EXIT_FAILURE;
|
||||
}
|
||||
|
||||
signal(SIGALRM, ignore_me);
|
||||
|
||||
for (;;) {
|
||||
unsigned char count;
|
||||
|
||||
ret = read(fd, &count, sizeof(count));
|
||||
alarm(0);
|
||||
if ((ret == -1) && (errno == EINTR)) {
|
||||
/* Alarm expired, time to unpark the heads */
|
||||
continue;
|
||||
}
|
||||
|
||||
if (ret != sizeof(count)) {
|
||||
perror("read");
|
||||
break;
|
||||
}
|
||||
|
||||
protect(21);
|
||||
set_led(1);
|
||||
if (1 || on_ac() || lid_open()) {
|
||||
alarm(2);
|
||||
} else {
|
||||
alarm(20);
|
||||
}
|
||||
}
|
||||
|
||||
close(fd);
|
||||
return EXIT_SUCCESS;
|
||||
}
|
|
@ -33,6 +33,14 @@ rate - reports the sampling rate of the accelerometer device in HZ
|
|||
This driver also provides an absolute input class device, allowing
|
||||
the laptop to act as a pinball machine-esque joystick.
|
||||
|
||||
Another feature of the driver is misc device called "freefall" that
|
||||
acts similar to /dev/rtc and reacts on free-fall interrupts received
|
||||
from the device. It supports blocking operations, poll/select and
|
||||
fasync operation modes. You must read 1 bytes from the device. The
|
||||
result is number of free-fall interrupts since the last successful
|
||||
read (or 255 if number of interrupts would not fit).
|
||||
|
||||
|
||||
Axes orientation
|
||||
----------------
|
||||
|
||||
|
|
|
@ -42,6 +42,11 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x4e
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497
|
||||
* Maxim MAX6648
|
||||
Prefix: 'max6646'
|
||||
Addresses scanned: I2C 0x4c
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
|
||||
* Maxim MAX6649
|
||||
Prefix: 'max6646'
|
||||
Addresses scanned: I2C 0x4c
|
||||
|
@ -74,6 +79,11 @@ Supported chips:
|
|||
0x4c, 0x4d and 0x4e
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370
|
||||
* Maxim MAX6692
|
||||
Prefix: 'max6646'
|
||||
Addresses scanned: I2C 0x4c
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
|
||||
|
||||
|
||||
Author: Jean Delvare <khali@linux-fr.org>
|
||||
|
|
|
@ -12,11 +12,11 @@ file at first.
|
|||
|
||||
==================================
|
||||
これは、
|
||||
linux-2.6.24/Documentation/stable_kernel_rules.txt
|
||||
linux-2.6.29/Documentation/stable_kernel_rules.txt
|
||||
の和訳です。
|
||||
|
||||
翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
|
||||
翻訳日: 2007/12/30
|
||||
翻訳日: 2009/1/14
|
||||
翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
|
||||
校正者: 武井伸光さん、<takei at webmasters dot gr dot jp>
|
||||
かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
|
||||
|
@ -38,12 +38,15 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
|
|||
- ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー
|
||||
タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という
|
||||
ようなものを修正しなければならない。短く言えば、重大な問題。
|
||||
- 新しい device ID とクオークも受け入れられる。
|
||||
- どのように競合状態が発生するかの説明も一緒に書かれていない限り、
|
||||
"理論的には競合状態になる"ようなものは不可。
|
||||
- いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー
|
||||
ンアップなど)
|
||||
- 対応するサブシステムメンテナが受け入れたものでなければならない。
|
||||
- Documentation/SubmittingPatches の規則に従ったものでなければならない。
|
||||
- パッチ自体か同等の修正が Linus のツリーに既に存在しなければならない。
|
||||
Linus のツリーでのコミットID を -stable へのパッチ投稿の際に引用す
|
||||
ること。
|
||||
|
||||
-stable ツリーにパッチを送付する手続き-
|
||||
|
||||
|
@ -52,8 +55,10 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
|
|||
- 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
|
||||
には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
|
||||
日かかる場合がある。
|
||||
- もし受け取られたら、パッチは他の開発者たちのレビューのために
|
||||
-stable キューに追加される。
|
||||
- もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
|
||||
メンテナーによるレビューのために -stable キューに追加される。
|
||||
- パッチに stable@kernel.org のアドレスが付加されているときには、それ
|
||||
が Linus のツリーに入る時に自動的に stable チームに email される。
|
||||
- セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ
|
||||
きではなく、代わりに security@kernel.org のアドレスに送られる。
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ Environment variables
|
|||
KCPPFLAGS
|
||||
--------------------------------------------------
|
||||
Additional options to pass when preprocessing. The preprocessing options
|
||||
will be used in all cases where kbuild do preprocessing including
|
||||
will be used in all cases where kbuild does preprocessing including
|
||||
building C files and assembler files.
|
||||
|
||||
KAFLAGS
|
||||
|
@ -16,7 +16,7 @@ Additional options to the C compiler.
|
|||
|
||||
KBUILD_VERBOSE
|
||||
--------------------------------------------------
|
||||
Set the kbuild verbosity. Can be assinged same values as "V=...".
|
||||
Set the kbuild verbosity. Can be assigned same values as "V=...".
|
||||
See make help for the full list.
|
||||
Setting "V=..." takes precedence over KBUILD_VERBOSE.
|
||||
|
||||
|
@ -35,14 +35,14 @@ KBUILD_OUTPUT
|
|||
--------------------------------------------------
|
||||
Specify the output directory when building the kernel.
|
||||
The output directory can also be specificed using "O=...".
|
||||
Setting "O=..." takes precedence over KBUILD_OUTPUT
|
||||
Setting "O=..." takes precedence over KBUILD_OUTPUT.
|
||||
|
||||
ARCH
|
||||
--------------------------------------------------
|
||||
Set ARCH to the architecture to be built.
|
||||
In most cases the name of the architecture is the same as the
|
||||
directory name found in the arch/ directory.
|
||||
But some architectures suach as x86 and sparc has aliases.
|
||||
But some architectures such as x86 and sparc have aliases.
|
||||
x86: i386 for 32 bit, x86_64 for 64 bit
|
||||
sparc: sparc for 32 bit, sparc64 for 64 bit
|
||||
|
||||
|
@ -63,7 +63,7 @@ CF is often used on the command-line like this:
|
|||
INSTALL_PATH
|
||||
--------------------------------------------------
|
||||
INSTALL_PATH specifies where to place the updated kernel and system map
|
||||
images. Default is /boot, but you can set it to other values
|
||||
images. Default is /boot, but you can set it to other values.
|
||||
|
||||
|
||||
MODLIB
|
||||
|
@ -90,7 +90,7 @@ INSTALL_MOD_STRIP will used as the options to the strip command.
|
|||
|
||||
INSTALL_FW_PATH
|
||||
--------------------------------------------------
|
||||
INSTALL_FW_PATH specify where to install the firmware blobs.
|
||||
INSTALL_FW_PATH specifies where to install the firmware blobs.
|
||||
The default value is:
|
||||
|
||||
$(INSTALL_MOD_PATH)/lib/firmware
|
||||
|
@ -99,7 +99,7 @@ The value can be overridden in which case the default value is ignored.
|
|||
|
||||
INSTALL_HDR_PATH
|
||||
--------------------------------------------------
|
||||
INSTALL_HDR_PATH specify where to install user space headers when
|
||||
INSTALL_HDR_PATH specifies where to install user space headers when
|
||||
executing "make headers_*".
|
||||
The default value is:
|
||||
|
||||
|
@ -112,22 +112,23 @@ The value can be overridden in which case the default value is ignored.
|
|||
|
||||
KBUILD_MODPOST_WARN
|
||||
--------------------------------------------------
|
||||
KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined
|
||||
symbols in the final module linking stage.
|
||||
KBUILD_MODPOST_WARN can be set to avoid errors in case of undefined
|
||||
symbols in the final module linking stage. It changes such errors
|
||||
into warnings.
|
||||
|
||||
KBUILD_MODPOST_FINAL
|
||||
KBUILD_MODPOST_NOFINAL
|
||||
--------------------------------------------------
|
||||
KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
|
||||
This is solely usefull to speed up test compiles.
|
||||
This is solely useful to speed up test compiles.
|
||||
|
||||
KBUILD_EXTRA_SYMBOLS
|
||||
--------------------------------------------------
|
||||
For modules use symbols from another modules.
|
||||
For modules that use symbols from other modules.
|
||||
See more details in modules.txt.
|
||||
|
||||
ALLSOURCE_ARCHS
|
||||
--------------------------------------------------
|
||||
For tags/TAGS/cscope targets, you can specify more than one archs
|
||||
to be included in the databases, separated by blankspace. e.g.
|
||||
For tags/TAGS/cscope targets, you can specify more than one arch
|
||||
to be included in the databases, separated by blank space. E.g.:
|
||||
|
||||
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
|
||||
|
|
|
@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc scripts,
|
|||
and any comment so marked must be in kernel-doc format. Do not use
|
||||
"/**" to be begin a comment block unless the comment block contains
|
||||
kernel-doc formatted comments. The closing comment marker for
|
||||
kernel-doc comments can be either "*/" or "**/".
|
||||
kernel-doc comments can be either "*/" or "**/", but "*/" is
|
||||
preferred in the Linux kernel tree.
|
||||
|
||||
Kernel-doc comments should be placed just before the function
|
||||
or data structure being described.
|
||||
|
@ -63,7 +64,7 @@ Example kernel-doc function comment:
|
|||
* comment lines.
|
||||
*
|
||||
* The longer description can have multiple paragraphs.
|
||||
**/
|
||||
*/
|
||||
|
||||
The first line, with the short description, must be on a single line.
|
||||
|
||||
|
@ -85,7 +86,7 @@ Example kernel-doc data structure comment.
|
|||
* perhaps with more lines and words.
|
||||
*
|
||||
* Longer description of this structure.
|
||||
**/
|
||||
*/
|
||||
|
||||
The kernel-doc function comments describe each parameter to the
|
||||
function, in order, with the @name lines.
|
||||
|
|
|
@ -44,6 +44,7 @@ parameter is applicable:
|
|||
FB The frame buffer device is enabled.
|
||||
HW Appropriate hardware is enabled.
|
||||
IA-64 IA-64 architecture is enabled.
|
||||
IMA Integrity measurement architecture is enabled.
|
||||
IOSCHED More than one I/O scheduler is enabled.
|
||||
IP_PNP IP DHCP, BOOTP, or RARP is enabled.
|
||||
ISAPNP ISA PnP code is enabled.
|
||||
|
@ -114,7 +115,7 @@ In addition, the following text indicates that the option:
|
|||
Parameters denoted with BOOT are actually interpreted by the boot
|
||||
loader, and have no meaning to the kernel directly.
|
||||
Do not modify the syntax of boot loader parameters without extreme
|
||||
need or coordination with <Documentation/x86/i386/boot.txt>.
|
||||
need or coordination with <Documentation/x86/boot.txt>.
|
||||
|
||||
There are also arch-specific kernel-parameters not documented here.
|
||||
See for example <Documentation/x86/x86_64/boot-options.txt>.
|
||||
|
@ -134,7 +135,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
acpi= [HW,ACPI,X86-64,i386]
|
||||
Advanced Configuration and Power Interface
|
||||
Format: { force | off | ht | strict | noirq }
|
||||
Format: { force | off | ht | strict | noirq | rsdt }
|
||||
force -- enable ACPI if default was off
|
||||
off -- disable ACPI if default was on
|
||||
noirq -- do not use ACPI for IRQ routing
|
||||
|
@ -492,10 +493,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Default: 64
|
||||
|
||||
hpet= [X86-32,HPET] option to control HPET usage
|
||||
Format: { enable (default) | disable | force }
|
||||
Format: { enable (default) | disable | force |
|
||||
verbose }
|
||||
disable: disable HPET and use PIT instead
|
||||
force: allow force enabled of undocumented chips (ICH4,
|
||||
VIA, nVidia)
|
||||
verbose: show contents of HPET registers during setup
|
||||
|
||||
com20020= [HW,NET] ARCnet - COM20020 chipset
|
||||
Format:
|
||||
|
@ -577,9 +580,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
a memory unit (amount[KMG]). See also
|
||||
Documentation/kdump/kdump.txt for a example.
|
||||
|
||||
cs4232= [HW,OSS]
|
||||
Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq>
|
||||
|
||||
cs89x0_dma= [HW,NET]
|
||||
Format: <dma>
|
||||
|
||||
|
@ -732,10 +732,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Default value is 0.
|
||||
Value can be changed at runtime via /selinux/enforce.
|
||||
|
||||
es1371= [HW,OSS]
|
||||
Format: <spdif>,[<nomix>,[<amplifier>]]
|
||||
See also header of sound/oss/es1371.c.
|
||||
|
||||
ether= [HW,NET] Ethernet cards parameters
|
||||
This option is obsoleted by the "netdev=" option, which
|
||||
has equivalent usage. See its documentation for details.
|
||||
|
@ -836,6 +832,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
|
||||
terminal devices. Valid values: 0..8
|
||||
hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs.
|
||||
If specified, z/VM IUCV HVC accepts connections
|
||||
from listed z/VM user IDs only.
|
||||
|
||||
i8042.debug [HW] Toggle i8042 debug mode
|
||||
i8042.direct [HW] Put keyboard port into non-translated mode
|
||||
|
@ -875,8 +874,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
icn= [HW,ISDN]
|
||||
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
|
||||
|
||||
ide= [HW] (E)IDE subsystem
|
||||
Format: ide=nodma or ide=doubler
|
||||
ide-core.nodma= [HW] (E)IDE subsystem
|
||||
Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
|
||||
.vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom
|
||||
.chs .ignore_cable are additional options
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
|
||||
|
@ -907,6 +908,15 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
ihash_entries= [KNL]
|
||||
Set number of hash buckets for inode cache.
|
||||
|
||||
ima_audit= [IMA]
|
||||
Format: { "0" | "1" }
|
||||
0 -- integrity auditing messages. (Default)
|
||||
1 -- enable informational integrity auditing messages.
|
||||
|
||||
ima_hash= [IMA]
|
||||
Formt: { "sha1" | "md5" }
|
||||
default: "sha1"
|
||||
|
||||
in2000= [HW,SCSI]
|
||||
See header of drivers/scsi/in2000.c.
|
||||
|
||||
|
@ -944,6 +954,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
|
||||
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
|
||||
on
|
||||
Enable intel iommu driver.
|
||||
off
|
||||
Disable intel iommu driver.
|
||||
igfx_off [Default Off]
|
||||
|
@ -1819,11 +1831,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
autoconfiguration.
|
||||
Ranges are in pairs (memory base and size).
|
||||
|
||||
dynamic_printk Enables pr_debug()/dev_dbg() calls if
|
||||
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled.
|
||||
These can also be switched on/off via
|
||||
<debugfs>/dynamic_printk/modules
|
||||
|
||||
print-fatal-signals=
|
||||
[KNL] debug: print fatal signals
|
||||
print-fatal-signals=1: print segfault info to
|
||||
|
@ -2454,7 +2461,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
See Documentation/fb/modedb.txt.
|
||||
|
||||
vga= [BOOT,X86-32] Select a particular video mode
|
||||
See Documentation/x86/i386/boot.txt and
|
||||
See Documentation/x86/boot.txt and
|
||||
Documentation/svga.txt.
|
||||
Use vga=ask for menu.
|
||||
This is actually a boot loader parameter; the value is
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
ThinkPad ACPI Extras Driver
|
||||
|
||||
Version 0.21
|
||||
May 29th, 2008
|
||||
Version 0.22
|
||||
November 23rd, 2008
|
||||
|
||||
Borislav Deianov <borislav@users.sf.net>
|
||||
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
|
||||
|
@ -16,7 +16,8 @@ supported by the generic Linux ACPI drivers.
|
|||
This driver used to be named ibm-acpi until kernel 2.6.21 and release
|
||||
0.13-20070314. It used to be in the drivers/acpi tree, but it was
|
||||
moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
|
||||
2.6.22, and release 0.14.
|
||||
2.6.22, and release 0.14. It was moved to drivers/platform/x86 for
|
||||
kernel 2.6.29 and release 0.22.
|
||||
|
||||
The driver is named "thinkpad-acpi". In some places, like module
|
||||
names, "thinkpad_acpi" is used because of userspace issues.
|
||||
|
@ -1412,6 +1413,24 @@ Sysfs notes:
|
|||
rfkill controller switch "tpacpi_wwan_sw": refer to
|
||||
Documentation/rfkill.txt for details.
|
||||
|
||||
EXPERIMENTAL: UWB
|
||||
-----------------
|
||||
|
||||
This feature is marked EXPERIMENTAL because it has not been extensively
|
||||
tested and validated in various ThinkPad models yet. The feature may not
|
||||
work as expected. USE WITH CAUTION! To use this feature, you need to supply
|
||||
the experimental=1 parameter when loading the module.
|
||||
|
||||
sysfs rfkill class: switch "tpacpi_uwb_sw"
|
||||
|
||||
This feature exports an rfkill controller for the UWB device, if one is
|
||||
present and enabled in the BIOS.
|
||||
|
||||
Sysfs notes:
|
||||
|
||||
rfkill controller switch "tpacpi_uwb_sw": refer to
|
||||
Documentation/rfkill.txt for details.
|
||||
|
||||
Multiple Commands, Module Parameters
|
||||
------------------------------------
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
# This creates the demonstration utility "lguest" which runs a Linux guest.
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include
|
||||
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
|
||||
LDLIBS:=-lz
|
||||
|
||||
all: lguest
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 16 KiB |
2911
Documentation/logo.svg
Normal file
2911
Documentation/logo.svg
Normal file
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 303 KiB |
|
@ -1,13 +1,4 @@
|
|||
This is the full-colour version of the currently unofficial Linux logo
|
||||
("currently unofficial" just means that there has been no paperwork and
|
||||
that I have not really announced it yet). It was created by Larry Ewing,
|
||||
and is freely usable as long as you acknowledge Larry as the original
|
||||
artist.
|
||||
|
||||
Note that there are black-and-white versions of this available that
|
||||
scale down to smaller sizes and are better for letterheads or whatever
|
||||
you want to use it for: for the full range of logos take a look at
|
||||
Larry's web-page:
|
||||
|
||||
http://www.isc.tamu.edu/~lewing/linux/
|
||||
Tux is taking a three month sabbatical to work as a barber, so Tuz is
|
||||
standing in. He's taken pains to ensure you'll hardly notice.
|
||||
|
||||
Image by Andrew McGown and Josh Bush. Image is licensed CC BY-SA.
|
||||
|
|
|
@ -2,14 +2,14 @@
|
|||
IP-Aliasing:
|
||||
============
|
||||
|
||||
IP-aliases are additional IP-addresses/masks hooked up to a base
|
||||
interface by adding a colon and a string when running ifconfig.
|
||||
IP-aliases are an obsolete way to manage multiple IP-addresses/masks
|
||||
per interface. Newer tools such as iproute2 support multiple
|
||||
address/prefixes per interface, but aliases are still supported
|
||||
for backwards compatibility.
|
||||
|
||||
An alias is formed by adding a colon and a string when running ifconfig.
|
||||
This string is usually numeric, but this is not a must.
|
||||
|
||||
IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking)
|
||||
is configured in the kernel.
|
||||
|
||||
|
||||
o Alias creation.
|
||||
Alias creation is done by 'magic' interface naming: eg. to create a
|
||||
200.1.1.1 alias for eth0 ...
|
||||
|
@ -38,16 +38,3 @@ o Relationship with main device
|
|||
|
||||
If the base device is shut down the added aliases will be deleted
|
||||
too.
|
||||
|
||||
|
||||
Contact
|
||||
-------
|
||||
Please finger or e-mail me:
|
||||
Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
|
||||
|
||||
Updated by Erik Schoenfelder <schoenfr@gaertner.DE>
|
||||
|
||||
; local variables:
|
||||
; mode: indented-text
|
||||
; mode: auto-fill
|
||||
; end:
|
||||
|
|
|
@ -141,7 +141,8 @@ rx_ccid = 2
|
|||
Default CCID for the receiver-sender half-connection; see tx_ccid.
|
||||
|
||||
seq_window = 100
|
||||
The initial sequence window (sec. 7.5.2).
|
||||
The initial sequence window (sec. 7.5.2) of the sender. This influences
|
||||
the local ackno validity and the remote seqno validity windows (7.5.1).
|
||||
|
||||
tx_qlen = 5
|
||||
The size of the transmit buffer in packets. A value of 0 corresponds
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
ip_forward - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
not 0 - enabled
|
||||
|
||||
Forward Packets between interfaces.
|
||||
|
||||
|
@ -36,49 +36,49 @@ rt_cache_rebuild_count - INTEGER
|
|||
IP Fragmentation:
|
||||
|
||||
ipfrag_high_thresh - INTEGER
|
||||
Maximum memory used to reassemble IP fragments. When
|
||||
Maximum memory used to reassemble IP fragments. When
|
||||
ipfrag_high_thresh bytes of memory is allocated for this purpose,
|
||||
the fragment handler will toss packets until ipfrag_low_thresh
|
||||
is reached.
|
||||
|
||||
|
||||
ipfrag_low_thresh - INTEGER
|
||||
See ipfrag_high_thresh
|
||||
See ipfrag_high_thresh
|
||||
|
||||
ipfrag_time - INTEGER
|
||||
Time in seconds to keep an IP fragment in memory.
|
||||
Time in seconds to keep an IP fragment in memory.
|
||||
|
||||
ipfrag_secret_interval - INTEGER
|
||||
Regeneration interval (in seconds) of the hash secret (or lifetime
|
||||
Regeneration interval (in seconds) of the hash secret (or lifetime
|
||||
for the hash secret) for IP fragments.
|
||||
Default: 600
|
||||
|
||||
ipfrag_max_dist - INTEGER
|
||||
ipfrag_max_dist is a non-negative integer value which defines the
|
||||
maximum "disorder" which is allowed among fragments which share a
|
||||
common IP source address. Note that reordering of packets is
|
||||
not unusual, but if a large number of fragments arrive from a source
|
||||
IP address while a particular fragment queue remains incomplete, it
|
||||
probably indicates that one or more fragments belonging to that queue
|
||||
have been lost. When ipfrag_max_dist is positive, an additional check
|
||||
is done on fragments before they are added to a reassembly queue - if
|
||||
ipfrag_max_dist (or more) fragments have arrived from a particular IP
|
||||
address between additions to any IP fragment queue using that source
|
||||
address, it's presumed that one or more fragments in the queue are
|
||||
lost. The existing fragment queue will be dropped, and a new one
|
||||
ipfrag_max_dist is a non-negative integer value which defines the
|
||||
maximum "disorder" which is allowed among fragments which share a
|
||||
common IP source address. Note that reordering of packets is
|
||||
not unusual, but if a large number of fragments arrive from a source
|
||||
IP address while a particular fragment queue remains incomplete, it
|
||||
probably indicates that one or more fragments belonging to that queue
|
||||
have been lost. When ipfrag_max_dist is positive, an additional check
|
||||
is done on fragments before they are added to a reassembly queue - if
|
||||
ipfrag_max_dist (or more) fragments have arrived from a particular IP
|
||||
address between additions to any IP fragment queue using that source
|
||||
address, it's presumed that one or more fragments in the queue are
|
||||
lost. The existing fragment queue will be dropped, and a new one
|
||||
started. An ipfrag_max_dist value of zero disables this check.
|
||||
|
||||
Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can
|
||||
result in unnecessarily dropping fragment queues when normal
|
||||
reordering of packets occurs, which could lead to poor application
|
||||
performance. Using a very large value, e.g. 50000, increases the
|
||||
likelihood of incorrectly reassembling IP fragments that originate
|
||||
reordering of packets occurs, which could lead to poor application
|
||||
performance. Using a very large value, e.g. 50000, increases the
|
||||
likelihood of incorrectly reassembling IP fragments that originate
|
||||
from different IP datagrams, which could result in data corruption.
|
||||
Default: 64
|
||||
|
||||
INET peer storage:
|
||||
|
||||
inet_peer_threshold - INTEGER
|
||||
The approximate size of the storage. Starting from this threshold
|
||||
The approximate size of the storage. Starting from this threshold
|
||||
entries will be thrown aggressively. This threshold also determines
|
||||
entries' time-to-live and time intervals between garbage collection
|
||||
passes. More entries, less time-to-live, less GC interval.
|
||||
|
@ -105,7 +105,7 @@ inet_peer_gc_maxtime - INTEGER
|
|||
in effect under low (or absent) memory pressure on the pool.
|
||||
Measured in seconds.
|
||||
|
||||
TCP variables:
|
||||
TCP variables:
|
||||
|
||||
somaxconn - INTEGER
|
||||
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
|
||||
|
@ -310,7 +310,7 @@ tcp_orphan_retries - INTEGER
|
|||
|
||||
tcp_reordering - INTEGER
|
||||
Maximal reordering of packets in a TCP stream.
|
||||
Default: 3
|
||||
Default: 3
|
||||
|
||||
tcp_retrans_collapse - BOOLEAN
|
||||
Bug-to-bug compatibility with some broken printers.
|
||||
|
@ -521,7 +521,7 @@ IP Variables:
|
|||
|
||||
ip_local_port_range - 2 INTEGERS
|
||||
Defines the local port range that is used by TCP and UDP to
|
||||
choose the local port. The first number is the first, the
|
||||
choose the local port. The first number is the first, the
|
||||
second the last local port number. Default value depends on
|
||||
amount of memory available on the system:
|
||||
> 128Mb 32768-61000
|
||||
|
@ -594,12 +594,12 @@ icmp_errors_use_inbound_ifaddr - BOOLEAN
|
|||
|
||||
If zero, icmp error messages are sent with the primary address of
|
||||
the exiting interface.
|
||||
|
||||
|
||||
If non-zero, the message will be sent with the primary address of
|
||||
the interface that received the packet that caused the icmp error.
|
||||
This is the behaviour network many administrators will expect from
|
||||
a router. And it can make debugging complicated network layouts
|
||||
much easier.
|
||||
much easier.
|
||||
|
||||
Note that if no primary address exists for the interface selected,
|
||||
then the primary address of the first non-loopback interface that
|
||||
|
@ -611,7 +611,7 @@ igmp_max_memberships - INTEGER
|
|||
Change the maximum number of multicast groups we can subscribe to.
|
||||
Default: 20
|
||||
|
||||
conf/interface/* changes special settings per interface (where "interface" is
|
||||
conf/interface/* changes special settings per interface (where "interface" is
|
||||
the name of your network interface)
|
||||
conf/all/* is special, changes the settings for all interfaces
|
||||
|
||||
|
@ -625,11 +625,11 @@ log_martians - BOOLEAN
|
|||
accept_redirects - BOOLEAN
|
||||
Accept ICMP redirect messages.
|
||||
accept_redirects for the interface will be enabled if:
|
||||
- both conf/{all,interface}/accept_redirects are TRUE in the case forwarding
|
||||
for the interface is enabled
|
||||
- both conf/{all,interface}/accept_redirects are TRUE in the case
|
||||
forwarding for the interface is enabled
|
||||
or
|
||||
- at least one of conf/{all,interface}/accept_redirects is TRUE in the case
|
||||
forwarding for the interface is disabled
|
||||
- at least one of conf/{all,interface}/accept_redirects is TRUE in the
|
||||
case forwarding for the interface is disabled
|
||||
accept_redirects for the interface will be disabled otherwise
|
||||
default TRUE (host)
|
||||
FALSE (router)
|
||||
|
@ -640,8 +640,8 @@ forwarding - BOOLEAN
|
|||
mc_forwarding - BOOLEAN
|
||||
Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE
|
||||
and a multicast routing daemon is required.
|
||||
conf/all/mc_forwarding must also be set to TRUE to enable multicast routing
|
||||
for the interface
|
||||
conf/all/mc_forwarding must also be set to TRUE to enable multicast
|
||||
routing for the interface
|
||||
|
||||
medium_id - INTEGER
|
||||
Integer value used to differentiate the devices by the medium they
|
||||
|
@ -649,7 +649,7 @@ medium_id - INTEGER
|
|||
the broadcast packets are received only on one of them.
|
||||
The default value 0 means that the device is the only interface
|
||||
to its medium, value of -1 means that medium is not known.
|
||||
|
||||
|
||||
Currently, it is used to change the proxy_arp behavior:
|
||||
the proxy_arp feature is enabled for packets forwarded between
|
||||
two devices attached to different media.
|
||||
|
@ -699,16 +699,22 @@ accept_source_route - BOOLEAN
|
|||
default TRUE (router)
|
||||
FALSE (host)
|
||||
|
||||
rp_filter - BOOLEAN
|
||||
1 - do source validation by reversed path, as specified in RFC1812
|
||||
Recommended option for single homed hosts and stub network
|
||||
routers. Could cause troubles for complicated (not loop free)
|
||||
networks running a slow unreliable protocol (sort of RIP),
|
||||
or using static routes.
|
||||
|
||||
rp_filter - INTEGER
|
||||
0 - No source validation.
|
||||
1 - Strict mode as defined in RFC3704 Strict Reverse Path
|
||||
Each incoming packet is tested against the FIB and if the interface
|
||||
is not the best reverse path the packet check will fail.
|
||||
By default failed packets are discarded.
|
||||
2 - Loose mode as defined in RFC3704 Loose Reverse Path
|
||||
Each incoming packet's source address is also tested against the FIB
|
||||
and if the source address is not reachable via any interface
|
||||
the packet check will fail.
|
||||
|
||||
conf/all/rp_filter must also be set to TRUE to do source validation
|
||||
Current recommended practice in RFC3704 is to enable strict mode
|
||||
to prevent IP spoofing from DDos attacks. If using asymmetric routing
|
||||
or other complicated routing, then loose mode is recommended.
|
||||
|
||||
conf/all/rp_filter must also be set to non-zero to do source validation
|
||||
on the interface
|
||||
|
||||
Default value is 0. Note that some distributions enable it
|
||||
|
@ -782,6 +788,12 @@ arp_ignore - INTEGER
|
|||
The max value from conf/{all,interface}/arp_ignore is used
|
||||
when ARP request is received on the {interface}
|
||||
|
||||
arp_notify - BOOLEAN
|
||||
Define mode for notification of address and device changes.
|
||||
0 - (default): do nothing
|
||||
1 - Generate gratuitous arp replies when device is brought up
|
||||
or hardware address changes.
|
||||
|
||||
arp_accept - BOOLEAN
|
||||
Define behavior when gratuitous arp replies are received:
|
||||
0 - drop gratuitous arp frames
|
||||
|
@ -823,7 +835,7 @@ apply to IPv6 [XXX?].
|
|||
|
||||
bindv6only - BOOLEAN
|
||||
Default value for IPV6_V6ONLY socket option,
|
||||
which restricts use of the IPv6 socket to IPv6 communication
|
||||
which restricts use of the IPv6 socket to IPv6 communication
|
||||
only.
|
||||
TRUE: disable IPv4-mapped address feature
|
||||
FALSE: enable IPv4-mapped address feature
|
||||
|
@ -833,19 +845,19 @@ bindv6only - BOOLEAN
|
|||
IPv6 Fragmentation:
|
||||
|
||||
ip6frag_high_thresh - INTEGER
|
||||
Maximum memory used to reassemble IPv6 fragments. When
|
||||
Maximum memory used to reassemble IPv6 fragments. When
|
||||
ip6frag_high_thresh bytes of memory is allocated for this purpose,
|
||||
the fragment handler will toss packets until ip6frag_low_thresh
|
||||
is reached.
|
||||
|
||||
|
||||
ip6frag_low_thresh - INTEGER
|
||||
See ip6frag_high_thresh
|
||||
See ip6frag_high_thresh
|
||||
|
||||
ip6frag_time - INTEGER
|
||||
Time in seconds to keep an IPv6 fragment in memory.
|
||||
|
||||
ip6frag_secret_interval - INTEGER
|
||||
Regeneration interval (in seconds) of the hash secret (or lifetime
|
||||
Regeneration interval (in seconds) of the hash secret (or lifetime
|
||||
for the hash secret) for IPv6 fragments.
|
||||
Default: 600
|
||||
|
||||
|
@ -854,17 +866,17 @@ conf/default/*:
|
|||
|
||||
|
||||
conf/all/*:
|
||||
Change all the interface-specific settings.
|
||||
Change all the interface-specific settings.
|
||||
|
||||
[XXX: Other special features than forwarding?]
|
||||
|
||||
conf/all/forwarding - BOOLEAN
|
||||
Enable global IPv6 forwarding between all interfaces.
|
||||
Enable global IPv6 forwarding between all interfaces.
|
||||
|
||||
IPv4 and IPv6 work differently here; e.g. netfilter must be used
|
||||
IPv4 and IPv6 work differently here; e.g. netfilter must be used
|
||||
to control which interfaces may forward packets and which not.
|
||||
|
||||
This also sets all interfaces' Host/Router setting
|
||||
This also sets all interfaces' Host/Router setting
|
||||
'forwarding' to the specified value. See below for details.
|
||||
|
||||
This referred to as global forwarding.
|
||||
|
@ -875,12 +887,12 @@ proxy_ndp - BOOLEAN
|
|||
conf/interface/*:
|
||||
Change special settings per interface.
|
||||
|
||||
The functional behaviour for certain settings is different
|
||||
The functional behaviour for certain settings is different
|
||||
depending on whether local forwarding is enabled or not.
|
||||
|
||||
accept_ra - BOOLEAN
|
||||
Accept Router Advertisements; autoconfigure using them.
|
||||
|
||||
|
||||
Functional default: enabled if local forwarding is disabled.
|
||||
disabled if local forwarding is enabled.
|
||||
|
||||
|
@ -926,7 +938,7 @@ accept_source_route - INTEGER
|
|||
Default: 0
|
||||
|
||||
autoconf - BOOLEAN
|
||||
Autoconfigure addresses using Prefix Information in Router
|
||||
Autoconfigure addresses using Prefix Information in Router
|
||||
Advertisements.
|
||||
|
||||
Functional default: enabled if accept_ra_pinfo is enabled.
|
||||
|
@ -935,11 +947,11 @@ autoconf - BOOLEAN
|
|||
dad_transmits - INTEGER
|
||||
The amount of Duplicate Address Detection probes to send.
|
||||
Default: 1
|
||||
|
||||
forwarding - BOOLEAN
|
||||
Configure interface-specific Host/Router behaviour.
|
||||
|
||||
Note: It is recommended to have the same setting on all
|
||||
forwarding - BOOLEAN
|
||||
Configure interface-specific Host/Router behaviour.
|
||||
|
||||
Note: It is recommended to have the same setting on all
|
||||
interfaces; mixed router/host scenarios are rather uncommon.
|
||||
|
||||
FALSE:
|
||||
|
@ -948,13 +960,13 @@ forwarding - BOOLEAN
|
|||
|
||||
1. IsRouter flag is not set in Neighbour Advertisements.
|
||||
2. Router Solicitations are being sent when necessary.
|
||||
3. If accept_ra is TRUE (default), accept Router
|
||||
3. If accept_ra is TRUE (default), accept Router
|
||||
Advertisements (and do autoconfiguration).
|
||||
4. If accept_redirects is TRUE (default), accept Redirects.
|
||||
|
||||
TRUE:
|
||||
|
||||
If local forwarding is enabled, Router behaviour is assumed.
|
||||
If local forwarding is enabled, Router behaviour is assumed.
|
||||
This means exactly the reverse from the above:
|
||||
|
||||
1. IsRouter flag is set in Neighbour Advertisements.
|
||||
|
@ -989,7 +1001,7 @@ router_solicitation_interval - INTEGER
|
|||
Default: 4
|
||||
|
||||
router_solicitations - INTEGER
|
||||
Number of Router Solicitations to send until assuming no
|
||||
Number of Router Solicitations to send until assuming no
|
||||
routers are present.
|
||||
Default: 3
|
||||
|
||||
|
@ -1013,11 +1025,11 @@ temp_prefered_lft - INTEGER
|
|||
|
||||
max_desync_factor - INTEGER
|
||||
Maximum value for DESYNC_FACTOR, which is a random value
|
||||
that ensures that clients don't synchronize with each
|
||||
that ensures that clients don't synchronize with each
|
||||
other and generate new addresses at exactly the same time.
|
||||
value is in seconds.
|
||||
Default: 600
|
||||
|
||||
|
||||
regen_max_retry - INTEGER
|
||||
Number of attempts before give up attempting to generate
|
||||
valid temporary addresses.
|
||||
|
@ -1025,13 +1037,15 @@ regen_max_retry - INTEGER
|
|||
|
||||
max_addresses - INTEGER
|
||||
Number of maximum addresses per interface. 0 disables limitation.
|
||||
It is recommended not set too large value (or 0) because it would
|
||||
be too easy way to crash kernel to allow to create too much of
|
||||
It is recommended not set too large value (or 0) because it would
|
||||
be too easy way to crash kernel to allow to create too much of
|
||||
autoconfigured addresses.
|
||||
Default: 16
|
||||
|
||||
disable_ipv6 - BOOLEAN
|
||||
Disable IPv6 operation.
|
||||
Disable IPv6 operation. If accept_dad is set to 2, this value
|
||||
will be dynamically set to TRUE if DAD fails for the link-local
|
||||
address.
|
||||
Default: FALSE (enable IPv6 operation)
|
||||
|
||||
accept_dad - INTEGER
|
||||
|
|
35
Documentation/networking/ipv6.txt
Normal file
35
Documentation/networking/ipv6.txt
Normal file
|
@ -0,0 +1,35 @@
|
|||
|
||||
Options for the ipv6 module are supplied as parameters at load time.
|
||||
|
||||
Module options may be given as command line arguments to the insmod
|
||||
or modprobe command, but are usually specified in either the
|
||||
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
|
||||
distro-specific configuration file.
|
||||
|
||||
The available ipv6 module parameters are listed below. If a parameter
|
||||
is not specified the default value is used.
|
||||
|
||||
The parameters are as follows:
|
||||
|
||||
disable
|
||||
|
||||
Specifies whether to load the IPv6 module, but disable all
|
||||
its functionality. This might be used when another module
|
||||
has a dependency on the IPv6 module being loaded, but no
|
||||
IPv6 addresses or operations are desired.
|
||||
|
||||
The possible values and their effects are:
|
||||
|
||||
0
|
||||
IPv6 is enabled.
|
||||
|
||||
This is the default value.
|
||||
|
||||
1
|
||||
IPv6 is disabled.
|
||||
|
||||
No IPv6 addresses will be added to interfaces, and
|
||||
it will not be possible to open an IPv6 socket.
|
||||
|
||||
A reboot is required to enable IPv6.
|
||||
|
199
Documentation/networking/ixgbe.txt
Normal file
199
Documentation/networking/ixgbe.txt
Normal file
|
@ -0,0 +1,199 @@
|
|||
Linux Base Driver for 10 Gigabit PCI Express Intel(R) Network Connection
|
||||
========================================================================
|
||||
|
||||
March 10, 2009
|
||||
|
||||
|
||||
Contents
|
||||
========
|
||||
|
||||
- In This Release
|
||||
- Identifying Your Adapter
|
||||
- Building and Installation
|
||||
- Additional Configurations
|
||||
- Support
|
||||
|
||||
|
||||
|
||||
In This Release
|
||||
===============
|
||||
|
||||
This file describes the ixgbe Linux Base Driver for the 10 Gigabit PCI
|
||||
Express Intel(R) Network Connection. This driver includes support for
|
||||
Itanium(R)2-based systems.
|
||||
|
||||
For questions related to hardware requirements, refer to the documentation
|
||||
supplied with your 10 Gigabit adapter. All hardware requirements listed apply
|
||||
to use with Linux.
|
||||
|
||||
The following features are available in this kernel:
|
||||
- Native VLANs
|
||||
- Channel Bonding (teaming)
|
||||
- SNMP
|
||||
- Generic Receive Offload
|
||||
- Data Center Bridging
|
||||
|
||||
Channel Bonding documentation can be found in the Linux kernel source:
|
||||
/Documentation/networking/bonding.txt
|
||||
|
||||
Ethtool, lspci, and ifconfig can be used to display device and driver
|
||||
specific information.
|
||||
|
||||
|
||||
Identifying Your Adapter
|
||||
========================
|
||||
|
||||
This driver supports devices based on the 82598 controller and the 82599
|
||||
controller.
|
||||
|
||||
For specific information on identifying which adapter you have, please visit:
|
||||
|
||||
http://support.intel.com/support/network/sb/CS-008441.htm
|
||||
|
||||
|
||||
Building and Installation
|
||||
=========================
|
||||
|
||||
select m for "Intel(R) 10GbE PCI Express adapters support" located at:
|
||||
Location:
|
||||
-> Device Drivers
|
||||
-> Network device support (NETDEVICES [=y])
|
||||
-> Ethernet (10000 Mbit) (NETDEV_10000 [=y])
|
||||
|
||||
1. make modules & make modules_install
|
||||
|
||||
2. Load the module:
|
||||
|
||||
# modprobe ixgbe
|
||||
|
||||
The insmod command can be used if the full
|
||||
path to the driver module is specified. For example:
|
||||
|
||||
insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgbe/ixgbe.ko
|
||||
|
||||
With 2.6 based kernels also make sure that older ixgbe drivers are
|
||||
removed from the kernel, before loading the new module:
|
||||
|
||||
rmmod ixgbe; modprobe ixgbe
|
||||
|
||||
3. Assign an IP address to the interface by entering the following, where
|
||||
x is the interface number:
|
||||
|
||||
ifconfig ethx <IP_address>
|
||||
|
||||
4. Verify that the interface works. Enter the following, where <IP_address>
|
||||
is the IP address for another machine on the same subnet as the interface
|
||||
that is being tested:
|
||||
|
||||
ping <IP_address>
|
||||
|
||||
|
||||
Additional Configurations
|
||||
=========================
|
||||
|
||||
Viewing Link Messages
|
||||
---------------------
|
||||
Link messages will not be displayed to the console if the distribution is
|
||||
restricting system messages. In order to see network driver link messages on
|
||||
your console, set dmesg to eight by entering the following:
|
||||
|
||||
dmesg -n 8
|
||||
|
||||
NOTE: This setting is not saved across reboots.
|
||||
|
||||
|
||||
Jumbo Frames
|
||||
------------
|
||||
The driver supports Jumbo Frames for all adapters. Jumbo Frames support is
|
||||
enabled by changing the MTU to a value larger than the default of 1500.
|
||||
The maximum value for the MTU is 16110. Use the ifconfig command to
|
||||
increase the MTU size. For example:
|
||||
|
||||
ifconfig ethx mtu 9000 up
|
||||
|
||||
The maximum MTU setting for Jumbo Frames is 16110. This value coincides
|
||||
with the maximum Jumbo Frames size of 16128.
|
||||
|
||||
Generic Receive Offload, aka GRO
|
||||
--------------------------------
|
||||
The driver supports the in-kernel software implementation of GRO. GRO has
|
||||
shown that by coalescing Rx traffic into larger chunks of data, CPU
|
||||
utilization can be significantly reduced when under large Rx load. GRO is an
|
||||
evolution of the previously-used LRO interface. GRO is able to coalesce
|
||||
other protocols besides TCP. It's also safe to use with configurations that
|
||||
are problematic for LRO, namely bridging and iSCSI.
|
||||
|
||||
GRO is enabled by default in the driver. Future versions of ethtool will
|
||||
support disabling and re-enabling GRO on the fly.
|
||||
|
||||
|
||||
Data Center Bridging, aka DCB
|
||||
-----------------------------
|
||||
|
||||
DCB is a configuration Quality of Service implementation in hardware.
|
||||
It uses the VLAN priority tag (802.1p) to filter traffic. That means
|
||||
that there are 8 different priorities that traffic can be filtered into.
|
||||
It also enables priority flow control which can limit or eliminate the
|
||||
number of dropped packets during network stress. Bandwidth can be
|
||||
allocated to each of these priorities, which is enforced at the hardware
|
||||
level.
|
||||
|
||||
To enable DCB support in ixgbe, you must enable the DCB netlink layer to
|
||||
allow the userspace tools (see below) to communicate with the driver.
|
||||
This can be found in the kernel configuration here:
|
||||
|
||||
-> Networking support
|
||||
-> Networking options
|
||||
-> Data Center Bridging support
|
||||
|
||||
Once this is selected, DCB support must be selected for ixgbe. This can
|
||||
be found here:
|
||||
|
||||
-> Device Drivers
|
||||
-> Network device support (NETDEVICES [=y])
|
||||
-> Ethernet (10000 Mbit) (NETDEV_10000 [=y])
|
||||
-> Intel(R) 10GbE PCI Express adapters support
|
||||
-> Data Center Bridging (DCB) Support
|
||||
|
||||
After these options are selected, you must rebuild your kernel and your
|
||||
modules.
|
||||
|
||||
In order to use DCB, userspace tools must be downloaded and installed.
|
||||
The dcbd tools can be found at:
|
||||
|
||||
http://e1000.sf.net
|
||||
|
||||
|
||||
Ethtool
|
||||
-------
|
||||
The driver utilizes the ethtool interface for driver configuration and
|
||||
diagnostics, as well as displaying statistical information. Ethtool
|
||||
version 3.0 or later is required for this functionality.
|
||||
|
||||
The latest release of ethtool can be found from
|
||||
http://sourceforge.net/projects/gkernel.
|
||||
|
||||
|
||||
NAPI
|
||||
----
|
||||
|
||||
NAPI (Rx polling mode) is supported in the ixgbe driver. NAPI is enabled
|
||||
by default in the driver.
|
||||
|
||||
See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
|
||||
|
||||
|
||||
Support
|
||||
=======
|
||||
|
||||
For general information, go to the Intel support website at:
|
||||
|
||||
http://support.intel.com
|
||||
|
||||
or the Intel Wired Networking project hosted by Sourceforge at:
|
||||
|
||||
http://e1000.sourceforge.net
|
||||
|
||||
If an issue is identified with the released source code on the supported
|
||||
kernel with a supported adapter, email the specific information related
|
||||
to the issue to e1000-devel@lists.sf.net
|
|
@ -51,7 +51,8 @@ Built-in netconsole starts immediately after the TCP stack is
|
|||
initialized and attempts to bring up the supplied dev at the supplied
|
||||
address.
|
||||
|
||||
The remote host can run either 'netcat -u -l -p <port>' or syslogd.
|
||||
The remote host can run either 'netcat -u -l -p <port>',
|
||||
'nc -l -u <port>' or syslogd.
|
||||
|
||||
Dynamic reconfiguration:
|
||||
========================
|
||||
|
|
356
Documentation/networking/rds.txt
Normal file
356
Documentation/networking/rds.txt
Normal file
|
@ -0,0 +1,356 @@
|
|||
|
||||
Overview
|
||||
========
|
||||
|
||||
This readme tries to provide some background on the hows and whys of RDS,
|
||||
and will hopefully help you find your way around the code.
|
||||
|
||||
In addition, please see this email about RDS origins:
|
||||
http://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html
|
||||
|
||||
RDS Architecture
|
||||
================
|
||||
|
||||
RDS provides reliable, ordered datagram delivery by using a single
|
||||
reliable connection between any two nodes in the cluster. This allows
|
||||
applications to use a single socket to talk to any other process in the
|
||||
cluster - so in a cluster with N processes you need N sockets, in contrast
|
||||
to N*N if you use a connection-oriented socket transport like TCP.
|
||||
|
||||
RDS is not Infiniband-specific; it was designed to support different
|
||||
transports. The current implementation used to support RDS over TCP as well
|
||||
as IB. Work is in progress to support RDS over iWARP, and using DCE to
|
||||
guarantee no dropped packets on Ethernet, it may be possible to use RDS over
|
||||
UDP in the future.
|
||||
|
||||
The high-level semantics of RDS from the application's point of view are
|
||||
|
||||
* Addressing
|
||||
RDS uses IPv4 addresses and 16bit port numbers to identify
|
||||
the end point of a connection. All socket operations that involve
|
||||
passing addresses between kernel and user space generally
|
||||
use a struct sockaddr_in.
|
||||
|
||||
The fact that IPv4 addresses are used does not mean the underlying
|
||||
transport has to be IP-based. In fact, RDS over IB uses a
|
||||
reliable IB connection; the IP address is used exclusively to
|
||||
locate the remote node's GID (by ARPing for the given IP).
|
||||
|
||||
The port space is entirely independent of UDP, TCP or any other
|
||||
protocol.
|
||||
|
||||
* Socket interface
|
||||
RDS sockets work *mostly* as you would expect from a BSD
|
||||
socket. The next section will cover the details. At any rate,
|
||||
all I/O is performed through the standard BSD socket API.
|
||||
Some additions like zerocopy support are implemented through
|
||||
control messages, while other extensions use the getsockopt/
|
||||
setsockopt calls.
|
||||
|
||||
Sockets must be bound before you can send or receive data.
|
||||
This is needed because binding also selects a transport and
|
||||
attaches it to the socket. Once bound, the transport assignment
|
||||
does not change. RDS will tolerate IPs moving around (eg in
|
||||
a active-active HA scenario), but only as long as the address
|
||||
doesn't move to a different transport.
|
||||
|
||||
* sysctls
|
||||
RDS supports a number of sysctls in /proc/sys/net/rds
|
||||
|
||||
|
||||
Socket Interface
|
||||
================
|
||||
|
||||
AF_RDS, PF_RDS, SOL_RDS
|
||||
These constants haven't been assigned yet, because RDS isn't in
|
||||
mainline yet. Currently, the kernel module assigns some constant
|
||||
and publishes it to user space through two sysctl files
|
||||
/proc/sys/net/rds/pf_rds
|
||||
/proc/sys/net/rds/sol_rds
|
||||
|
||||
fd = socket(PF_RDS, SOCK_SEQPACKET, 0);
|
||||
This creates a new, unbound RDS socket.
|
||||
|
||||
setsockopt(SOL_SOCKET): send and receive buffer size
|
||||
RDS honors the send and receive buffer size socket options.
|
||||
You are not allowed to queue more than SO_SNDSIZE bytes to
|
||||
a socket. A message is queued when sendmsg is called, and
|
||||
it leaves the queue when the remote system acknowledges
|
||||
its arrival.
|
||||
|
||||
The SO_RCVSIZE option controls the maximum receive queue length.
|
||||
This is a soft limit rather than a hard limit - RDS will
|
||||
continue to accept and queue incoming messages, even if that
|
||||
takes the queue length over the limit. However, it will also
|
||||
mark the port as "congested" and send a congestion update to
|
||||
the source node. The source node is supposed to throttle any
|
||||
processes sending to this congested port.
|
||||
|
||||
bind(fd, &sockaddr_in, ...)
|
||||
This binds the socket to a local IP address and port, and a
|
||||
transport.
|
||||
|
||||
sendmsg(fd, ...)
|
||||
Sends a message to the indicated recipient. The kernel will
|
||||
transparently establish the underlying reliable connection
|
||||
if it isn't up yet.
|
||||
|
||||
An attempt to send a message that exceeds SO_SNDSIZE will
|
||||
return with -EMSGSIZE
|
||||
|
||||
An attempt to send a message that would take the total number
|
||||
of queued bytes over the SO_SNDSIZE threshold will return
|
||||
EAGAIN.
|
||||
|
||||
An attempt to send a message to a destination that is marked
|
||||
as "congested" will return ENOBUFS.
|
||||
|
||||
recvmsg(fd, ...)
|
||||
Receives a message that was queued to this socket. The sockets
|
||||
recv queue accounting is adjusted, and if the queue length
|
||||
drops below SO_SNDSIZE, the port is marked uncongested, and
|
||||
a congestion update is sent to all peers.
|
||||
|
||||
Applications can ask the RDS kernel module to receive
|
||||
notifications via control messages (for instance, there is a
|
||||
notification when a congestion update arrived, or when a RDMA
|
||||
operation completes). These notifications are received through
|
||||
the msg.msg_control buffer of struct msghdr. The format of the
|
||||
messages is described in manpages.
|
||||
|
||||
poll(fd)
|
||||
RDS supports the poll interface to allow the application
|
||||
to implement async I/O.
|
||||
|
||||
POLLIN handling is pretty straightforward. When there's an
|
||||
incoming message queued to the socket, or a pending notification,
|
||||
we signal POLLIN.
|
||||
|
||||
POLLOUT is a little harder. Since you can essentially send
|
||||
to any destination, RDS will always signal POLLOUT as long as
|
||||
there's room on the send queue (ie the number of bytes queued
|
||||
is less than the sendbuf size).
|
||||
|
||||
However, the kernel will refuse to accept messages to
|
||||
a destination marked congested - in this case you will loop
|
||||
forever if you rely on poll to tell you what to do.
|
||||
This isn't a trivial problem, but applications can deal with
|
||||
this - by using congestion notifications, and by checking for
|
||||
ENOBUFS errors returned by sendmsg.
|
||||
|
||||
setsockopt(SOL_RDS, RDS_CANCEL_SENT_TO, &sockaddr_in)
|
||||
This allows the application to discard all messages queued to a
|
||||
specific destination on this particular socket.
|
||||
|
||||
This allows the application to cancel outstanding messages if
|
||||
it detects a timeout. For instance, if it tried to send a message,
|
||||
and the remote host is unreachable, RDS will keep trying forever.
|
||||
The application may decide it's not worth it, and cancel the
|
||||
operation. In this case, it would use RDS_CANCEL_SENT_TO to
|
||||
nuke any pending messages.
|
||||
|
||||
|
||||
RDMA for RDS
|
||||
============
|
||||
|
||||
see rds-rdma(7) manpage (available in rds-tools)
|
||||
|
||||
|
||||
Congestion Notifications
|
||||
========================
|
||||
|
||||
see rds(7) manpage
|
||||
|
||||
|
||||
RDS Protocol
|
||||
============
|
||||
|
||||
Message header
|
||||
|
||||
The message header is a 'struct rds_header' (see rds.h):
|
||||
Fields:
|
||||
h_sequence:
|
||||
per-packet sequence number
|
||||
h_ack:
|
||||
piggybacked acknowledgment of last packet received
|
||||
h_len:
|
||||
length of data, not including header
|
||||
h_sport:
|
||||
source port
|
||||
h_dport:
|
||||
destination port
|
||||
h_flags:
|
||||
CONG_BITMAP - this is a congestion update bitmap
|
||||
ACK_REQUIRED - receiver must ack this packet
|
||||
RETRANSMITTED - packet has previously been sent
|
||||
h_credit:
|
||||
indicate to other end of connection that
|
||||
it has more credits available (i.e. there is
|
||||
more send room)
|
||||
h_padding[4]:
|
||||
unused, for future use
|
||||
h_csum:
|
||||
header checksum
|
||||
h_exthdr:
|
||||
optional data can be passed here. This is currently used for
|
||||
passing RDMA-related information.
|
||||
|
||||
ACK and retransmit handling
|
||||
|
||||
One might think that with reliable IB connections you wouldn't need
|
||||
to ack messages that have been received. The problem is that IB
|
||||
hardware generates an ack message before it has DMAed the message
|
||||
into memory. This creates a potential message loss if the HCA is
|
||||
disabled for any reason between when it sends the ack and before
|
||||
the message is DMAed and processed. This is only a potential issue
|
||||
if another HCA is available for fail-over.
|
||||
|
||||
Sending an ack immediately would allow the sender to free the sent
|
||||
message from their send queue quickly, but could cause excessive
|
||||
traffic to be used for acks. RDS piggybacks acks on sent data
|
||||
packets. Ack-only packets are reduced by only allowing one to be
|
||||
in flight at a time, and by the sender only asking for acks when
|
||||
its send buffers start to fill up. All retransmissions are also
|
||||
acked.
|
||||
|
||||
Flow Control
|
||||
|
||||
RDS's IB transport uses a credit-based mechanism to verify that
|
||||
there is space in the peer's receive buffers for more data. This
|
||||
eliminates the need for hardware retries on the connection.
|
||||
|
||||
Congestion
|
||||
|
||||
Messages waiting in the receive queue on the receiving socket
|
||||
are accounted against the sockets SO_RCVBUF option value. Only
|
||||
the payload bytes in the message are accounted for. If the
|
||||
number of bytes queued equals or exceeds rcvbuf then the socket
|
||||
is congested. All sends attempted to this socket's address
|
||||
should return block or return -EWOULDBLOCK.
|
||||
|
||||
Applications are expected to be reasonably tuned such that this
|
||||
situation very rarely occurs. An application encountering this
|
||||
"back-pressure" is considered a bug.
|
||||
|
||||
This is implemented by having each node maintain bitmaps which
|
||||
indicate which ports on bound addresses are congested. As the
|
||||
bitmap changes it is sent through all the connections which
|
||||
terminate in the local address of the bitmap which changed.
|
||||
|
||||
The bitmaps are allocated as connections are brought up. This
|
||||
avoids allocation in the interrupt handling path which queues
|
||||
sages on sockets. The dense bitmaps let transports send the
|
||||
entire bitmap on any bitmap change reasonably efficiently. This
|
||||
is much easier to implement than some finer-grained
|
||||
communication of per-port congestion. The sender does a very
|
||||
inexpensive bit test to test if the port it's about to send to
|
||||
is congested or not.
|
||||
|
||||
|
||||
RDS Transport Layer
|
||||
==================
|
||||
|
||||
As mentioned above, RDS is not IB-specific. Its code is divided
|
||||
into a general RDS layer and a transport layer.
|
||||
|
||||
The general layer handles the socket API, congestion handling,
|
||||
loopback, stats, usermem pinning, and the connection state machine.
|
||||
|
||||
The transport layer handles the details of the transport. The IB
|
||||
transport, for example, handles all the queue pairs, work requests,
|
||||
CM event handlers, and other Infiniband details.
|
||||
|
||||
|
||||
RDS Kernel Structures
|
||||
=====================
|
||||
|
||||
struct rds_message
|
||||
aka possibly "rds_outgoing", the generic RDS layer copies data to
|
||||
be sent and sets header fields as needed, based on the socket API.
|
||||
This is then queued for the individual connection and sent by the
|
||||
connection's transport.
|
||||
struct rds_incoming
|
||||
a generic struct referring to incoming data that can be handed from
|
||||
the transport to the general code and queued by the general code
|
||||
while the socket is awoken. It is then passed back to the transport
|
||||
code to handle the actual copy-to-user.
|
||||
struct rds_socket
|
||||
per-socket information
|
||||
struct rds_connection
|
||||
per-connection information
|
||||
struct rds_transport
|
||||
pointers to transport-specific functions
|
||||
struct rds_statistics
|
||||
non-transport-specific statistics
|
||||
struct rds_cong_map
|
||||
wraps the raw congestion bitmap, contains rbnode, waitq, etc.
|
||||
|
||||
Connection management
|
||||
=====================
|
||||
|
||||
Connections may be in UP, DOWN, CONNECTING, DISCONNECTING, and
|
||||
ERROR states.
|
||||
|
||||
The first time an attempt is made by an RDS socket to send data to
|
||||
a node, a connection is allocated and connected. That connection is
|
||||
then maintained forever -- if there are transport errors, the
|
||||
connection will be dropped and re-established.
|
||||
|
||||
Dropping a connection while packets are queued will cause queued or
|
||||
partially-sent datagrams to be retransmitted when the connection is
|
||||
re-established.
|
||||
|
||||
|
||||
The send path
|
||||
=============
|
||||
|
||||
rds_sendmsg()
|
||||
struct rds_message built from incoming data
|
||||
CMSGs parsed (e.g. RDMA ops)
|
||||
transport connection alloced and connected if not already
|
||||
rds_message placed on send queue
|
||||
send worker awoken
|
||||
rds_send_worker()
|
||||
calls rds_send_xmit() until queue is empty
|
||||
rds_send_xmit()
|
||||
transmits congestion map if one is pending
|
||||
may set ACK_REQUIRED
|
||||
calls transport to send either non-RDMA or RDMA message
|
||||
(RDMA ops never retransmitted)
|
||||
rds_ib_xmit()
|
||||
allocs work requests from send ring
|
||||
adds any new send credits available to peer (h_credits)
|
||||
maps the rds_message's sg list
|
||||
piggybacks ack
|
||||
populates work requests
|
||||
post send to connection's queue pair
|
||||
|
||||
The recv path
|
||||
=============
|
||||
|
||||
rds_ib_recv_cq_comp_handler()
|
||||
looks at write completions
|
||||
unmaps recv buffer from device
|
||||
no errors, call rds_ib_process_recv()
|
||||
refill recv ring
|
||||
rds_ib_process_recv()
|
||||
validate header checksum
|
||||
copy header to rds_ib_incoming struct if start of a new datagram
|
||||
add to ibinc's fraglist
|
||||
if competed datagram:
|
||||
update cong map if datagram was cong update
|
||||
call rds_recv_incoming() otherwise
|
||||
note if ack is required
|
||||
rds_recv_incoming()
|
||||
drop duplicate packets
|
||||
respond to pings
|
||||
find the sock associated with this datagram
|
||||
add to sock queue
|
||||
wake up sock
|
||||
do some congestion calculations
|
||||
rds_recvmsg
|
||||
copy data into user iovec
|
||||
handle CMSGs
|
||||
return to application
|
||||
|
||||
|
180
Documentation/networking/timestamping.txt
Normal file
180
Documentation/networking/timestamping.txt
Normal file
|
@ -0,0 +1,180 @@
|
|||
The existing interfaces for getting network packages time stamped are:
|
||||
|
||||
* SO_TIMESTAMP
|
||||
Generate time stamp for each incoming packet using the (not necessarily
|
||||
monotonous!) system time. Result is returned via recv_msg() in a
|
||||
control message as timeval (usec resolution).
|
||||
|
||||
* SO_TIMESTAMPNS
|
||||
Same time stamping mechanism as SO_TIMESTAMP, but returns result as
|
||||
timespec (nsec resolution).
|
||||
|
||||
* IP_MULTICAST_LOOP + SO_TIMESTAMP[NS]
|
||||
Only for multicasts: approximate send time stamp by receiving the looped
|
||||
packet and using its receive time stamp.
|
||||
|
||||
The following interface complements the existing ones: receive time
|
||||
stamps can be generated and returned for arbitrary packets and much
|
||||
closer to the point where the packet is really sent. Time stamps can
|
||||
be generated in software (as before) or in hardware (if the hardware
|
||||
has such a feature).
|
||||
|
||||
SO_TIMESTAMPING:
|
||||
|
||||
Instructs the socket layer which kind of information is wanted. The
|
||||
parameter is an integer with some of the following bits set. Setting
|
||||
other bits is an error and doesn't change the current state.
|
||||
|
||||
SOF_TIMESTAMPING_TX_HARDWARE: try to obtain send time stamp in hardware
|
||||
SOF_TIMESTAMPING_TX_SOFTWARE: if SOF_TIMESTAMPING_TX_HARDWARE is off or
|
||||
fails, then do it in software
|
||||
SOF_TIMESTAMPING_RX_HARDWARE: return the original, unmodified time stamp
|
||||
as generated by the hardware
|
||||
SOF_TIMESTAMPING_RX_SOFTWARE: if SOF_TIMESTAMPING_RX_HARDWARE is off or
|
||||
fails, then do it in software
|
||||
SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp
|
||||
SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to
|
||||
the system time base
|
||||
SOF_TIMESTAMPING_SOFTWARE: return system time stamp generated in
|
||||
software
|
||||
|
||||
SOF_TIMESTAMPING_TX/RX determine how time stamps are generated.
|
||||
SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the
|
||||
following control message:
|
||||
struct scm_timestamping {
|
||||
struct timespec systime;
|
||||
struct timespec hwtimetrans;
|
||||
struct timespec hwtimeraw;
|
||||
};
|
||||
|
||||
recvmsg() can be used to get this control message for regular incoming
|
||||
packets. For send time stamps the outgoing packet is looped back to
|
||||
the socket's error queue with the send time stamp(s) attached. It can
|
||||
be received with recvmsg(flags=MSG_ERRQUEUE). The call returns the
|
||||
original outgoing packet data including all headers preprended down to
|
||||
and including the link layer, the scm_timestamping control message and
|
||||
a sock_extended_err control message with ee_errno==ENOMSG and
|
||||
ee_origin==SO_EE_ORIGIN_TIMESTAMPING. A socket with such a pending
|
||||
bounced packet is ready for reading as far as select() is concerned.
|
||||
If the outgoing packet has to be fragmented, then only the first
|
||||
fragment is time stamped and returned to the sending socket.
|
||||
|
||||
All three values correspond to the same event in time, but were
|
||||
generated in different ways. Each of these values may be empty (= all
|
||||
zero), in which case no such value was available. If the application
|
||||
is not interested in some of these values, they can be left blank to
|
||||
avoid the potential overhead of calculating them.
|
||||
|
||||
systime is the value of the system time at that moment. This
|
||||
corresponds to the value also returned via SO_TIMESTAMP[NS]. If the
|
||||
time stamp was generated by hardware, then this field is
|
||||
empty. Otherwise it is filled in if SOF_TIMESTAMPING_SOFTWARE is
|
||||
set.
|
||||
|
||||
hwtimeraw is the original hardware time stamp. Filled in if
|
||||
SOF_TIMESTAMPING_RAW_HARDWARE is set. No assumptions about its
|
||||
relation to system time should be made.
|
||||
|
||||
hwtimetrans is the hardware time stamp transformed so that it
|
||||
corresponds as good as possible to system time. This correlation is
|
||||
not perfect; as a consequence, sorting packets received via different
|
||||
NICs by their hwtimetrans may differ from the order in which they were
|
||||
received. hwtimetrans may be non-monotonic even for the same NIC.
|
||||
Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support
|
||||
by the network device and will be empty without that support.
|
||||
|
||||
|
||||
SIOCSHWTSTAMP:
|
||||
|
||||
Hardware time stamping must also be initialized for each device driver
|
||||
that is expected to do hardware time stamping. The parameter is:
|
||||
|
||||
struct hwtstamp_config {
|
||||
int flags; /* no flags defined right now, must be zero */
|
||||
int tx_type; /* HWTSTAMP_TX_* */
|
||||
int rx_filter; /* HWTSTAMP_FILTER_* */
|
||||
};
|
||||
|
||||
Desired behavior is passed into the kernel and to a specific device by
|
||||
calling ioctl(SIOCSHWTSTAMP) with a pointer to a struct ifreq whose
|
||||
ifr_data points to a struct hwtstamp_config. The tx_type and
|
||||
rx_filter are hints to the driver what it is expected to do. If
|
||||
the requested fine-grained filtering for incoming packets is not
|
||||
supported, the driver may time stamp more than just the requested types
|
||||
of packets.
|
||||
|
||||
A driver which supports hardware time stamping shall update the struct
|
||||
with the actual, possibly more permissive configuration. If the
|
||||
requested packets cannot be time stamped, then nothing should be
|
||||
changed and ERANGE shall be returned (in contrast to EINVAL, which
|
||||
indicates that SIOCSHWTSTAMP is not supported at all).
|
||||
|
||||
Only a processes with admin rights may change the configuration. User
|
||||
space is responsible to ensure that multiple processes don't interfere
|
||||
with each other and that the settings are reset.
|
||||
|
||||
/* possible values for hwtstamp_config->tx_type */
|
||||
enum {
|
||||
/*
|
||||
* no outgoing packet will need hardware time stamping;
|
||||
* should a packet arrive which asks for it, no hardware
|
||||
* time stamping will be done
|
||||
*/
|
||||
HWTSTAMP_TX_OFF,
|
||||
|
||||
/*
|
||||
* enables hardware time stamping for outgoing packets;
|
||||
* the sender of the packet decides which are to be
|
||||
* time stamped by setting SOF_TIMESTAMPING_TX_SOFTWARE
|
||||
* before sending the packet
|
||||
*/
|
||||
HWTSTAMP_TX_ON,
|
||||
};
|
||||
|
||||
/* possible values for hwtstamp_config->rx_filter */
|
||||
enum {
|
||||
/* time stamp no incoming packet at all */
|
||||
HWTSTAMP_FILTER_NONE,
|
||||
|
||||
/* time stamp any incoming packet */
|
||||
HWTSTAMP_FILTER_ALL,
|
||||
|
||||
/* return value: time stamp all packets requested plus some others */
|
||||
HWTSTAMP_FILTER_SOME,
|
||||
|
||||
/* PTP v1, UDP, any kind of event packet */
|
||||
HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
|
||||
|
||||
...
|
||||
};
|
||||
|
||||
|
||||
DEVICE IMPLEMENTATION
|
||||
|
||||
A driver which supports hardware time stamping must support the
|
||||
SIOCSHWTSTAMP ioctl. Time stamps for received packets must be stored
|
||||
in the skb with skb_hwtstamp_set().
|
||||
|
||||
Time stamps for outgoing packets are to be generated as follows:
|
||||
- In hard_start_xmit(), check if skb_hwtstamp_check_tx_hardware()
|
||||
returns non-zero. If yes, then the driver is expected
|
||||
to do hardware time stamping.
|
||||
- If this is possible for the skb and requested, then declare
|
||||
that the driver is doing the time stamping by calling
|
||||
skb_hwtstamp_tx_in_progress(). A driver not supporting
|
||||
hardware time stamping doesn't do that. A driver must never
|
||||
touch sk_buff::tstamp! It is used to store how time stamping
|
||||
for an outgoing packets is to be done.
|
||||
- As soon as the driver has sent the packet and/or obtained a
|
||||
hardware time stamp for it, it passes the time stamp back by
|
||||
calling skb_hwtstamp_tx() with the original skb, the raw
|
||||
hardware time stamp and a handle to the device (necessary
|
||||
to convert the hardware time stamp to system time). If obtaining
|
||||
the hardware time stamp somehow fails, then the driver should
|
||||
not fall back to software time stamping. The rationale is that
|
||||
this would occur at a later time in the processing pipeline
|
||||
than other software time stamping and therefore could lead
|
||||
to unexpected deltas between time stamps.
|
||||
- If the driver did not call skb_hwtstamp_tx_in_progress(), then
|
||||
dev_hard_start_xmit() checks whether software time stamping
|
||||
is wanted as fallback and potentially generates the time stamp.
|
1
Documentation/networking/timestamping/.gitignore
vendored
Normal file
1
Documentation/networking/timestamping/.gitignore
vendored
Normal file
|
@ -0,0 +1 @@
|
|||
timestamping
|
6
Documentation/networking/timestamping/Makefile
Normal file
6
Documentation/networking/timestamping/Makefile
Normal file
|
@ -0,0 +1,6 @@
|
|||
CPPFLAGS = -I../../../include
|
||||
|
||||
timestamping: timestamping.c
|
||||
|
||||
clean:
|
||||
rm -f timestamping
|
533
Documentation/networking/timestamping/timestamping.c
Normal file
533
Documentation/networking/timestamping/timestamping.c
Normal file
|
@ -0,0 +1,533 @@
|
|||
/*
|
||||
* This program demonstrates how the various time stamping features in
|
||||
* the Linux kernel work. It emulates the behavior of a PTP
|
||||
* implementation in stand-alone master mode by sending PTPv1 Sync
|
||||
* multicasts once every second. It looks for similar packets, but
|
||||
* beyond that doesn't actually implement PTP.
|
||||
*
|
||||
* Outgoing packets are time stamped with SO_TIMESTAMPING with or
|
||||
* without hardware support.
|
||||
*
|
||||
* Incoming packets are time stamped with SO_TIMESTAMPING with or
|
||||
* without hardware support, SIOCGSTAMP[NS] (per-socket time stamp) and
|
||||
* SO_TIMESTAMP[NS].
|
||||
*
|
||||
* Copyright (C) 2009 Intel Corporation.
|
||||
* Author: Patrick Ohly <patrick.ohly@intel.com>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify it
|
||||
* under the terms and conditions of the GNU General Public License,
|
||||
* version 2, as published by the Free Software Foundation.
|
||||
*
|
||||
* This program is distributed in the hope it will be useful, but WITHOUT
|
||||
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
||||
* FITNESS FOR A PARTICULAR PURPOSE. * See the GNU General Public License for
|
||||
* more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License along with
|
||||
* this program; if not, write to the Free Software Foundation, Inc.,
|
||||
* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <errno.h>
|
||||
#include <string.h>
|
||||
|
||||
#include <sys/time.h>
|
||||
#include <sys/socket.h>
|
||||
#include <sys/select.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <arpa/inet.h>
|
||||
#include <net/if.h>
|
||||
|
||||
#include "asm/types.h"
|
||||
#include "linux/net_tstamp.h"
|
||||
#include "linux/errqueue.h"
|
||||
|
||||
#ifndef SO_TIMESTAMPING
|
||||
# define SO_TIMESTAMPING 37
|
||||
# define SCM_TIMESTAMPING SO_TIMESTAMPING
|
||||
#endif
|
||||
|
||||
#ifndef SO_TIMESTAMPNS
|
||||
# define SO_TIMESTAMPNS 35
|
||||
#endif
|
||||
|
||||
#ifndef SIOCGSTAMPNS
|
||||
# define SIOCGSTAMPNS 0x8907
|
||||
#endif
|
||||
|
||||
#ifndef SIOCSHWTSTAMP
|
||||
# define SIOCSHWTSTAMP 0x89b0
|
||||
#endif
|
||||
|
||||
static void usage(const char *error)
|
||||
{
|
||||
if (error)
|
||||
printf("invalid option: %s\n", error);
|
||||
printf("timestamping interface option*\n\n"
|
||||
"Options:\n"
|
||||
" IP_MULTICAST_LOOP - looping outgoing multicasts\n"
|
||||
" SO_TIMESTAMP - normal software time stamping, ms resolution\n"
|
||||
" SO_TIMESTAMPNS - more accurate software time stamping\n"
|
||||
" SOF_TIMESTAMPING_TX_HARDWARE - hardware time stamping of outgoing packets\n"
|
||||
" SOF_TIMESTAMPING_TX_SOFTWARE - software fallback for outgoing packets\n"
|
||||
" SOF_TIMESTAMPING_RX_HARDWARE - hardware time stamping of incoming packets\n"
|
||||
" SOF_TIMESTAMPING_RX_SOFTWARE - software fallback for incoming packets\n"
|
||||
" SOF_TIMESTAMPING_SOFTWARE - request reporting of software time stamps\n"
|
||||
" SOF_TIMESTAMPING_SYS_HARDWARE - request reporting of transformed HW time stamps\n"
|
||||
" SOF_TIMESTAMPING_RAW_HARDWARE - request reporting of raw HW time stamps\n"
|
||||
" SIOCGSTAMP - check last socket time stamp\n"
|
||||
" SIOCGSTAMPNS - more accurate socket time stamp\n");
|
||||
exit(1);
|
||||
}
|
||||
|
||||
static void bail(const char *error)
|
||||
{
|
||||
printf("%s: %s\n", error, strerror(errno));
|
||||
exit(1);
|
||||
}
|
||||
|
||||
static const unsigned char sync[] = {
|
||||
0x00, 0x01, 0x00, 0x01,
|
||||
0x5f, 0x44, 0x46, 0x4c,
|
||||
0x54, 0x00, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x01, 0x01,
|
||||
|
||||
/* fake uuid */
|
||||
0x00, 0x01,
|
||||
0x02, 0x03, 0x04, 0x05,
|
||||
|
||||
0x00, 0x01, 0x00, 0x37,
|
||||
0x00, 0x00, 0x00, 0x08,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x49, 0x05, 0xcd, 0x01,
|
||||
0x29, 0xb1, 0x8d, 0xb0,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x00, 0x01,
|
||||
|
||||
/* fake uuid */
|
||||
0x00, 0x01,
|
||||
0x02, 0x03, 0x04, 0x05,
|
||||
|
||||
0x00, 0x00, 0x00, 0x37,
|
||||
0x00, 0x00, 0x00, 0x04,
|
||||
0x44, 0x46, 0x4c, 0x54,
|
||||
0x00, 0x00, 0xf0, 0x60,
|
||||
0x00, 0x01, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x01,
|
||||
0x00, 0x00, 0xf0, 0x60,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x04,
|
||||
0x44, 0x46, 0x4c, 0x54,
|
||||
0x00, 0x01,
|
||||
|
||||
/* fake uuid */
|
||||
0x00, 0x01,
|
||||
0x02, 0x03, 0x04, 0x05,
|
||||
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x00,
|
||||
0x00, 0x00, 0x00, 0x00
|
||||
};
|
||||
|
||||
static void sendpacket(int sock, struct sockaddr *addr, socklen_t addr_len)
|
||||
{
|
||||
struct timeval now;
|
||||
int res;
|
||||
|
||||
res = sendto(sock, sync, sizeof(sync), 0,
|
||||
addr, addr_len);
|
||||
gettimeofday(&now, 0);
|
||||
if (res < 0)
|
||||
printf("%s: %s\n", "send", strerror(errno));
|
||||
else
|
||||
printf("%ld.%06ld: sent %d bytes\n",
|
||||
(long)now.tv_sec, (long)now.tv_usec,
|
||||
res);
|
||||
}
|
||||
|
||||
static void printpacket(struct msghdr *msg, int res,
|
||||
char *data,
|
||||
int sock, int recvmsg_flags,
|
||||
int siocgstamp, int siocgstampns)
|
||||
{
|
||||
struct sockaddr_in *from_addr = (struct sockaddr_in *)msg->msg_name;
|
||||
struct cmsghdr *cmsg;
|
||||
struct timeval tv;
|
||||
struct timespec ts;
|
||||
struct timeval now;
|
||||
|
||||
gettimeofday(&now, 0);
|
||||
|
||||
printf("%ld.%06ld: received %s data, %d bytes from %s, %d bytes control messages\n",
|
||||
(long)now.tv_sec, (long)now.tv_usec,
|
||||
(recvmsg_flags & MSG_ERRQUEUE) ? "error" : "regular",
|
||||
res,
|
||||
inet_ntoa(from_addr->sin_addr),
|
||||
msg->msg_controllen);
|
||||
for (cmsg = CMSG_FIRSTHDR(msg);
|
||||
cmsg;
|
||||
cmsg = CMSG_NXTHDR(msg, cmsg)) {
|
||||
printf(" cmsg len %d: ", cmsg->cmsg_len);
|
||||
switch (cmsg->cmsg_level) {
|
||||
case SOL_SOCKET:
|
||||
printf("SOL_SOCKET ");
|
||||
switch (cmsg->cmsg_type) {
|
||||
case SO_TIMESTAMP: {
|
||||
struct timeval *stamp =
|
||||
(struct timeval *)CMSG_DATA(cmsg);
|
||||
printf("SO_TIMESTAMP %ld.%06ld",
|
||||
(long)stamp->tv_sec,
|
||||
(long)stamp->tv_usec);
|
||||
break;
|
||||
}
|
||||
case SO_TIMESTAMPNS: {
|
||||
struct timespec *stamp =
|
||||
(struct timespec *)CMSG_DATA(cmsg);
|
||||
printf("SO_TIMESTAMPNS %ld.%09ld",
|
||||
(long)stamp->tv_sec,
|
||||
(long)stamp->tv_nsec);
|
||||
break;
|
||||
}
|
||||
case SO_TIMESTAMPING: {
|
||||
struct timespec *stamp =
|
||||
(struct timespec *)CMSG_DATA(cmsg);
|
||||
printf("SO_TIMESTAMPING ");
|
||||
printf("SW %ld.%09ld ",
|
||||
(long)stamp->tv_sec,
|
||||
(long)stamp->tv_nsec);
|
||||
stamp++;
|
||||
printf("HW transformed %ld.%09ld ",
|
||||
(long)stamp->tv_sec,
|
||||
(long)stamp->tv_nsec);
|
||||
stamp++;
|
||||
printf("HW raw %ld.%09ld",
|
||||
(long)stamp->tv_sec,
|
||||
(long)stamp->tv_nsec);
|
||||
break;
|
||||
}
|
||||
default:
|
||||
printf("type %d", cmsg->cmsg_type);
|
||||
break;
|
||||
}
|
||||
break;
|
||||
case IPPROTO_IP:
|
||||
printf("IPPROTO_IP ");
|
||||
switch (cmsg->cmsg_type) {
|
||||
case IP_RECVERR: {
|
||||
struct sock_extended_err *err =
|
||||
(struct sock_extended_err *)CMSG_DATA(cmsg);
|
||||
printf("IP_RECVERR ee_errno '%s' ee_origin %d => %s",
|
||||
strerror(err->ee_errno),
|
||||
err->ee_origin,
|
||||
#ifdef SO_EE_ORIGIN_TIMESTAMPING
|
||||
err->ee_origin == SO_EE_ORIGIN_TIMESTAMPING ?
|
||||
"bounced packet" : "unexpected origin"
|
||||
#else
|
||||
"probably SO_EE_ORIGIN_TIMESTAMPING"
|
||||
#endif
|
||||
);
|
||||
if (res < sizeof(sync))
|
||||
printf(" => truncated data?!");
|
||||
else if (!memcmp(sync, data + res - sizeof(sync),
|
||||
sizeof(sync)))
|
||||
printf(" => GOT OUR DATA BACK (HURRAY!)");
|
||||
break;
|
||||
}
|
||||
case IP_PKTINFO: {
|
||||
struct in_pktinfo *pktinfo =
|
||||
(struct in_pktinfo *)CMSG_DATA(cmsg);
|
||||
printf("IP_PKTINFO interface index %u",
|
||||
pktinfo->ipi_ifindex);
|
||||
break;
|
||||
}
|
||||
default:
|
||||
printf("type %d", cmsg->cmsg_type);
|
||||
break;
|
||||
}
|
||||
break;
|
||||
default:
|
||||
printf("level %d type %d",
|
||||
cmsg->cmsg_level,
|
||||
cmsg->cmsg_type);
|
||||
break;
|
||||
}
|
||||
printf("\n");
|
||||
}
|
||||
|
||||
if (siocgstamp) {
|
||||
if (ioctl(sock, SIOCGSTAMP, &tv))
|
||||
printf(" %s: %s\n", "SIOCGSTAMP", strerror(errno));
|
||||
else
|
||||
printf("SIOCGSTAMP %ld.%06ld\n",
|
||||
(long)tv.tv_sec,
|
||||
(long)tv.tv_usec);
|
||||
}
|
||||
if (siocgstampns) {
|
||||
if (ioctl(sock, SIOCGSTAMPNS, &ts))
|
||||
printf(" %s: %s\n", "SIOCGSTAMPNS", strerror(errno));
|
||||
else
|
||||
printf("SIOCGSTAMPNS %ld.%09ld\n",
|
||||
(long)ts.tv_sec,
|
||||
(long)ts.tv_nsec);
|
||||
}
|
||||
}
|
||||
|
||||
static void recvpacket(int sock, int recvmsg_flags,
|
||||
int siocgstamp, int siocgstampns)
|
||||
{
|
||||
char data[256];
|
||||
struct msghdr msg;
|
||||
struct iovec entry;
|
||||
struct sockaddr_in from_addr;
|
||||
struct {
|
||||
struct cmsghdr cm;
|
||||
char control[512];
|
||||
} control;
|
||||
int res;
|
||||
|
||||
memset(&msg, 0, sizeof(msg));
|
||||
msg.msg_iov = &entry;
|
||||
msg.msg_iovlen = 1;
|
||||
entry.iov_base = data;
|
||||
entry.iov_len = sizeof(data);
|
||||
msg.msg_name = (caddr_t)&from_addr;
|
||||
msg.msg_namelen = sizeof(from_addr);
|
||||
msg.msg_control = &control;
|
||||
msg.msg_controllen = sizeof(control);
|
||||
|
||||
res = recvmsg(sock, &msg, recvmsg_flags|MSG_DONTWAIT);
|
||||
if (res < 0) {
|
||||
printf("%s %s: %s\n",
|
||||
"recvmsg",
|
||||
(recvmsg_flags & MSG_ERRQUEUE) ? "error" : "regular",
|
||||
strerror(errno));
|
||||
} else {
|
||||
printpacket(&msg, res, data,
|
||||
sock, recvmsg_flags,
|
||||
siocgstamp, siocgstampns);
|
||||
}
|
||||
}
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
int so_timestamping_flags = 0;
|
||||
int so_timestamp = 0;
|
||||
int so_timestampns = 0;
|
||||
int siocgstamp = 0;
|
||||
int siocgstampns = 0;
|
||||
int ip_multicast_loop = 0;
|
||||
char *interface;
|
||||
int i;
|
||||
int enabled = 1;
|
||||
int sock;
|
||||
struct ifreq device;
|
||||
struct ifreq hwtstamp;
|
||||
struct hwtstamp_config hwconfig, hwconfig_requested;
|
||||
struct sockaddr_in addr;
|
||||
struct ip_mreq imr;
|
||||
struct in_addr iaddr;
|
||||
int val;
|
||||
socklen_t len;
|
||||
struct timeval next;
|
||||
|
||||
if (argc < 2)
|
||||
usage(0);
|
||||
interface = argv[1];
|
||||
|
||||
for (i = 2; i < argc; i++) {
|
||||
if (!strcasecmp(argv[i], "SO_TIMESTAMP"))
|
||||
so_timestamp = 1;
|
||||
else if (!strcasecmp(argv[i], "SO_TIMESTAMPNS"))
|
||||
so_timestampns = 1;
|
||||
else if (!strcasecmp(argv[i], "SIOCGSTAMP"))
|
||||
siocgstamp = 1;
|
||||
else if (!strcasecmp(argv[i], "SIOCGSTAMPNS"))
|
||||
siocgstampns = 1;
|
||||
else if (!strcasecmp(argv[i], "IP_MULTICAST_LOOP"))
|
||||
ip_multicast_loop = 1;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_TX_HARDWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_TX_HARDWARE;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_TX_SOFTWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_TX_SOFTWARE;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RX_HARDWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_RX_HARDWARE;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RX_SOFTWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_RX_SOFTWARE;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_SOFTWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_SOFTWARE;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_SYS_HARDWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_SYS_HARDWARE;
|
||||
else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RAW_HARDWARE"))
|
||||
so_timestamping_flags |= SOF_TIMESTAMPING_RAW_HARDWARE;
|
||||
else
|
||||
usage(argv[i]);
|
||||
}
|
||||
|
||||
sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
|
||||
if (socket < 0)
|
||||
bail("socket");
|
||||
|
||||
memset(&device, 0, sizeof(device));
|
||||
strncpy(device.ifr_name, interface, sizeof(device.ifr_name));
|
||||
if (ioctl(sock, SIOCGIFADDR, &device) < 0)
|
||||
bail("getting interface IP address");
|
||||
|
||||
memset(&hwtstamp, 0, sizeof(hwtstamp));
|
||||
strncpy(hwtstamp.ifr_name, interface, sizeof(hwtstamp.ifr_name));
|
||||
hwtstamp.ifr_data = (void *)&hwconfig;
|
||||
memset(&hwconfig, 0, sizeof(&hwconfig));
|
||||
hwconfig.tx_type =
|
||||
(so_timestamping_flags & SOF_TIMESTAMPING_TX_HARDWARE) ?
|
||||
HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
|
||||
hwconfig.rx_filter =
|
||||
(so_timestamping_flags & SOF_TIMESTAMPING_RX_HARDWARE) ?
|
||||
HWTSTAMP_FILTER_PTP_V1_L4_SYNC : HWTSTAMP_FILTER_NONE;
|
||||
hwconfig_requested = hwconfig;
|
||||
if (ioctl(sock, SIOCSHWTSTAMP, &hwtstamp) < 0) {
|
||||
if ((errno == EINVAL || errno == ENOTSUP) &&
|
||||
hwconfig_requested.tx_type == HWTSTAMP_TX_OFF &&
|
||||
hwconfig_requested.rx_filter == HWTSTAMP_FILTER_NONE)
|
||||
printf("SIOCSHWTSTAMP: disabling hardware time stamping not possible\n");
|
||||
else
|
||||
bail("SIOCSHWTSTAMP");
|
||||
}
|
||||
printf("SIOCSHWTSTAMP: tx_type %d requested, got %d; rx_filter %d requested, got %d\n",
|
||||
hwconfig_requested.tx_type, hwconfig.tx_type,
|
||||
hwconfig_requested.rx_filter, hwconfig.rx_filter);
|
||||
|
||||
/* bind to PTP port */
|
||||
addr.sin_family = AF_INET;
|
||||
addr.sin_addr.s_addr = htonl(INADDR_ANY);
|
||||
addr.sin_port = htons(319 /* PTP event port */);
|
||||
if (bind(sock,
|
||||
(struct sockaddr *)&addr,
|
||||
sizeof(struct sockaddr_in)) < 0)
|
||||
bail("bind");
|
||||
|
||||
/* set multicast group for outgoing packets */
|
||||
inet_aton("224.0.1.130", &iaddr); /* alternate PTP domain 1 */
|
||||
addr.sin_addr = iaddr;
|
||||
imr.imr_multiaddr.s_addr = iaddr.s_addr;
|
||||
imr.imr_interface.s_addr =
|
||||
((struct sockaddr_in *)&device.ifr_addr)->sin_addr.s_addr;
|
||||
if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF,
|
||||
&imr.imr_interface.s_addr, sizeof(struct in_addr)) < 0)
|
||||
bail("set multicast");
|
||||
|
||||
/* join multicast group, loop our own packet */
|
||||
if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP,
|
||||
&imr, sizeof(struct ip_mreq)) < 0)
|
||||
bail("join multicast group");
|
||||
|
||||
if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_LOOP,
|
||||
&ip_multicast_loop, sizeof(enabled)) < 0) {
|
||||
bail("loop multicast");
|
||||
}
|
||||
|
||||
/* set socket options for time stamping */
|
||||
if (so_timestamp &&
|
||||
setsockopt(sock, SOL_SOCKET, SO_TIMESTAMP,
|
||||
&enabled, sizeof(enabled)) < 0)
|
||||
bail("setsockopt SO_TIMESTAMP");
|
||||
|
||||
if (so_timestampns &&
|
||||
setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPNS,
|
||||
&enabled, sizeof(enabled)) < 0)
|
||||
bail("setsockopt SO_TIMESTAMPNS");
|
||||
|
||||
if (so_timestamping_flags &&
|
||||
setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING,
|
||||
&so_timestamping_flags,
|
||||
sizeof(so_timestamping_flags)) < 0)
|
||||
bail("setsockopt SO_TIMESTAMPING");
|
||||
|
||||
/* request IP_PKTINFO for debugging purposes */
|
||||
if (setsockopt(sock, SOL_IP, IP_PKTINFO,
|
||||
&enabled, sizeof(enabled)) < 0)
|
||||
printf("%s: %s\n", "setsockopt IP_PKTINFO", strerror(errno));
|
||||
|
||||
/* verify socket options */
|
||||
len = sizeof(val);
|
||||
if (getsockopt(sock, SOL_SOCKET, SO_TIMESTAMP, &val, &len) < 0)
|
||||
printf("%s: %s\n", "getsockopt SO_TIMESTAMP", strerror(errno));
|
||||
else
|
||||
printf("SO_TIMESTAMP %d\n", val);
|
||||
|
||||
if (getsockopt(sock, SOL_SOCKET, SO_TIMESTAMPNS, &val, &len) < 0)
|
||||
printf("%s: %s\n", "getsockopt SO_TIMESTAMPNS",
|
||||
strerror(errno));
|
||||
else
|
||||
printf("SO_TIMESTAMPNS %d\n", val);
|
||||
|
||||
if (getsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, &val, &len) < 0) {
|
||||
printf("%s: %s\n", "getsockopt SO_TIMESTAMPING",
|
||||
strerror(errno));
|
||||
} else {
|
||||
printf("SO_TIMESTAMPING %d\n", val);
|
||||
if (val != so_timestamping_flags)
|
||||
printf(" not the expected value %d\n",
|
||||
so_timestamping_flags);
|
||||
}
|
||||
|
||||
/* send packets forever every five seconds */
|
||||
gettimeofday(&next, 0);
|
||||
next.tv_sec = (next.tv_sec + 1) / 5 * 5;
|
||||
next.tv_usec = 0;
|
||||
while (1) {
|
||||
struct timeval now;
|
||||
struct timeval delta;
|
||||
long delta_us;
|
||||
int res;
|
||||
fd_set readfs, errorfs;
|
||||
|
||||
gettimeofday(&now, 0);
|
||||
delta_us = (long)(next.tv_sec - now.tv_sec) * 1000000 +
|
||||
(long)(next.tv_usec - now.tv_usec);
|
||||
if (delta_us > 0) {
|
||||
/* continue waiting for timeout or data */
|
||||
delta.tv_sec = delta_us / 1000000;
|
||||
delta.tv_usec = delta_us % 1000000;
|
||||
|
||||
FD_ZERO(&readfs);
|
||||
FD_ZERO(&errorfs);
|
||||
FD_SET(sock, &readfs);
|
||||
FD_SET(sock, &errorfs);
|
||||
printf("%ld.%06ld: select %ldus\n",
|
||||
(long)now.tv_sec, (long)now.tv_usec,
|
||||
delta_us);
|
||||
res = select(sock + 1, &readfs, 0, &errorfs, &delta);
|
||||
gettimeofday(&now, 0);
|
||||
printf("%ld.%06ld: select returned: %d, %s\n",
|
||||
(long)now.tv_sec, (long)now.tv_usec,
|
||||
res,
|
||||
res < 0 ? strerror(errno) : "success");
|
||||
if (res > 0) {
|
||||
if (FD_ISSET(sock, &readfs))
|
||||
printf("ready for reading\n");
|
||||
if (FD_ISSET(sock, &errorfs))
|
||||
printf("has error\n");
|
||||
recvpacket(sock, 0,
|
||||
siocgstamp,
|
||||
siocgstampns);
|
||||
recvpacket(sock, MSG_ERRQUEUE,
|
||||
siocgstamp,
|
||||
siocgstampns);
|
||||
}
|
||||
} else {
|
||||
/* write one packet */
|
||||
sendpacket(sock,
|
||||
(struct sockaddr *)&addr,
|
||||
sizeof(addr));
|
||||
next.tv_sec += 5;
|
||||
continue;
|
||||
}
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
180
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
Normal file
180
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
Normal file
|
@ -0,0 +1,180 @@
|
|||
MPC5200 Device Tree Bindings
|
||||
----------------------------
|
||||
|
||||
(c) 2006-2009 Secret Lab Technologies Ltd
|
||||
Grant Likely <grant.likely@secretlab.ca>
|
||||
|
||||
Naming conventions
|
||||
------------------
|
||||
For mpc5200 on-chip devices, the format for each compatible value is
|
||||
<chip>-<device>[-<mode>]. The OS should be able to match a device driver
|
||||
to the device based solely on the compatible value. If two drivers
|
||||
match on the compatible list; the 'most compatible' driver should be
|
||||
selected.
|
||||
|
||||
The split between the MPC5200 and the MPC5200B leaves a bit of a
|
||||
conundrum. How should the compatible property be set up to provide
|
||||
maximum compatibility information; but still accurately describe the
|
||||
chip? For the MPC5200; the answer is easy. Most of the SoC devices
|
||||
originally appeared on the MPC5200. Since they didn't exist anywhere
|
||||
else; the 5200 compatible properties will contain only one item;
|
||||
"fsl,mpc5200-<device>".
|
||||
|
||||
The 5200B is almost the same as the 5200, but not quite. It fixes
|
||||
silicon bugs and it adds a small number of enhancements. Most of the
|
||||
devices either provide exactly the same interface as on the 5200. A few
|
||||
devices have extra functions but still have a backwards compatible mode.
|
||||
To express this information as completely as possible, 5200B device trees
|
||||
should have two items in the compatible list:
|
||||
compatible = "fsl,mpc5200b-<device>","fsl,mpc5200-<device>";
|
||||
|
||||
It is *strongly* recommended that 5200B device trees follow this convention
|
||||
(instead of only listing the base mpc5200 item).
|
||||
|
||||
ie. ethernet on mpc5200: compatible = "fsl,mpc5200-fec";
|
||||
ethernet on mpc5200b: compatible = "fsl,mpc5200b-fec", "fsl,mpc5200-fec";
|
||||
|
||||
Modal devices, like PSCs, also append the configured function to the
|
||||
end of the compatible field. ie. A PSC in i2s mode would specify
|
||||
"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s". This convention is chosen to
|
||||
avoid naming conflicts with non-psc devices providing the same
|
||||
function. For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe
|
||||
the mpc5200 simple spi device and a PSC spi mode respectively.
|
||||
|
||||
At the time of writing, exact chip may be either 'fsl,mpc5200' or
|
||||
'fsl,mpc5200b'.
|
||||
|
||||
The soc node
|
||||
------------
|
||||
This node describes the on chip SOC peripherals. Every mpc5200 based
|
||||
board will have this node, and as such there is a common naming
|
||||
convention for SOC devices.
|
||||
|
||||
Required properties:
|
||||
name description
|
||||
---- -----------
|
||||
ranges Memory range of the internal memory mapped registers.
|
||||
Should be <0 [baseaddr] 0xc000>
|
||||
reg Should be <[baseaddr] 0x100>
|
||||
compatible mpc5200: "fsl,mpc5200-immr"
|
||||
mpc5200b: "fsl,mpc5200b-immr"
|
||||
system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI
|
||||
clocks are derived from the fsystem clock.
|
||||
bus-frequency IPB bus frequency in Hz. Clock rate
|
||||
used by most of the soc devices.
|
||||
|
||||
soc child nodes
|
||||
---------------
|
||||
Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
|
||||
|
||||
Note: The tables below show the value for the mpc5200. A mpc5200b device
|
||||
tree should use the "fsl,mpc5200b-<device>","fsl,mpc5200-<device>" form.
|
||||
|
||||
Required soc5200 child nodes:
|
||||
name compatible Description
|
||||
---- ---------- -----------
|
||||
cdm@<addr> fsl,mpc5200-cdm Clock Distribution
|
||||
interrupt-controller@<addr> fsl,mpc5200-pic need an interrupt
|
||||
controller to boot
|
||||
bestcomm@<addr> fsl,mpc5200-bestcomm Bestcomm DMA controller
|
||||
|
||||
Recommended soc5200 child nodes; populate as needed for your board
|
||||
name compatible Description
|
||||
---- ---------- -----------
|
||||
timer@<addr> fsl,mpc5200-gpt General purpose timers
|
||||
gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio controller
|
||||
gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio controller
|
||||
rtc@<addr> fsl,mpc5200-rtc Real time clock
|
||||
mscan@<addr> fsl,mpc5200-mscan CAN bus controller
|
||||
pci@<addr> fsl,mpc5200-pci PCI bridge
|
||||
serial@<addr> fsl,mpc5200-psc-uart PSC in serial mode
|
||||
i2s@<addr> fsl,mpc5200-psc-i2s PSC in i2s mode
|
||||
ac97@<addr> fsl,mpc5200-psc-ac97 PSC in ac97 mode
|
||||
spi@<addr> fsl,mpc5200-psc-spi PSC in spi mode
|
||||
irda@<addr> fsl,mpc5200-psc-irda PSC in IrDA mode
|
||||
spi@<addr> fsl,mpc5200-spi MPC5200 spi device
|
||||
ethernet@<addr> fsl,mpc5200-fec MPC5200 ethernet device
|
||||
ata@<addr> fsl,mpc5200-ata IDE ATA interface
|
||||
i2c@<addr> fsl,mpc5200-i2c I2C controller
|
||||
usb@<addr> fsl,mpc5200-ohci,ohci-be USB controller
|
||||
xlb@<addr> fsl,mpc5200-xlb XLB arbitrator
|
||||
|
||||
fsl,mpc5200-gpt nodes
|
||||
---------------------
|
||||
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
|
||||
design supports the internal wdt, then the device node for GPT0 should
|
||||
include the empty property 'fsl,has-wdt'.
|
||||
|
||||
An mpc5200-gpt can be used as a single line GPIO controller. To do so,
|
||||
add the following properties to the gpt node:
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
When referencing the GPIO line from another node, the first cell must always
|
||||
be zero and the second cell represents the gpio flags and described in the
|
||||
gpio device tree binding.
|
||||
|
||||
An mpc5200-gpt can be used as a single line edge sensitive interrupt
|
||||
controller. To do so, add the following properties to the gpt node:
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
When referencing the IRQ line from another node, the cell represents the
|
||||
sense mode; 1 for edge rising, 2 for edge falling.
|
||||
|
||||
fsl,mpc5200-psc nodes
|
||||
---------------------
|
||||
The PSCs should include a cell-index which is the index of the PSC in
|
||||
hardware. cell-index is used to determine which shared SoC registers to
|
||||
use when setting up PSC clocking. cell-index number starts at '0'. ie:
|
||||
PSC1 has 'cell-index = <0>'
|
||||
PSC4 has 'cell-index = <3>'
|
||||
|
||||
PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
|
||||
i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
|
||||
compatible field.
|
||||
|
||||
|
||||
fsl,mpc5200-gpio and fsl,mpc5200-gpio-wkup nodes
|
||||
------------------------------------------------
|
||||
Each GPIO controller node should have the empty property gpio-controller and
|
||||
#gpio-cells set to 2. First cell is the GPIO number which is interpreted
|
||||
according to the bit numbers in the GPIO control registers. The second cell
|
||||
is for flags which is currently unused.
|
||||
|
||||
fsl,mpc5200-fec nodes
|
||||
---------------------
|
||||
The FEC node can specify one of the following properties to configure
|
||||
the MII link:
|
||||
- fsl,7-wire-mode - An empty property that specifies the link uses 7-wire
|
||||
mode instead of MII
|
||||
- current-speed - Specifies that the MII should be configured for a fixed
|
||||
speed. This property should contain two cells. The
|
||||
first cell specifies the speed in Mbps and the second
|
||||
should be '0' for half duplex and '1' for full duplex
|
||||
- phy-handle - Contains a phandle to an Ethernet PHY.
|
||||
|
||||
Interrupt controller (fsl,mpc5200-pic) node
|
||||
-------------------------------------------
|
||||
The mpc5200 pic binding splits hardware IRQ numbers into two levels. The
|
||||
split reflects the layout of the PIC hardware itself, which groups
|
||||
interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
|
||||
Bestcomm dma engine has it's own set of interrupt sources which are
|
||||
cascaded off of peripheral interrupt 0, which the driver interprets as a
|
||||
fourth group, SDMA.
|
||||
|
||||
The interrupts property for device nodes using the mpc5200 pic consists
|
||||
of three cells; <L1 L2 level>
|
||||
|
||||
L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
|
||||
L2 := interrupt number; directly mapped from the value in the
|
||||
"ICTL PerStat, MainStat, CritStat Encoded Register"
|
||||
level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
|
||||
|
||||
For external IRQs, use the following interrupt property values (how to
|
||||
specify external interrupts is a frequently asked question):
|
||||
External interrupts:
|
||||
external irq0: interrupts = <0 0 n>;
|
||||
external irq1: interrupts = <1 1 n>;
|
||||
external irq2: interrupts = <1 2 n>;
|
||||
external irq3: interrupts = <1 3 n>;
|
||||
'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low)
|
||||
|
|
@ -56,6 +56,12 @@ Properties:
|
|||
hardware.
|
||||
- fsl,magic-packet : If present, indicates that the hardware supports
|
||||
waking up via magic packet.
|
||||
- bd-stash : If present, indicates that the hardware supports stashing
|
||||
buffer descriptors in the L2.
|
||||
- rx-stash-len : Denotes the number of bytes of a received buffer to stash
|
||||
in the L2.
|
||||
- rx-stash-idx : Denotes the index of the first byte from the received
|
||||
buffer to stash in the L2.
|
||||
|
||||
Example:
|
||||
ethernet@24000 {
|
||||
|
|
|
@ -1,277 +0,0 @@
|
|||
MPC5200 Device Tree Bindings
|
||||
----------------------------
|
||||
|
||||
(c) 2006-2007 Secret Lab Technologies Ltd
|
||||
Grant Likely <grant.likely at secretlab.ca>
|
||||
|
||||
********** DRAFT ***********
|
||||
* WARNING: Do not depend on the stability of these bindings just yet.
|
||||
* The MPC5200 device tree conventions are still in flux
|
||||
* Keep an eye on the linuxppc-dev mailing list for more details
|
||||
********** DRAFT ***********
|
||||
|
||||
I - Introduction
|
||||
================
|
||||
Boards supported by the arch/powerpc architecture require device tree be
|
||||
passed by the boot loader to the kernel at boot time. The device tree
|
||||
describes what devices are present on the board and how they are
|
||||
connected. The device tree can either be passed as a binary blob (as
|
||||
described in Documentation/powerpc/booting-without-of.txt), or passed
|
||||
by Open Firmware (IEEE 1275) compatible firmware using an OF compatible
|
||||
client interface API.
|
||||
|
||||
This document specifies the requirements on the device-tree for mpc5200
|
||||
based boards. These requirements are above and beyond the details
|
||||
specified in either the Open Firmware spec or booting-without-of.txt
|
||||
|
||||
All new mpc5200-based boards are expected to match this document. In
|
||||
cases where this document is not sufficient to support a new board port,
|
||||
this document should be updated as part of adding the new board support.
|
||||
|
||||
II - Philosophy
|
||||
===============
|
||||
The core of this document is naming convention. The whole point of
|
||||
defining this convention is to reduce or eliminate the number of
|
||||
special cases required to support a 5200 board. If all 5200 boards
|
||||
follow the same convention, then generic 5200 support code will work
|
||||
rather than coding special cases for each new board.
|
||||
|
||||
This section tries to capture the thought process behind why the naming
|
||||
convention is what it is.
|
||||
|
||||
1. names
|
||||
---------
|
||||
There is strong convention/requirements already established for children
|
||||
of the root node. 'cpus' describes the processor cores, 'memory'
|
||||
describes memory, and 'chosen' provides boot configuration. Other nodes
|
||||
are added to describe devices attached to the processor local bus.
|
||||
|
||||
Following convention already established with other system-on-chip
|
||||
processors, 5200 device trees should use the name 'soc5200' for the
|
||||
parent node of on chip devices, and the root node should be its parent.
|
||||
|
||||
Child nodes are typically named after the configured function. ie.
|
||||
the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'.
|
||||
|
||||
2. device_type property
|
||||
-----------------------
|
||||
similar to the node name convention above; the device_type reflects the
|
||||
configured function of a device. ie. 'serial' for a uart and 'spi' for
|
||||
an spi controller. However, while node names *should* reflect the
|
||||
configured function, device_type *must* match the configured function
|
||||
exactly.
|
||||
|
||||
3. compatible property
|
||||
----------------------
|
||||
Since device_type isn't enough to match devices to drivers, there also
|
||||
needs to be a naming convention for the compatible property. Compatible
|
||||
is an list of device descriptions sorted from specific to generic. For
|
||||
the mpc5200, the required format for each compatible value is
|
||||
<chip>-<device>[-<mode>]. The OS should be able to match a device driver
|
||||
to the device based solely on the compatible value. If two drivers
|
||||
match on the compatible list; the 'most compatible' driver should be
|
||||
selected.
|
||||
|
||||
The split between the MPC5200 and the MPC5200B leaves a bit of a
|
||||
conundrum. How should the compatible property be set up to provide
|
||||
maximum compatibility information; but still accurately describe the
|
||||
chip? For the MPC5200; the answer is easy. Most of the SoC devices
|
||||
originally appeared on the MPC5200. Since they didn't exist anywhere
|
||||
else; the 5200 compatible properties will contain only one item;
|
||||
"mpc5200-<device>".
|
||||
|
||||
The 5200B is almost the same as the 5200, but not quite. It fixes
|
||||
silicon bugs and it adds a small number of enhancements. Most of the
|
||||
devices either provide exactly the same interface as on the 5200. A few
|
||||
devices have extra functions but still have a backwards compatible mode.
|
||||
To express this information as completely as possible, 5200B device trees
|
||||
should have two items in the compatible list;
|
||||
"mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended
|
||||
that 5200B device trees follow this convention (instead of only listing
|
||||
the base mpc5200 item).
|
||||
|
||||
If another chip appear on the market with one of the mpc5200 SoC
|
||||
devices, then the compatible list should include mpc5200-<device>.
|
||||
|
||||
ie. ethernet on mpc5200: compatible = "mpc5200-ethernet"
|
||||
ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet"
|
||||
|
||||
Modal devices, like PSCs, also append the configured function to the
|
||||
end of the compatible field. ie. A PSC in i2s mode would specify
|
||||
"mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to
|
||||
avoid naming conflicts with non-psc devices providing the same
|
||||
function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe
|
||||
the mpc5200 simple spi device and a PSC spi mode respectively.
|
||||
|
||||
If the soc device is more generic and present on other SOCs, the
|
||||
compatible property can specify the more generic device type also.
|
||||
|
||||
ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan";
|
||||
|
||||
At the time of writing, exact chip may be either 'mpc5200' or
|
||||
'mpc5200b'.
|
||||
|
||||
Device drivers should always try to match as generically as possible.
|
||||
|
||||
III - Structure
|
||||
===============
|
||||
The device tree for an mpc5200 board follows the structure defined in
|
||||
booting-without-of.txt with the following additional notes:
|
||||
|
||||
0) the root node
|
||||
----------------
|
||||
Typical root description node; see booting-without-of
|
||||
|
||||
1) The cpus node
|
||||
----------------
|
||||
The cpus node follows the basic layout described in booting-without-of.
|
||||
The bus-frequency property holds the XLB bus frequency
|
||||
The clock-frequency property holds the core frequency
|
||||
|
||||
2) The memory node
|
||||
------------------
|
||||
Typical memory description node; see booting-without-of.
|
||||
|
||||
3) The soc5200 node
|
||||
-------------------
|
||||
This node describes the on chip SOC peripherals. Every mpc5200 based
|
||||
board will have this node, and as such there is a common naming
|
||||
convention for SOC devices.
|
||||
|
||||
Required properties:
|
||||
name type description
|
||||
---- ---- -----------
|
||||
device_type string must be "soc"
|
||||
ranges int should be <0 baseaddr baseaddr+10000>
|
||||
reg int must be <baseaddr 10000>
|
||||
compatible string mpc5200: "mpc5200-soc"
|
||||
mpc5200b: "mpc5200b-soc\0mpc5200-soc"
|
||||
system-frequency int Fsystem frequency; source of all
|
||||
other clocks.
|
||||
bus-frequency int IPB bus frequency in HZ. Clock rate
|
||||
used by most of the soc devices.
|
||||
#interrupt-cells int must be <3>.
|
||||
|
||||
Recommended properties:
|
||||
name type description
|
||||
---- ---- -----------
|
||||
model string Exact model of the chip;
|
||||
ie: model="fsl,mpc5200"
|
||||
revision string Silicon revision of chip
|
||||
ie: revision="M08A"
|
||||
|
||||
The 'model' and 'revision' properties are *strongly* recommended. Having
|
||||
them presence acts as a bit of a safety net for working around as yet
|
||||
undiscovered bugs on one version of silicon. For example, device drivers
|
||||
can use the model and revision properties to decide if a bug fix should
|
||||
be turned on.
|
||||
|
||||
4) soc5200 child nodes
|
||||
----------------------
|
||||
Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
|
||||
|
||||
Note: The tables below show the value for the mpc5200. A mpc5200b device
|
||||
tree should use the "mpc5200b-<device>\0mpc5200-<device> form.
|
||||
|
||||
Required soc5200 child nodes:
|
||||
name device_type compatible Description
|
||||
---- ----------- ---------- -----------
|
||||
cdm@<addr> cdm mpc5200-cmd Clock Distribution
|
||||
pic@<addr> interrupt-controller mpc5200-pic need an interrupt
|
||||
controller to boot
|
||||
bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires
|
||||
the bestcomm device
|
||||
|
||||
Recommended soc5200 child nodes; populate as needed for your board
|
||||
name device_type compatible Description
|
||||
---- ----------- ---------- -----------
|
||||
gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
|
||||
gpt@<addr> gpt fsl,mpc5200-gpt-gpio General purpose
|
||||
timers in GPIO mode
|
||||
gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio
|
||||
controller
|
||||
gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio
|
||||
controller
|
||||
rtc@<addr> rtc mpc5200-rtc Real time clock
|
||||
mscan@<addr> mscan mpc5200-mscan CAN bus controller
|
||||
pci@<addr> pci mpc5200-pci PCI bridge
|
||||
serial@<addr> serial mpc5200-psc-uart PSC in serial mode
|
||||
i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode
|
||||
ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode
|
||||
spi@<addr> spi mpc5200-psc-spi PSC in spi mode
|
||||
irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode
|
||||
spi@<addr> spi mpc5200-spi MPC5200 spi device
|
||||
ethernet@<addr> network mpc5200-fec MPC5200 ethernet device
|
||||
ata@<addr> ata mpc5200-ata IDE ATA interface
|
||||
i2c@<addr> i2c mpc5200-i2c I2C controller
|
||||
usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller
|
||||
xlb@<addr> xlb mpc5200-xlb XLB arbitrator
|
||||
|
||||
Important child node properties
|
||||
name type description
|
||||
---- ---- -----------
|
||||
cell-index int When multiple devices are present, is the
|
||||
index of the device in the hardware (ie. There
|
||||
are 6 PSC on the 5200 numbered PSC1 to PSC6)
|
||||
PSC1 has 'cell-index = <0>'
|
||||
PSC4 has 'cell-index = <3>'
|
||||
|
||||
5) General Purpose Timer nodes (child of soc5200 node)
|
||||
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
|
||||
design supports the internal wdt, then the device node for GPT0 should
|
||||
include the empty property 'fsl,has-wdt'.
|
||||
|
||||
6) PSC nodes (child of soc5200 node)
|
||||
PSC nodes can define the optional 'port-number' property to force assignment
|
||||
order of serial ports. For example, PSC5 might be physically connected to
|
||||
the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would
|
||||
have a "port-number = <0>" property, and PSC1 would have "port-number = <1>".
|
||||
|
||||
PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
|
||||
i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
|
||||
compatible field.
|
||||
|
||||
7) GPIO controller nodes
|
||||
Each GPIO controller node should have the empty property gpio-controller and
|
||||
#gpio-cells set to 2. First cell is the GPIO number which is interpreted
|
||||
according to the bit numbers in the GPIO control registers. The second cell
|
||||
is for flags which is currently unsused.
|
||||
|
||||
8) FEC nodes
|
||||
The FEC node can specify one of the following properties to configure
|
||||
the MII link:
|
||||
"fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire
|
||||
mode instead of MII
|
||||
"current-speed" - Specifies that the MII should be configured for a fixed
|
||||
speed. This property should contain two cells. The
|
||||
first cell specifies the speed in Mbps and the second
|
||||
should be '0' for half duplex and '1' for full duplex
|
||||
"phy-handle" - Contains a phandle to an Ethernet PHY.
|
||||
|
||||
IV - Extra Notes
|
||||
================
|
||||
|
||||
1. Interrupt mapping
|
||||
--------------------
|
||||
The mpc5200 pic driver splits hardware IRQ numbers into two levels. The
|
||||
split reflects the layout of the PIC hardware itself, which groups
|
||||
interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
|
||||
Bestcomm dma engine has it's own set of interrupt sources which are
|
||||
cascaded off of peripheral interrupt 0, which the driver interprets as a
|
||||
fourth group, SDMA.
|
||||
|
||||
The interrupts property for device nodes using the mpc5200 pic consists
|
||||
of three cells; <L1 L2 level>
|
||||
|
||||
L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
|
||||
L2 := interrupt number; directly mapped from the value in the
|
||||
"ICTL PerStat, MainStat, CritStat Encoded Register"
|
||||
level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
|
||||
|
||||
2. Shared registers
|
||||
-------------------
|
||||
Some SoC devices share registers between them. ie. the i2c devices use
|
||||
a single clock control register, and almost all device are affected by
|
||||
the port_config register. Devices which need to manipulate shared regs
|
||||
should look to the parent SoC node. The soc node is responsible
|
||||
for arbitrating all shared register access.
|
|
@ -2,8 +2,6 @@
|
|||
- this file.
|
||||
sched-arch.txt
|
||||
- CPU Scheduler implementation hints for architecture specific code.
|
||||
sched-coding.txt
|
||||
- reference for various scheduler-related methods in the O(1) scheduler.
|
||||
sched-design-CFS.txt
|
||||
- goals, design and implementation of the Complete Fair Scheduler.
|
||||
sched-domains.txt
|
||||
|
|
|
@ -1,126 +0,0 @@
|
|||
Reference for various scheduler-related methods in the O(1) scheduler
|
||||
Robert Love <rml@tech9.net>, MontaVista Software
|
||||
|
||||
|
||||
Note most of these methods are local to kernel/sched.c - this is by design.
|
||||
The scheduler is meant to be self-contained and abstracted away. This document
|
||||
is primarily for understanding the scheduler, not interfacing to it. Some of
|
||||
the discussed interfaces, however, are general process/scheduling methods.
|
||||
They are typically defined in include/linux/sched.h.
|
||||
|
||||
|
||||
Main Scheduling Methods
|
||||
-----------------------
|
||||
|
||||
void load_balance(runqueue_t *this_rq, int idle)
|
||||
Attempts to pull tasks from one cpu to another to balance cpu usage,
|
||||
if needed. This method is called explicitly if the runqueues are
|
||||
imbalanced or periodically by the timer tick. Prior to calling,
|
||||
the current runqueue must be locked and interrupts disabled.
|
||||
|
||||
void schedule()
|
||||
The main scheduling function. Upon return, the highest priority
|
||||
process will be active.
|
||||
|
||||
|
||||
Locking
|
||||
-------
|
||||
|
||||
Each runqueue has its own lock, rq->lock. When multiple runqueues need
|
||||
to be locked, lock acquires must be ordered by ascending &runqueue value.
|
||||
|
||||
A specific runqueue is locked via
|
||||
|
||||
task_rq_lock(task_t pid, unsigned long *flags)
|
||||
|
||||
which disables preemption, disables interrupts, and locks the runqueue pid is
|
||||
running on. Likewise,
|
||||
|
||||
task_rq_unlock(task_t pid, unsigned long *flags)
|
||||
|
||||
unlocks the runqueue pid is running on, restores interrupts to their previous
|
||||
state, and reenables preemption.
|
||||
|
||||
The routines
|
||||
|
||||
double_rq_lock(runqueue_t *rq1, runqueue_t *rq2)
|
||||
|
||||
and
|
||||
|
||||
double_rq_unlock(runqueue_t *rq1, runqueue_t *rq2)
|
||||
|
||||
safely lock and unlock, respectively, the two specified runqueues. They do
|
||||
not, however, disable and restore interrupts. Users are required to do so
|
||||
manually before and after calls.
|
||||
|
||||
|
||||
Values
|
||||
------
|
||||
|
||||
MAX_PRIO
|
||||
The maximum priority of the system, stored in the task as task->prio.
|
||||
Lower priorities are higher. Normal (non-RT) priorities range from
|
||||
MAX_RT_PRIO to (MAX_PRIO - 1).
|
||||
MAX_RT_PRIO
|
||||
The maximum real-time priority of the system. Valid RT priorities
|
||||
range from 0 to (MAX_RT_PRIO - 1).
|
||||
MAX_USER_RT_PRIO
|
||||
The maximum real-time priority that is exported to user-space. Should
|
||||
always be equal to or less than MAX_RT_PRIO. Setting it less allows
|
||||
kernel threads to have higher priorities than any user-space task.
|
||||
MIN_TIMESLICE
|
||||
MAX_TIMESLICE
|
||||
Respectively, the minimum and maximum timeslices (quanta) of a process.
|
||||
|
||||
Data
|
||||
----
|
||||
|
||||
struct runqueue
|
||||
The main per-CPU runqueue data structure.
|
||||
struct task_struct
|
||||
The main per-process data structure.
|
||||
|
||||
|
||||
General Methods
|
||||
---------------
|
||||
|
||||
cpu_rq(cpu)
|
||||
Returns the runqueue of the specified cpu.
|
||||
this_rq()
|
||||
Returns the runqueue of the current cpu.
|
||||
task_rq(pid)
|
||||
Returns the runqueue which holds the specified pid.
|
||||
cpu_curr(cpu)
|
||||
Returns the task currently running on the given cpu.
|
||||
rt_task(pid)
|
||||
Returns true if pid is real-time, false if not.
|
||||
|
||||
|
||||
Process Control Methods
|
||||
-----------------------
|
||||
|
||||
void set_user_nice(task_t *p, long nice)
|
||||
Sets the "nice" value of task p to the given value.
|
||||
int setscheduler(pid_t pid, int policy, struct sched_param *param)
|
||||
Sets the scheduling policy and parameters for the given pid.
|
||||
int set_cpus_allowed(task_t *p, unsigned long new_mask)
|
||||
Sets a given task's CPU affinity and migrates it to a proper cpu.
|
||||
Callers must have a valid reference to the task and assure the
|
||||
task not exit prematurely. No locks can be held during the call.
|
||||
set_task_state(tsk, state_value)
|
||||
Sets the given task's state to the given value.
|
||||
set_current_state(state_value)
|
||||
Sets the current task's state to the given value.
|
||||
void set_tsk_need_resched(struct task_struct *tsk)
|
||||
Sets need_resched in the given task.
|
||||
void clear_tsk_need_resched(struct task_struct *tsk)
|
||||
Clears need_resched in the given task.
|
||||
void set_need_resched()
|
||||
Sets need_resched in the current task.
|
||||
void clear_need_resched()
|
||||
Clears need_resched in the current task.
|
||||
int need_resched()
|
||||
Returns true if need_resched is set in the current task, false
|
||||
otherwise.
|
||||
yield()
|
||||
Place the current process at the end of the runqueue and call schedule.
|
|
@ -4,7 +4,7 @@ Introduction
|
|||
============
|
||||
|
||||
The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc.
|
||||
series of products) supports iSCSI acceleration and iSCSI Direct Data Placement
|
||||
series of products) support iSCSI acceleration and iSCSI Direct Data Placement
|
||||
(DDP) where the hardware handles the expensive byte touching operations, such
|
||||
as CRC computation and verification, and direct DMA to the final host memory
|
||||
destination:
|
||||
|
@ -31,9 +31,9 @@ destination:
|
|||
the TCP segments onto the wire. It handles TCP retransmission if
|
||||
needed.
|
||||
|
||||
On receving, S3 h/w recovers the iSCSI PDU by reassembling TCP
|
||||
On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP
|
||||
segments, separating the header and data, calculating and verifying
|
||||
the digests, then forwards the header to the host. The payload data,
|
||||
the digests, then forwarding the header to the host. The payload data,
|
||||
if possible, will be directly placed into the pre-posted host DDP
|
||||
buffer. Otherwise, the payload data will be sent to the host too.
|
||||
|
||||
|
@ -68,9 +68,8 @@ The following steps need to be taken to accelerates the open-iscsi initiator:
|
|||
sure the ip address is unique in the network.
|
||||
|
||||
3. edit /etc/iscsi/iscsid.conf
|
||||
The default setting for MaxRecvDataSegmentLength (131072) is too big,
|
||||
replace "node.conn[0].iscsi.MaxRecvDataSegmentLength" to be a value no
|
||||
bigger than 15360 (for example 8192):
|
||||
The default setting for MaxRecvDataSegmentLength (131072) is too big;
|
||||
replace with a value no bigger than 15360 (for example 8192):
|
||||
|
||||
node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192
|
||||
|
||||
|
|
|
@ -346,6 +346,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
sbirq - IRQ # for CMI8330 chip (SB16)
|
||||
sbdma8 - 8bit DMA # for CMI8330 chip (SB16)
|
||||
sbdma16 - 16bit DMA # for CMI8330 chip (SB16)
|
||||
fmport - (optional) OPL3 I/O port
|
||||
mpuport - (optional) MPU401 I/O port
|
||||
mpuirq - (optional) MPU401 irq #
|
||||
|
||||
This module supports multiple cards and autoprobe.
|
||||
|
||||
|
@ -388,34 +391,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
The power-management is supported.
|
||||
|
||||
Module snd-cs4232
|
||||
-----------------
|
||||
|
||||
Module for sound cards based on CS4232/CS4232A ISA chips.
|
||||
|
||||
isapnp - ISA PnP detection - 0 = disable, 1 = enable (default)
|
||||
|
||||
with isapnp=0, the following options are available:
|
||||
|
||||
port - port # for CS4232 chip (PnP setup - 0x534)
|
||||
cport - control port # for CS4232 chip (PnP setup - 0x120,0x210,0xf00)
|
||||
mpu_port - port # for MPU-401 UART (PnP setup - 0x300), -1 = disable
|
||||
fm_port - FM port # for CS4232 chip (PnP setup - 0x388), -1 = disable
|
||||
irq - IRQ # for CS4232 chip (5,7,9,11,12,15)
|
||||
mpu_irq - IRQ # for MPU-401 UART (9,11,12,15)
|
||||
dma1 - first DMA # for CS4232 chip (0,1,3)
|
||||
dma2 - second DMA # for Yamaha CS4232 chip (0,1,3), -1 = disable
|
||||
|
||||
This module supports multiple cards. This module does not support autoprobe
|
||||
(if ISA PnP is not used) thus main port must be specified!!! Other ports are
|
||||
optional.
|
||||
|
||||
The power-management is supported.
|
||||
|
||||
Module snd-cs4236
|
||||
-----------------
|
||||
|
||||
Module for sound cards based on CS4235/CS4236/CS4236B/CS4237B/
|
||||
Module for sound cards based on CS4232/CS4232A,
|
||||
CS4235/CS4236/CS4236B/CS4237B/
|
||||
CS4238B/CS4239 ISA chips.
|
||||
|
||||
isapnp - ISA PnP detection - 0 = disable, 1 = enable (default)
|
||||
|
@ -437,6 +417,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
The power-management is supported.
|
||||
|
||||
This module is aliased as snd-cs4232 since it provides the old
|
||||
snd-cs4232 functionality, too.
|
||||
|
||||
Module snd-cs4281
|
||||
-----------------
|
||||
|
||||
|
@ -606,6 +589,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
Module for ESS AudioDrive ES-1688 and ES-688 sound cards.
|
||||
|
||||
port - port # for ES-1688 chip (0x220,0x240,0x260)
|
||||
fm_port - port # for OPL3 (option; share the same port as default)
|
||||
mpu_port - port # for MPU-401 port (0x300,0x310,0x320,0x330), -1 = disable (default)
|
||||
irq - IRQ # for ES-1688 chip (5,7,9,10)
|
||||
mpu_irq - IRQ # for MPU-401 port (5,7,9,10)
|
||||
|
@ -757,6 +741,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
model - force the model name
|
||||
position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF)
|
||||
probe_mask - Bitmask to probe codecs (default = -1, meaning all slots)
|
||||
When the bit 8 (0x100) is set, the lower 8 bits are used
|
||||
as the "fixed" codec slots; i.e. the driver probes the
|
||||
slots regardless what hardware reports back
|
||||
probe_only - Only probing and no codec initialization (default=off);
|
||||
Useful to check the initial codec status for debugging
|
||||
bdl_pos_adj - Specifies the DMA IRQ timing delay in samples.
|
||||
|
@ -1185,6 +1172,54 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
This module supports multiple devices and PnP.
|
||||
|
||||
Module snd-msnd-classic
|
||||
-----------------------
|
||||
|
||||
Module for Turtle Beach MultiSound Classic, Tahiti or Monterey
|
||||
soundcards.
|
||||
|
||||
io - Port # for msnd-classic card
|
||||
irq - IRQ # for msnd-classic card
|
||||
mem - Memory address (0xb0000, 0xc8000, 0xd0000, 0xd8000,
|
||||
0xe0000 or 0xe8000)
|
||||
write_ndelay - enable write ndelay (default = 1)
|
||||
calibrate_signal - calibrate signal (default = 0)
|
||||
isapnp - ISA PnP detection - 0 = disable, 1 = enable (default)
|
||||
digital - Digital daughterboard present (default = 0)
|
||||
cfg - Config port (0x250, 0x260 or 0x270) default = PnP
|
||||
reset - Reset all devices
|
||||
mpu_io - MPU401 I/O port
|
||||
mpu_irq - MPU401 irq#
|
||||
ide_io0 - IDE port #0
|
||||
ide_io1 - IDE port #1
|
||||
ide_irq - IDE irq#
|
||||
joystick_io - Joystick I/O port
|
||||
|
||||
The driver requires firmware files "turtlebeach/msndinit.bin" and
|
||||
"turtlebeach/msndperm.bin" in the proper firmware directory.
|
||||
|
||||
See Documentation/sound/oss/MultiSound for important information
|
||||
about this driver. Note that it has been discontinued, but the
|
||||
Voyetra Turtle Beach knowledge base entry for it is still available
|
||||
at
|
||||
http://www.turtlebeach.com/site/kb_ftp/790.asp
|
||||
|
||||
Module snd-msnd-pinnacle
|
||||
------------------------
|
||||
|
||||
Module for Turtle Beach MultiSound Pinnacle/Fiji soundcards.
|
||||
|
||||
io - Port # for pinnacle/fiji card
|
||||
irq - IRQ # for pinnalce/fiji card
|
||||
mem - Memory address (0xb0000, 0xc8000, 0xd0000, 0xd8000,
|
||||
0xe0000 or 0xe8000)
|
||||
write_ndelay - enable write ndelay (default = 1)
|
||||
calibrate_signal - calibrate signal (default = 0)
|
||||
isapnp - ISA PnP detection - 0 = disable, 1 = enable (default)
|
||||
|
||||
The driver requires firmware files "turtlebeach/pndspini.bin" and
|
||||
"turtlebeach/pndsperm.bin" in the proper firmware directory.
|
||||
|
||||
Module snd-mtpav
|
||||
----------------
|
||||
|
||||
|
@ -1824,7 +1859,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
-------------------
|
||||
|
||||
Module for sound cards based on the Asus AV100/AV200 chips,
|
||||
i.e., Xonar D1, DX, D2, D2X and HDAV1.3 (Deluxe).
|
||||
i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), and Essence STX.
|
||||
|
||||
This module supports autoprobe and multiple cards.
|
||||
|
||||
|
|
|
@ -56,6 +56,7 @@ ALC262
|
|||
sony-assamd Sony ASSAMD
|
||||
toshiba-s06 Toshiba S06
|
||||
toshiba-rx1 Toshiba RX1
|
||||
tyan Tyan Thunder n6650W (S2915-E)
|
||||
ultra Samsung Q1 Ultra Vista model
|
||||
lenovo-3000 Lenovo 3000 y410
|
||||
nec NEC Versa S9100
|
||||
|
@ -261,6 +262,8 @@ Conexant 5051
|
|||
=============
|
||||
laptop Basic Laptop config (default)
|
||||
hp HP Spartan laptop
|
||||
hp-dv6736 HP dv6736
|
||||
lenovo-x200 Lenovo X200 laptop
|
||||
|
||||
STAC9200
|
||||
========
|
||||
|
@ -278,6 +281,7 @@ STAC9200
|
|||
gateway-m4 Gateway laptops with EAPD control
|
||||
gateway-m4-2 Gateway laptops with EAPD control
|
||||
panasonic Panasonic CF-74
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9205/9254
|
||||
=============
|
||||
|
@ -285,6 +289,8 @@ STAC9205/9254
|
|||
dell-m42 Dell (unknown)
|
||||
dell-m43 Dell Precision
|
||||
dell-m44 Dell Inspiron
|
||||
eapd Keep EAPD on (e.g. Gateway T1616)
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9220/9221
|
||||
=============
|
||||
|
@ -308,6 +314,7 @@ STAC9220/9221
|
|||
dell-d82 Dell (unknown)
|
||||
dell-m81 Dell (unknown)
|
||||
dell-m82 Dell XPS M1210
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9202/9250/9251
|
||||
==================
|
||||
|
@ -319,6 +326,7 @@ STAC9202/9250/9251
|
|||
m3 Some Gateway MX series laptops
|
||||
m5 Some Gateway MX series laptops (MP6954)
|
||||
m6 Some Gateway NX series laptops
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9227/9228/9229/927x
|
||||
=======================
|
||||
|
@ -328,6 +336,7 @@ STAC9227/9228/9229/927x
|
|||
5stack D965 5stack + SPDIF
|
||||
dell-3stack Dell Dimension E520
|
||||
dell-bios Fixes with Dell BIOS setup
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD71B*
|
||||
============
|
||||
|
@ -335,7 +344,10 @@ STAC92HD71B*
|
|||
dell-m4-1 Dell desktops
|
||||
dell-m4-2 Dell desktops
|
||||
dell-m4-3 Dell desktops
|
||||
hp-m4 HP dv laptops
|
||||
hp-m4 HP mini 1000
|
||||
hp-dv5 HP dv series
|
||||
hp-hdx HP HDX series
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD73*
|
||||
===========
|
||||
|
@ -345,12 +357,16 @@ STAC92HD73*
|
|||
dell-m6-dmic Dell desktops/laptops with digital mics
|
||||
dell-m6 Dell desktops/laptops with both type of mics
|
||||
dell-eq Dell desktops/laptops
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD83*
|
||||
===========
|
||||
ref Reference board
|
||||
mic-ref Reference board with power managment for ports
|
||||
dell-s14 Dell laptop
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9872
|
||||
========
|
||||
vaio Setup for VAIO FE550G/SZ110
|
||||
vaio-ar Setup for VAIO AR
|
||||
vaio VAIO laptop without SPDIF
|
||||
auto BIOS setup (default)
|
||||
|
|
|
@ -109,6 +109,13 @@ slot, pass `probe_mask=1`. For the first and the third slots, pass
|
|||
Since 2.6.29 kernel, the driver has a more robust probing method, so
|
||||
this error might happen rarely, though.
|
||||
|
||||
On a machine with a broken BIOS, sometimes you need to force the
|
||||
driver to probe the codec slots the hardware doesn't report for use.
|
||||
In such a case, turn the bit 8 (0x100) of `probe_mask` option on.
|
||||
Then the rest 8 bits are passed as the codec slots to probe
|
||||
unconditionally. For example, `probe_mask=0x103` will force to probe
|
||||
the codec slots 0 and 1 no matter what the hardware reports.
|
||||
|
||||
|
||||
Interrupt Handling
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
@ -358,10 +365,26 @@ modelname::
|
|||
to this file.
|
||||
init_verbs::
|
||||
The extra verbs to execute at initialization. You can add a verb by
|
||||
writing to this file. Pass tree numbers, nid, verb and parameter.
|
||||
writing to this file. Pass three numbers: nid, verb and parameter
|
||||
(separated with a space).
|
||||
hints::
|
||||
Shows hint strings for codec parsers for any use. Right now it's
|
||||
not used.
|
||||
Shows / stores hint strings for codec parsers for any use.
|
||||
Its format is `key = value`. For example, passing `hp_detect = yes`
|
||||
to IDT/STAC codec parser will result in the disablement of the
|
||||
headphone detection.
|
||||
init_pin_configs::
|
||||
Shows the initial pin default config values set by BIOS.
|
||||
driver_pin_configs::
|
||||
Shows the pin default values set by the codec parser explicitly.
|
||||
This doesn't show all pin values but only the changed values by
|
||||
the parser. That is, if the parser doesn't change the pin default
|
||||
config values by itself, this will contain nothing.
|
||||
user_pin_configs::
|
||||
Shows the pin default config values to override the BIOS setup.
|
||||
Writing this (with two numbers, NID and value) appends the new
|
||||
value. The given will be used instead of the initial BIOS value at
|
||||
the next reconfiguration time. Note that this config will override
|
||||
even the driver pin configs, too.
|
||||
reconfig::
|
||||
Triggers the codec re-configuration. When any value is written to
|
||||
this file, the driver re-initialize and parses the codec tree
|
||||
|
@ -371,6 +394,14 @@ clear::
|
|||
Resets the codec, removes the mixer elements and PCM stuff of the
|
||||
specified codec, and clear all init verbs and hints.
|
||||
|
||||
For example, when you want to change the pin default configuration
|
||||
value of the pin widget 0x14 to 0x9993013f, and let the driver
|
||||
re-configure based on that state, run like below:
|
||||
------------------------------------------------------------------------
|
||||
# echo 0x14 0x9993013f > /sys/class/sound/hwC0D0/user_pin_configs
|
||||
# echo 1 > /sys/class/sound/hwC0D0/reconfig
|
||||
------------------------------------------------------------------------
|
||||
|
||||
|
||||
Power-Saving
|
||||
~~~~~~~~~~~~
|
||||
|
@ -461,6 +492,16 @@ run with `--no-upload` option, and attach the generated file.
|
|||
There are some other useful options. See `--help` option output for
|
||||
details.
|
||||
|
||||
When a probe error occurs or when the driver obviously assigns a
|
||||
mismatched model, it'd be helpful to load the driver with
|
||||
`probe_only=1` option (at best after the cold reboot) and run
|
||||
alsa-info at this state. With this option, the driver won't configure
|
||||
the mixer and PCM but just tries to probe the codec slot. After
|
||||
probing, the proc file is available, so you can get the raw codec
|
||||
information before modified by the driver. Of course, the driver
|
||||
isn't usable with `probe_only=1`. But you can continue the
|
||||
configuration via hwdep sysfs file if hda-reconfig option is enabled.
|
||||
|
||||
|
||||
hda-verb
|
||||
~~~~~~~~
|
||||
|
|
|
@ -116,6 +116,9 @@ SOC_DAPM_SINGLE("HiFi Playback Switch", WM8731_APANA, 4, 1, 0),
|
|||
SND_SOC_DAPM_MIXER("Output Mixer", WM8731_PWR, 4, 1, wm8731_output_mixer_controls,
|
||||
ARRAY_SIZE(wm8731_output_mixer_controls)),
|
||||
|
||||
If you dont want the mixer elements prefixed with the name of the mixer widget,
|
||||
you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same
|
||||
as for SND_SOC_DAPM_MIXER.
|
||||
|
||||
2.3 Platform/Machine domain Widgets
|
||||
-----------------------------------
|
||||
|
|
|
@ -1,23 +0,0 @@
|
|||
To configure the Crystal CS423x sound chip and activate its DSP functions,
|
||||
modules may be loaded in this order:
|
||||
|
||||
modprobe sound
|
||||
insmod ad1848
|
||||
insmod uart401
|
||||
insmod cs4232 io=* irq=* dma=* dma2=*
|
||||
|
||||
This is the meaning of the parameters:
|
||||
|
||||
io--I/O address of the Windows Sound System (normally 0x534)
|
||||
irq--IRQ of this device
|
||||
dma and dma2--DMA channels (DMA2 may be 0)
|
||||
|
||||
On some cards, the board attempts to do non-PnP setup, and fails. If you
|
||||
have problems, use Linux' PnP facilities.
|
||||
|
||||
To get MIDI facilities add
|
||||
|
||||
insmod opl3 io=*
|
||||
|
||||
where "io" is the I/O address of the OPL3 synthesizer. This will be shown
|
||||
in /proc/sys/pnp and is normally 0x388.
|
|
@ -80,7 +80,7 @@ Notes:
|
|||
additional features.
|
||||
|
||||
2. The commercial OSS driver may be obtained from the site:
|
||||
http://www/opensound.com. This may be used for cards that
|
||||
http://www.opensound.com. This may be used for cards that
|
||||
are unsupported by the kernel driver, or may be used
|
||||
by other operating systems.
|
||||
|
||||
|
|
|
@ -78,12 +78,10 @@ to view your kernel log and look for "mmiotrace has lost events" warning. If
|
|||
events were lost, the trace is incomplete. You should enlarge the buffers and
|
||||
try again. Buffers are enlarged by first seeing how large the current buffers
|
||||
are:
|
||||
$ cat /debug/tracing/trace_entries
|
||||
$ cat /debug/tracing/buffer_size_kb
|
||||
gives you a number. Approximately double this number and write it back, for
|
||||
instance:
|
||||
$ echo 0 > /debug/tracing/tracing_enabled
|
||||
$ echo 128000 > /debug/tracing/trace_entries
|
||||
$ echo 1 > /debug/tracing/tracing_enabled
|
||||
$ echo 128000 > /debug/tracing/buffer_size_kb
|
||||
Then start again from the top.
|
||||
|
||||
If you are doing a trace for a driver project, e.g. Nouveau, you should also
|
||||
|
|
|
@ -6,8 +6,9 @@ in the kernel usb programming guide (kerneldoc, from the source code).
|
|||
API OVERVIEW
|
||||
|
||||
The big picture is that USB drivers can continue to ignore most DMA issues,
|
||||
though they still must provide DMA-ready buffers (see DMA-mapping.txt).
|
||||
That's how they've worked through the 2.4 (and earlier) kernels.
|
||||
though they still must provide DMA-ready buffers (see
|
||||
Documentation/PCI/PCI-DMA-mapping.txt). That's how they've worked through
|
||||
the 2.4 (and earlier) kernels.
|
||||
|
||||
OR: they can now be DMA-aware.
|
||||
|
||||
|
@ -62,8 +63,8 @@ and effects like cache-trashing can impose subtle penalties.
|
|||
force a consistent memory access ordering by using memory barriers. It's
|
||||
not using a streaming DMA mapping, so it's good for small transfers on
|
||||
systems where the I/O would otherwise thrash an IOMMU mapping. (See
|
||||
Documentation/DMA-mapping.txt for definitions of "coherent" and "streaming"
|
||||
DMA mappings.)
|
||||
Documentation/PCI/PCI-DMA-mapping.txt for definitions of "coherent" and
|
||||
"streaming" DMA mappings.)
|
||||
|
||||
Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
|
||||
space-efficient.
|
||||
|
@ -93,7 +94,7 @@ WORKING WITH EXISTING BUFFERS
|
|||
Existing buffers aren't usable for DMA without first being mapped into the
|
||||
DMA address space of the device. However, most buffers passed to your
|
||||
driver can safely be used with such DMA mapping. (See the first section
|
||||
of DMA-mapping.txt, titled "What memory is DMA-able?")
|
||||
of Documentation/PCI/PCI-DMA-mapping.txt, titled "What memory is DMA-able?")
|
||||
|
||||
- When you're using scatterlists, you can map everything at once. On some
|
||||
systems, this kicks in an IOMMU and turns the scatterlists into single
|
||||
|
|
|
@ -229,16 +229,26 @@ struct usbmon_packet {
|
|||
int status; /* 28: */
|
||||
unsigned int length; /* 32: Length of data (submitted or actual) */
|
||||
unsigned int len_cap; /* 36: Delivered length */
|
||||
unsigned char setup[8]; /* 40: Only for Control 'S' */
|
||||
}; /* 48 bytes total */
|
||||
union { /* 40: */
|
||||
unsigned char setup[SETUP_LEN]; /* Only for Control S-type */
|
||||
struct iso_rec { /* Only for ISO */
|
||||
int error_count;
|
||||
int numdesc;
|
||||
} iso;
|
||||
} s;
|
||||
int interval; /* 48: Only for Interrupt and ISO */
|
||||
int start_frame; /* 52: For ISO */
|
||||
unsigned int xfer_flags; /* 56: copy of URB's transfer_flags */
|
||||
unsigned int ndesc; /* 60: Actual number of ISO descriptors */
|
||||
}; /* 64 total length */
|
||||
|
||||
These events can be received from a character device by reading with read(2),
|
||||
with an ioctl(2), or by accessing the buffer with mmap.
|
||||
with an ioctl(2), or by accessing the buffer with mmap. However, read(2)
|
||||
only returns first 48 bytes for compatibility reasons.
|
||||
|
||||
The character device is usually called /dev/usbmonN, where N is the USB bus
|
||||
number. Number zero (/dev/usbmon0) is special and means "all buses".
|
||||
However, this feature is not implemented yet. Note that specific naming
|
||||
policy is set by your Linux distribution.
|
||||
Note that specific naming policy is set by your Linux distribution.
|
||||
|
||||
If you create /dev/usbmon0 by hand, make sure that it is owned by root
|
||||
and has mode 0600. Otherwise, unpriviledged users will be able to snoop
|
||||
|
@ -279,9 +289,10 @@ size is out of [unspecified] bounds for this kernel, the call fails with
|
|||
This call returns the current size of the buffer in bytes.
|
||||
|
||||
MON_IOCX_GET, defined as _IOW(MON_IOC_MAGIC, 6, struct mon_get_arg)
|
||||
MON_IOCX_GETX, defined as _IOW(MON_IOC_MAGIC, 10, struct mon_get_arg)
|
||||
|
||||
This call waits for events to arrive if none were in the kernel buffer,
|
||||
then returns the first event. Its argument is a pointer to the following
|
||||
These calls wait for events to arrive if none were in the kernel buffer,
|
||||
then return the first event. The argument is a pointer to the following
|
||||
structure:
|
||||
|
||||
struct mon_get_arg {
|
||||
|
@ -294,6 +305,8 @@ Before the call, hdr, data, and alloc should be filled. Upon return, the area
|
|||
pointed by hdr contains the next event structure, and the data buffer contains
|
||||
the data, if any. The event is removed from the kernel buffer.
|
||||
|
||||
The MON_IOCX_GET copies 48 bytes, MON_IOCX_GETX copies 64 bytes.
|
||||
|
||||
MON_IOCX_MFETCH, defined as _IOWR(MON_IOC_MAGIC, 7, struct mon_mfetch_arg)
|
||||
|
||||
This ioctl is primarily used when the application accesses the buffer
|
||||
|
|
|
@ -4,12 +4,21 @@
|
|||
*
|
||||
* Compile with:
|
||||
* gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab
|
||||
* Use as:
|
||||
* v4lgrab >image.ppm
|
||||
* Use as:
|
||||
* v4lgrab >image.ppm
|
||||
*
|
||||
* Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org>
|
||||
* Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
|
||||
* with minor modifications (Dave Forrest, drf5n@virginia.edu).
|
||||
* Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
|
||||
* with minor modifications (Dave Forrest, drf5n@virginia.edu).
|
||||
*
|
||||
*
|
||||
* For some cameras you may need to pre-load libv4l to perform
|
||||
* the necessary decompression, e.g.:
|
||||
*
|
||||
* export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
|
||||
* ./v4lgrab >image.ppm
|
||||
*
|
||||
* see http://hansdegoede.livejournal.com/3636.html for details.
|
||||
*
|
||||
*/
|
||||
|
||||
|
@ -24,7 +33,7 @@
|
|||
#include <linux/types.h>
|
||||
#include <linux/videodev.h>
|
||||
|
||||
#define FILE "/dev/video0"
|
||||
#define VIDEO_DEV "/dev/video0"
|
||||
|
||||
/* Stole this from tvset.c */
|
||||
|
||||
|
@ -90,7 +99,7 @@ int get_brightness_adj(unsigned char *image, long size, int *brightness) {
|
|||
|
||||
int main(int argc, char ** argv)
|
||||
{
|
||||
int fd = open(FILE, O_RDONLY), f;
|
||||
int fd = open(VIDEO_DEV, O_RDONLY), f;
|
||||
struct video_capability cap;
|
||||
struct video_window win;
|
||||
struct video_picture vpic;
|
||||
|
@ -100,13 +109,13 @@ int main(int argc, char ** argv)
|
|||
unsigned int i, src_depth;
|
||||
|
||||
if (fd < 0) {
|
||||
perror(FILE);
|
||||
perror(VIDEO_DEV);
|
||||
exit(1);
|
||||
}
|
||||
|
||||
if (ioctl(fd, VIDIOCGCAP, &cap) < 0) {
|
||||
perror("VIDIOGCAP");
|
||||
fprintf(stderr, "(" FILE " not a video4linux device?)\n");
|
||||
fprintf(stderr, "(" VIDEO_DEV " not a video4linux device?)\n");
|
||||
close(fd);
|
||||
exit(1);
|
||||
}
|
||||
|
|
124
MAINTAINERS
124
MAINTAINERS
|
@ -692,6 +692,13 @@ M: kernel@wantstofly.org
|
|||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
S: Maintained
|
||||
|
||||
ARM/NUVOTON W90X900 ARM ARCHITECTURE
|
||||
P: Wan ZongShun
|
||||
M: mcuos.com@gmail.com
|
||||
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
|
||||
W: http://www.mcuos.com
|
||||
S: Maintained
|
||||
|
||||
ARPD SUPPORT
|
||||
P: Jonathan Layes
|
||||
L: netdev@vger.kernel.org
|
||||
|
@ -911,7 +918,7 @@ S: Maintained
|
|||
BLACKFIN ARCHITECTURE
|
||||
P: Bryan Wu
|
||||
M: cooloney@kernel.org
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only)
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org
|
||||
W: http://blackfin.uclinux.org
|
||||
S: Supported
|
||||
|
||||
|
@ -1004,6 +1011,8 @@ L: netdev@vger.kernel.org
|
|||
S: Supported
|
||||
|
||||
BROADCOM TG3 GIGABIT ETHERNET DRIVER
|
||||
P: Matt Carlson
|
||||
M: mcarlson@broadcom.com
|
||||
P: Michael Chan
|
||||
M: mchan@broadcom.com
|
||||
L: netdev@vger.kernel.org
|
||||
|
@ -1021,6 +1030,14 @@ M: mb@bu3sch.de
|
|||
W: http://bu3sch.de/btgpio.php
|
||||
S: Maintained
|
||||
|
||||
BTRFS FILE SYSTEM
|
||||
P: Chris Mason
|
||||
M: chris.mason@oracle.com
|
||||
L: linux-btrfs@vger.kernel.org
|
||||
W: http://btrfs.wiki.kernel.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mason/btrfs-unstable.git
|
||||
S: Maintained
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@infradead.org
|
||||
|
@ -1194,6 +1211,8 @@ S: Supported
|
|||
CONTROL GROUPS (CGROUPS)
|
||||
P: Paul Menage
|
||||
M: menage@google.com
|
||||
P: Li Zefan
|
||||
M: lizf@cn.fujitsu.com
|
||||
L: containers@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -1252,6 +1271,12 @@ L: linux-crypto@vger.kernel.org
|
|||
T: git kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
|
||||
S: Maintained
|
||||
|
||||
CRYPTOGRAPHIC RANDOM NUMBER GENERATOR
|
||||
P: Neil Horman
|
||||
M: nhorman@tuxdriver.com
|
||||
L: linux-crypto@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
CS5535 Audio ALSA driver
|
||||
P: Jaya Kumar
|
||||
M: jayakumar.alsa@gmail.com
|
||||
|
@ -1452,8 +1477,6 @@ L: linux-acpi@vger.kernel.org
|
|||
S: Supported
|
||||
|
||||
DOCUMENTATION (/Documentation directory)
|
||||
P: Michael Kerrisk
|
||||
M: mtk.manpages@gmail.com
|
||||
P: Randy Dunlap
|
||||
M: rdunlap@xenotime.net
|
||||
L: linux-doc@vger.kernel.org
|
||||
|
@ -1895,10 +1918,10 @@ W: http://gigaset307x.sourceforge.net/
|
|||
S: Maintained
|
||||
|
||||
HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER
|
||||
P: Robert Love
|
||||
M: rlove@rlove.org
|
||||
M: linux-kernel@vger.kernel.org
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/rml/hdaps/
|
||||
P: Frank Seidel
|
||||
M: frank@f-seidel.de
|
||||
L: lm-sensors@lm-sensors.org
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
|
||||
S: Maintained
|
||||
|
||||
GSPCA FINEPIX SUBDRIVER
|
||||
|
@ -1991,7 +2014,7 @@ S: Maintained
|
|||
|
||||
HIBERNATION (aka Software Suspend, aka swsusp)
|
||||
P: Pavel Machek
|
||||
M: pavel@suse.cz
|
||||
M: pavel@ucw.cz
|
||||
P: Rafael J. Wysocki
|
||||
M: rjw@sisk.pl
|
||||
L: linux-pm@lists.linux-foundation.org
|
||||
|
@ -2102,7 +2125,8 @@ M: khali@linux-fr.org
|
|||
P: Ben Dooks (embedded platforms)
|
||||
M: ben-linux@fluff.org
|
||||
L: linux-i2c@vger.kernel.org
|
||||
T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
|
||||
W: http://i2c.wiki.kernel.org/
|
||||
T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
|
||||
S: Maintained
|
||||
|
||||
I2C-TINY-USB DRIVER
|
||||
|
@ -2200,6 +2224,11 @@ M: stefanr@s5r6.in-berlin.de
|
|||
L: linux1394-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
|
||||
P: Mimi Zohar
|
||||
M: zohar@us.ibm.com
|
||||
S: Supported
|
||||
|
||||
IMS TWINTURBO FRAMEBUFFER DRIVER
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
S: Orphan
|
||||
|
@ -2211,7 +2240,7 @@ P: Sean Hefty
|
|||
M: sean.hefty@intel.com
|
||||
P: Hal Rosenstock
|
||||
M: hal.rosenstock@gmail.com
|
||||
L: general@lists.openfabrics.org
|
||||
L: general@lists.openfabrics.org (moderated for non-subscribers)
|
||||
W: http://www.openib.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
|
||||
S: Supported
|
||||
|
@ -2446,7 +2475,7 @@ S: Maintained
|
|||
|
||||
ISDN SUBSYSTEM
|
||||
P: Karsten Keil
|
||||
M: kkeil@suse.de
|
||||
M: isdn@linux-pingi.de
|
||||
L: isdn4linux@listserv.isdn4linux.de (subscribers-only)
|
||||
W: http://www.isdn4linux.de
|
||||
T: git kernel.org:/pub/scm/linux/kernel/kkeil/isdn-2.6.git
|
||||
|
@ -2816,7 +2845,7 @@ P: Roman Zippel
|
|||
M: zippel@linux-m68k.org
|
||||
L: linux-m68k@lists.linux-m68k.org
|
||||
W: http://www.linux-m68k.org/
|
||||
W: http://linux-m68k-cvs.ubb.ca/
|
||||
T: git git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
|
||||
S: Maintained
|
||||
|
||||
M68K ON APPLE MACINTOSH
|
||||
|
@ -2835,8 +2864,6 @@ S: Maintained
|
|||
MAC80211
|
||||
P: Johannes Berg
|
||||
M: johannes@sipsolutions.net
|
||||
P: Michael Wu
|
||||
M: flamingice@sourmilk.net
|
||||
L: linux-wireless@vger.kernel.org
|
||||
W: http://linuxwireless.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
|
||||
|
@ -2863,7 +2890,7 @@ P: Michael Kerrisk
|
|||
M: mtk.manpages@gmail.com
|
||||
W: http://www.kernel.org/doc/man-pages
|
||||
L: linux-man@vger.kernel.org
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
MARVELL LIBERTAS WIRELESS DRIVER
|
||||
P: Dan Williams
|
||||
|
@ -3318,8 +3345,8 @@ P: Jeremy Fitzhardinge
|
|||
M: jeremy@xensource.com
|
||||
P: Chris Wright
|
||||
M: chrisw@sous-sol.org
|
||||
P: Zachary Amsden
|
||||
M: zach@vmware.com
|
||||
P: Alok Kataria
|
||||
M: akataria@vmware.com
|
||||
P: Rusty Russell
|
||||
M: rusty@rustcorp.com.au
|
||||
L: virtualization@lists.osdl.org
|
||||
|
@ -3336,10 +3363,8 @@ S: Maintained
|
|||
PARISC ARCHITECTURE
|
||||
P: Kyle McMartin
|
||||
M: kyle@mcmartin.ca
|
||||
P: Matthew Wilcox
|
||||
M: matthew@wil.cx
|
||||
P: Grant Grundler
|
||||
M: grundler@parisc-linux.org
|
||||
P: Helge Deller
|
||||
M: deller@gmx.de
|
||||
L: linux-parisc@vger.kernel.org
|
||||
W: http://www.parisc-linux.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/kyle/parisc-2.6.git
|
||||
|
@ -3530,6 +3555,12 @@ S: Maintained
|
|||
PXA MMCI DRIVER
|
||||
S: Orphan
|
||||
|
||||
PXA RTC DRIVER
|
||||
P: Robert Jarzmik
|
||||
M: robert.jarzmik@free.fr
|
||||
L: rtc-linux@googlegroups.com
|
||||
S: Maintained
|
||||
|
||||
QLOGIC QLA2XXX FC-SCSI DRIVER
|
||||
P: Andrew Vasquez
|
||||
M: linux-driver@qlogic.com
|
||||
|
@ -3617,6 +3648,12 @@ M: florian.fainelli@telecomint.eu
|
|||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
RDS - RELIABLE DATAGRAM SOCKETS
|
||||
P: Andy Grover
|
||||
M: andy.grover@oracle.com
|
||||
L: rds-devel@oss.oracle.com
|
||||
S: Supported
|
||||
|
||||
READ-COPY UPDATE (RCU)
|
||||
P: Dipankar Sarma
|
||||
M: dipankar@in.ibm.com
|
||||
|
@ -3708,6 +3745,15 @@ L: linux-s390@vger.kernel.org
|
|||
W: http://www.ibm.com/developerworks/linux/linux390/
|
||||
S: Supported
|
||||
|
||||
S390 ZCRYPT DRIVER
|
||||
P: Felix Beck
|
||||
M: felix.beck@de.ibm.com
|
||||
P: Ralph Wuerthner
|
||||
M: ralph.wuerthner@de.ibm.com
|
||||
M: linux390@de.ibm.com
|
||||
L: linux-s390@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
S390 ZFCP DRIVER
|
||||
P: Christof Schmitt
|
||||
M: christof.schmitt@de.ibm.com
|
||||
|
@ -3826,6 +3872,7 @@ M: jmorris@namei.org
|
|||
L: linux-kernel@vger.kernel.org
|
||||
L: linux-security-module@vger.kernel.org (suggested Cc:)
|
||||
T: git kernel.org:pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git
|
||||
W: http://security.wiki.kernel.org/
|
||||
S: Supported
|
||||
|
||||
SECURITY CONTACT
|
||||
|
@ -3858,6 +3905,15 @@ L: linux-ide@vger.kernel.org
|
|||
T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
|
||||
S: Supported
|
||||
|
||||
SERVER ENGINES 10Gbps NIC - BladeEngine 2 DRIVER
|
||||
P: Sathya Perla
|
||||
M: sathyap@serverengines.com
|
||||
P: Subbu Seetharaman
|
||||
M: subbus@serverengines.com
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.serverengines.com
|
||||
S: Supported
|
||||
|
||||
SFC NETWORK DRIVER
|
||||
P: Steve Hodgson
|
||||
P: Ben Hutchings
|
||||
|
@ -4157,7 +4213,7 @@ SUSPEND TO RAM
|
|||
P: Len Brown
|
||||
M: len.brown@intel.com
|
||||
P: Pavel Machek
|
||||
M: pavel@suse.cz
|
||||
M: pavel@ucw.cz
|
||||
P: Rafael J. Wysocki
|
||||
M: rjw@sisk.pl
|
||||
L: linux-pm@lists.linux-foundation.org
|
||||
|
@ -4258,6 +4314,19 @@ L: tlan-devel@lists.sourceforge.net (subscribers-only)
|
|||
W: http://sourceforge.net/projects/tlan/
|
||||
S: Maintained
|
||||
|
||||
TOMOYO SECURITY MODULE
|
||||
P: Kentaro Takeda
|
||||
M: takedakn@nttdata.co.jp
|
||||
P: Tetsuo Handa
|
||||
M: penguin-kernel@I-love.SAKURA.ne.jp
|
||||
L: linux-kernel@vger.kernel.org (kernel issues)
|
||||
L: tomoyo-users-en@lists.sourceforge.jp (subscribers-only, for developers and users in English)
|
||||
L: tomoyo-dev@lists.sourceforge.jp (subscribers-only, for developers in Japanese)
|
||||
L: tomoyo-users@lists.sourceforge.jp (subscribers-only, for users in Japanese)
|
||||
W: http://tomoyo.sourceforge.jp/
|
||||
T: quilt http://svn.sourceforge.jp/svnroot/tomoyo/trunk/2.2.x/tomoyo-lsm/patches/
|
||||
S: Maintained
|
||||
|
||||
TOSHIBA ACPI EXTRAS DRIVER
|
||||
P: John Belmonte
|
||||
M: toshiba_acpi@memebeam.org
|
||||
|
@ -4278,8 +4347,8 @@ P: Rajiv Andrade
|
|||
M: srajiv@linux.vnet.ibm.com
|
||||
W: http://tpmdd.sourceforge.net
|
||||
P: Marcel Selhorst
|
||||
M: tpm@selhorst.net
|
||||
W: http://www.prosec.rub.de/tpm/
|
||||
M: m.selhorst@sirrix.com
|
||||
W: http://www.sirrix.com
|
||||
L: tpmdd-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
||||
|
@ -4842,6 +4911,7 @@ P: Ingo Molnar
|
|||
M: mingo@redhat.com
|
||||
P: H. Peter Anvin
|
||||
M: hpa@zytor.com
|
||||
M: x86@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
T: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
|
||||
S: Maintained
|
||||
|
@ -4908,11 +4978,11 @@ L: zd1211-devs@lists.sourceforge.net (subscribers-only)
|
|||
S: Maintained
|
||||
|
||||
ZR36067 VIDEO FOR LINUX DRIVER
|
||||
P: Ronald Bultje
|
||||
M: rbultje@ronald.bitfreak.net
|
||||
L: mjpeg-users@lists.sourceforge.net
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://mjpeg.sourceforge.net/driver-zoran/
|
||||
S: Maintained
|
||||
T: Mercurial http://linuxtv.org/hg/v4l-dvb
|
||||
S: Odd Fixes
|
||||
|
||||
ZS DECSTATION Z85C30 SERIAL DRIVER
|
||||
P: Maciej W. Rozycki
|
||||
|
|
93
Makefile
93
Makefile
|
@ -1,8 +1,8 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 29
|
||||
EXTRAVERSION = -rc1
|
||||
NAME = Erotic Pickled Herring
|
||||
EXTRAVERSION =
|
||||
NAME = Temporary Tasmanian Devil
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
@ -213,6 +213,10 @@ endif
|
|||
# Where to locate arch specific headers
|
||||
hdr-arch := $(SRCARCH)
|
||||
|
||||
ifeq ($(ARCH),m68knommu)
|
||||
hdr-arch := m68k
|
||||
endif
|
||||
|
||||
KCONFIG_CONFIG ?= .config
|
||||
|
||||
# SHELL used by kbuild
|
||||
|
@ -385,6 +389,7 @@ PHONY += outputmakefile
|
|||
# output directory.
|
||||
outputmakefile:
|
||||
ifneq ($(KBUILD_SRC),)
|
||||
$(Q)ln -fsn $(srctree) source
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \
|
||||
$(srctree) $(objtree) $(VERSION) $(PATCHLEVEL)
|
||||
endif
|
||||
|
@ -561,6 +566,12 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
|
|||
# disable pointer signed / unsigned warnings in gcc 4.0
|
||||
KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
|
||||
|
||||
# disable invalid "can't wrap" optimzations for signed / pointers
|
||||
KBUILD_CFLAGS += $(call cc-option,-fwrapv)
|
||||
|
||||
# revert to pre-gcc-4.4 behaviour of .eh_frame
|
||||
KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
|
||||
|
||||
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
|
||||
# But warn user when we do so
|
||||
warn-assign = \
|
||||
|
@ -606,25 +617,20 @@ export INSTALL_PATH ?= /boot
|
|||
MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
|
||||
export MODLIB
|
||||
|
||||
strip-symbols := $(srctree)/scripts/strip-symbols \
|
||||
$(wildcard $(srctree)/arch/$(ARCH)/scripts/strip-symbols)
|
||||
|
||||
#
|
||||
# INSTALL_MOD_STRIP, if defined, will cause modules to be stripped while
|
||||
# they get installed. If INSTALL_MOD_STRIP is '1', then the default
|
||||
# options (see below) will be used. Otherwise, INSTALL_MOD_STRIP will
|
||||
# be used as the option(s) to the objcopy command.
|
||||
# INSTALL_MOD_STRIP, if defined, will cause modules to be
|
||||
# stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
|
||||
# the default option --strip-debug will be used. Otherwise,
|
||||
# INSTALL_MOD_STRIP will used as the options to the strip command.
|
||||
|
||||
ifdef INSTALL_MOD_STRIP
|
||||
ifeq ($(INSTALL_MOD_STRIP),1)
|
||||
mod_strip_cmd = $(OBJCOPY) --strip-debug
|
||||
ifeq ($(CONFIG_KALLSYMS_ALL),$(CONFIG_KALLSYMS_STRIP_GENERATED))
|
||||
mod_strip_cmd += --wildcard $(addprefix --strip-symbols ,$(strip-symbols))
|
||||
endif
|
||||
mod_strip_cmd = $(STRIP) --strip-debug
|
||||
else
|
||||
mod_strip_cmd = $(OBJCOPY) $(INSTALL_MOD_STRIP)
|
||||
mod_strip_cmd = $(STRIP) $(INSTALL_MOD_STRIP)
|
||||
endif # INSTALL_MOD_STRIP=1
|
||||
else
|
||||
mod_strip_cmd = false
|
||||
mod_strip_cmd = true
|
||||
endif # INSTALL_MOD_STRIP
|
||||
export mod_strip_cmd
|
||||
|
||||
|
@ -754,7 +760,6 @@ last_kallsyms := 2
|
|||
endif
|
||||
|
||||
kallsyms.o := .tmp_kallsyms$(last_kallsyms).o
|
||||
kallsyms.h := $(wildcard include/config/kallsyms/*.h) $(wildcard include/config/kallsyms/*/*.h)
|
||||
|
||||
define verify_kallsyms
|
||||
$(Q)$(if $($(quiet)cmd_sysmap), \
|
||||
|
@ -779,41 +784,24 @@ endef
|
|||
|
||||
# Generate .S file with all kernel symbols
|
||||
quiet_cmd_kallsyms = KSYM $@
|
||||
cmd_kallsyms = { test $* -eq 0 || $(NM) -n $<; } \
|
||||
| $(KALLSYMS) $(if $(CONFIG_KALLSYMS_ALL),--all-symbols) >$@
|
||||
cmd_kallsyms = $(NM) -n $< | $(KALLSYMS) \
|
||||
$(if $(CONFIG_KALLSYMS_ALL),--all-symbols) > $@
|
||||
|
||||
quiet_cmd_kstrip = STRIP $@
|
||||
cmd_kstrip = $(OBJCOPY) --wildcard $(addprefix --strip$(if $(CONFIG_RELOCATABLE),-unneeded)-symbols ,$(filter %/scripts/strip-symbols,$^)) $< $@
|
||||
|
||||
$(foreach n,0 1 2 3,.tmp_kallsyms$(n).o): KBUILD_AFLAGS += -Wa,--strip-local-absolute
|
||||
$(foreach n,0 1 2 3,.tmp_kallsyms$(n).o): %.o: %.S scripts FORCE
|
||||
.tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms3.o: %.o: %.S scripts FORCE
|
||||
$(call if_changed_dep,as_o_S)
|
||||
|
||||
ifeq ($(CONFIG_KALLSYMS_STRIP_GENERATED),y)
|
||||
strip-ext := .stripped
|
||||
endif
|
||||
|
||||
.tmp_kallsyms%.S: .tmp_vmlinux%$(strip-ext) $(KALLSYMS) $(kallsyms.h)
|
||||
.tmp_kallsyms%.S: .tmp_vmlinux% $(KALLSYMS)
|
||||
$(call cmd,kallsyms)
|
||||
|
||||
# make -jN seems to have problems with intermediate files, see bug #3330.
|
||||
.SECONDARY: $(foreach n,1 2 3,.tmp_vmlinux$(n).stripped)
|
||||
.tmp_vmlinux%.stripped: .tmp_vmlinux% $(strip-symbols) $(kallsyms.h)
|
||||
$(call cmd,kstrip)
|
||||
|
||||
ifneq ($(CONFIG_DEBUG_INFO),y)
|
||||
.tmp_vmlinux%: LDFLAGS_vmlinux += -S
|
||||
endif
|
||||
# .tmp_vmlinux1 must be complete except kallsyms, so update vmlinux version
|
||||
.tmp_vmlinux%: $(vmlinux-lds) $(vmlinux-all) FORCE
|
||||
$(if $(filter 1,$*),$(call if_changed_rule,ksym_ld),$(call if_changed,vmlinux__))
|
||||
.tmp_vmlinux1: $(vmlinux-lds) $(vmlinux-all) FORCE
|
||||
$(call if_changed_rule,ksym_ld)
|
||||
|
||||
.tmp_vmlinux0$(strip-ext):
|
||||
$(Q)echo "placeholder" >$@
|
||||
.tmp_vmlinux2: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms1.o FORCE
|
||||
$(call if_changed,vmlinux__)
|
||||
|
||||
.tmp_vmlinux1: .tmp_kallsyms0.o
|
||||
.tmp_vmlinux2: .tmp_kallsyms1.o
|
||||
.tmp_vmlinux3: .tmp_kallsyms2.o
|
||||
.tmp_vmlinux3: $(vmlinux-lds) $(vmlinux-all) .tmp_kallsyms2.o FORCE
|
||||
$(call if_changed,vmlinux__)
|
||||
|
||||
# Needs to visit scripts/ before $(KALLSYMS) can be used.
|
||||
$(KALLSYMS): scripts ;
|
||||
|
@ -922,12 +910,18 @@ localver = $(subst $(space),, $(string) \
|
|||
# and if the SCM is know a tag from the SCM is appended.
|
||||
# The appended tag is determined by the SCM used.
|
||||
#
|
||||
# Currently, only git is supported.
|
||||
# Other SCMs can edit scripts/setlocalversion and add the appropriate
|
||||
# checks as needed.
|
||||
# .scmversion is used when generating rpm packages so we do not loose
|
||||
# the version information from the SCM when we do the build of the kernel
|
||||
# from the copied source
|
||||
ifdef CONFIG_LOCALVERSION_AUTO
|
||||
_localver-auto = $(shell $(CONFIG_SHELL) \
|
||||
$(srctree)/scripts/setlocalversion $(srctree))
|
||||
|
||||
ifeq ($(wildcard .scmversion),)
|
||||
_localver-auto = $(shell $(CONFIG_SHELL) \
|
||||
$(srctree)/scripts/setlocalversion $(srctree))
|
||||
else
|
||||
_localver-auto = $(shell cat .scmversion 2> /dev/null)
|
||||
endif
|
||||
|
||||
localver-auto = $(LOCALVERSION)$(_localver-auto)
|
||||
endif
|
||||
|
||||
|
@ -965,7 +959,6 @@ ifneq ($(KBUILD_SRC),)
|
|||
mkdir -p include2; \
|
||||
ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \
|
||||
fi
|
||||
ln -fsn $(srctree) source
|
||||
endif
|
||||
|
||||
# prepare2 creates a makefile if using a separate output directory
|
||||
|
@ -1556,7 +1549,7 @@ quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
|
|||
cmd_depmod = \
|
||||
if [ -r System.map -a -x $(DEPMOD) ]; then \
|
||||
$(DEPMOD) -ae -F System.map \
|
||||
$(if $(strip $(INSTALL_MOD_PATH)), -b $(INSTALL_MOD_PATH) -r) \
|
||||
$(if $(strip $(INSTALL_MOD_PATH)), -b $(INSTALL_MOD_PATH) ) \
|
||||
$(KERNELRELEASE); \
|
||||
fi
|
||||
|
||||
|
|
2
README
2
README
|
@ -188,7 +188,7 @@ CONFIGURING the kernel:
|
|||
values to random values.
|
||||
|
||||
You can find more information on using the Linux kernel config tools
|
||||
in Documentation/kbuild/make-configs.txt.
|
||||
in Documentation/kbuild/kconfig.txt.
|
||||
|
||||
NOTES on "make config":
|
||||
- having unnecessary drivers will make the kernel bigger, and can
|
||||
|
|
|
@ -8,6 +8,7 @@ config ALPHA
|
|||
select HAVE_AOUT
|
||||
select HAVE_IDE
|
||||
select HAVE_OPROFILE
|
||||
select HAVE_SYSCALL_WRAPPERS
|
||||
help
|
||||
The Alpha is a 64-bit general-purpose processor designed and
|
||||
marketed by the Digital Equipment Corporation of blessed memory,
|
||||
|
|
|
@ -8,17 +8,12 @@
|
|||
|
||||
/* ??? Would be nice to use .gprel32 here, but we can't be sure that the
|
||||
function loaded the GP, so this could fail in modules. */
|
||||
static inline void ATTRIB_NORET __BUG(const char *file, int line)
|
||||
{
|
||||
__asm__ __volatile__(
|
||||
"call_pal %0 # bugchk\n\t"
|
||||
".long %1\n\t.8byte %2"
|
||||
: : "i" (PAL_bugchk), "i"(line), "i"(file));
|
||||
for ( ; ; )
|
||||
;
|
||||
}
|
||||
|
||||
#define BUG() __BUG(__FILE__, __LINE__)
|
||||
#define BUG() do { \
|
||||
__asm__ __volatile__( \
|
||||
"call_pal %0 # bugchk\n\t" \
|
||||
".long %1\n\t.8byte %2" \
|
||||
: : "i"(PAL_bugchk), "i"(__LINE__), "i"(__FILE__)); \
|
||||
for ( ; ; ); } while (0)
|
||||
|
||||
#define HAVE_ARCH_BUG
|
||||
#endif
|
||||
|
|
|
@ -29,6 +29,8 @@
|
|||
|
||||
#else /* no PCI - no IOMMU. */
|
||||
|
||||
#include <asm/io.h> /* for virt_to_phys() */
|
||||
|
||||
struct scatterlist;
|
||||
void *dma_alloc_coherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, gfp_t gfp);
|
||||
|
|
|
@ -62,6 +62,9 @@
|
|||
|
||||
#define SO_MARK 36
|
||||
|
||||
#define SO_TIMESTAMPING 37
|
||||
#define SCM_TIMESTAMPING SO_TIMESTAMPING
|
||||
|
||||
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
|
||||
* have to define SOCK_NONBLOCK to a different value here.
|
||||
*/
|
||||
|
|
|
@ -1,6 +1,8 @@
|
|||
#ifndef _ALPHA_STATFS_H
|
||||
#define _ALPHA_STATFS_H
|
||||
|
||||
#include <linux/types.h>
|
||||
|
||||
/* Alpha is the only 64-bit platform with 32-bit statfs. And doesn't
|
||||
even seem to implement statfs64 */
|
||||
#define __statfs_word __u32
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
#ifndef _ALPHA_SWAB_H
|
||||
#define _ALPHA_SWAB_H
|
||||
|
||||
#include <asm/types.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/compiler.h>
|
||||
#include <asm/compiler.h>
|
||||
|
||||
|
|
|
@ -933,7 +933,7 @@ sys_execve:
|
|||
osf_sigprocmask:
|
||||
.prologue 0
|
||||
mov $sp, $18
|
||||
jmp $31, do_osf_sigprocmask
|
||||
jmp $31, sys_osf_sigprocmask
|
||||
.end osf_sigprocmask
|
||||
|
||||
.align 4
|
||||
|
|
|
@ -90,7 +90,7 @@ show_interrupts(struct seq_file *p, void *v)
|
|||
seq_printf(p, "%10u ", kstat_irqs(irq));
|
||||
#else
|
||||
for_each_online_cpu(j)
|
||||
seq_printf(p, "%10u ", kstat_cpu(j).irqs[irq]);
|
||||
seq_printf(p, "%10u ", kstat_irqs_cpu(irq, j));
|
||||
#endif
|
||||
seq_printf(p, " %14s", irq_desc[irq].chip->typename);
|
||||
seq_printf(p, " %c%s",
|
||||
|
|
|
@ -64,7 +64,7 @@ do_entInt(unsigned long type, unsigned long vector,
|
|||
smp_percpu_timer_interrupt(regs);
|
||||
cpu = smp_processor_id();
|
||||
if (cpu != boot_cpuid) {
|
||||
kstat_cpu(cpu).irqs[RTC_IRQ]++;
|
||||
kstat_incr_irqs_this_cpu(RTC_IRQ, irq_to_desc(RTC_IRQ));
|
||||
} else {
|
||||
handle_irq(RTC_IRQ);
|
||||
}
|
||||
|
|
|
@ -54,8 +54,7 @@ extern int do_pipe(int *);
|
|||
* identical to OSF as we don't return 0 on success, but doing otherwise
|
||||
* would require changes to libc. Hopefully this is good enough.
|
||||
*/
|
||||
asmlinkage unsigned long
|
||||
osf_brk(unsigned long brk)
|
||||
SYSCALL_DEFINE1(osf_brk, unsigned long, brk)
|
||||
{
|
||||
unsigned long retval = sys_brk(brk);
|
||||
if (brk && brk != retval)
|
||||
|
@ -66,9 +65,9 @@ osf_brk(unsigned long brk)
|
|||
/*
|
||||
* This is pure guess-work..
|
||||
*/
|
||||
asmlinkage int
|
||||
osf_set_program_attributes(unsigned long text_start, unsigned long text_len,
|
||||
unsigned long bss_start, unsigned long bss_len)
|
||||
SYSCALL_DEFINE4(osf_set_program_attributes, unsigned long, text_start,
|
||||
unsigned long, text_len, unsigned long, bss_start,
|
||||
unsigned long, bss_len)
|
||||
{
|
||||
struct mm_struct *mm;
|
||||
|
||||
|
@ -146,9 +145,9 @@ Efault:
|
|||
return -EFAULT;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_getdirentries(unsigned int fd, struct osf_dirent __user *dirent,
|
||||
unsigned int count, long __user *basep)
|
||||
SYSCALL_DEFINE4(osf_getdirentries, unsigned int, fd,
|
||||
struct osf_dirent __user *, dirent, unsigned int, count,
|
||||
long __user *, basep)
|
||||
{
|
||||
int error;
|
||||
struct file *file;
|
||||
|
@ -177,9 +176,9 @@ osf_getdirentries(unsigned int fd, struct osf_dirent __user *dirent,
|
|||
|
||||
#undef NAME_OFFSET
|
||||
|
||||
asmlinkage unsigned long
|
||||
osf_mmap(unsigned long addr, unsigned long len, unsigned long prot,
|
||||
unsigned long flags, unsigned long fd, unsigned long off)
|
||||
SYSCALL_DEFINE6(osf_mmap, unsigned long, addr, unsigned long, len,
|
||||
unsigned long, prot, unsigned long, flags, unsigned long, fd,
|
||||
unsigned long, off)
|
||||
{
|
||||
struct file *file = NULL;
|
||||
unsigned long ret = -EBADF;
|
||||
|
@ -254,8 +253,8 @@ do_osf_statfs(struct dentry * dentry, struct osf_statfs __user *buffer,
|
|||
return error;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_statfs(char __user *pathname, struct osf_statfs __user *buffer, unsigned long bufsiz)
|
||||
SYSCALL_DEFINE3(osf_statfs, char __user *, pathname,
|
||||
struct osf_statfs __user *, buffer, unsigned long, bufsiz)
|
||||
{
|
||||
struct path path;
|
||||
int retval;
|
||||
|
@ -268,8 +267,8 @@ osf_statfs(char __user *pathname, struct osf_statfs __user *buffer, unsigned lon
|
|||
return retval;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_fstatfs(unsigned long fd, struct osf_statfs __user *buffer, unsigned long bufsiz)
|
||||
SYSCALL_DEFINE3(osf_fstatfs, unsigned long, fd,
|
||||
struct osf_statfs __user *, buffer, unsigned long, bufsiz)
|
||||
{
|
||||
struct file *file;
|
||||
int retval;
|
||||
|
@ -368,8 +367,8 @@ osf_procfs_mount(char *dirname, struct procfs_args __user *args, int flags)
|
|||
return do_mount("", dirname, "proc", flags, NULL);
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_mount(unsigned long typenr, char __user *path, int flag, void __user *data)
|
||||
SYSCALL_DEFINE4(osf_mount, unsigned long, typenr, char __user *, path,
|
||||
int, flag, void __user *, data)
|
||||
{
|
||||
int retval = -EINVAL;
|
||||
char *name;
|
||||
|
@ -399,8 +398,7 @@ osf_mount(unsigned long typenr, char __user *path, int flag, void __user *data)
|
|||
return retval;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_utsname(char __user *name)
|
||||
SYSCALL_DEFINE1(osf_utsname, char __user *, name)
|
||||
{
|
||||
int error;
|
||||
|
||||
|
@ -423,14 +421,12 @@ osf_utsname(char __user *name)
|
|||
return error;
|
||||
}
|
||||
|
||||
asmlinkage unsigned long
|
||||
sys_getpagesize(void)
|
||||
SYSCALL_DEFINE0(getpagesize)
|
||||
{
|
||||
return PAGE_SIZE;
|
||||
}
|
||||
|
||||
asmlinkage unsigned long
|
||||
sys_getdtablesize(void)
|
||||
SYSCALL_DEFINE0(getdtablesize)
|
||||
{
|
||||
return sysctl_nr_open;
|
||||
}
|
||||
|
@ -438,8 +434,7 @@ sys_getdtablesize(void)
|
|||
/*
|
||||
* For compatibility with OSF/1 only. Use utsname(2) instead.
|
||||
*/
|
||||
asmlinkage int
|
||||
osf_getdomainname(char __user *name, int namelen)
|
||||
SYSCALL_DEFINE2(osf_getdomainname, char __user *, name, int, namelen)
|
||||
{
|
||||
unsigned len;
|
||||
int i;
|
||||
|
@ -527,8 +522,8 @@ enum pl_code {
|
|||
PL_DEL = 5, PL_FDEL = 6
|
||||
};
|
||||
|
||||
asmlinkage long
|
||||
osf_proplist_syscall(enum pl_code code, union pl_args __user *args)
|
||||
SYSCALL_DEFINE2(osf_proplist_syscall, enum pl_code, code,
|
||||
union pl_args __user *, args)
|
||||
{
|
||||
long error;
|
||||
int __user *min_buf_size_ptr;
|
||||
|
@ -567,8 +562,8 @@ osf_proplist_syscall(enum pl_code code, union pl_args __user *args)
|
|||
return error;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_sigstack(struct sigstack __user *uss, struct sigstack __user *uoss)
|
||||
SYSCALL_DEFINE2(osf_sigstack, struct sigstack __user *, uss,
|
||||
struct sigstack __user *, uoss)
|
||||
{
|
||||
unsigned long usp = rdusp();
|
||||
unsigned long oss_sp = current->sas_ss_sp + current->sas_ss_size;
|
||||
|
@ -608,8 +603,7 @@ osf_sigstack(struct sigstack __user *uss, struct sigstack __user *uoss)
|
|||
return error;
|
||||
}
|
||||
|
||||
asmlinkage long
|
||||
osf_sysinfo(int command, char __user *buf, long count)
|
||||
SYSCALL_DEFINE3(osf_sysinfo, int, command, char __user *, buf, long, count)
|
||||
{
|
||||
char *sysinfo_table[] = {
|
||||
utsname()->sysname,
|
||||
|
@ -647,9 +641,8 @@ osf_sysinfo(int command, char __user *buf, long count)
|
|||
return err;
|
||||
}
|
||||
|
||||
asmlinkage unsigned long
|
||||
osf_getsysinfo(unsigned long op, void __user *buffer, unsigned long nbytes,
|
||||
int __user *start, void __user *arg)
|
||||
SYSCALL_DEFINE5(osf_getsysinfo, unsigned long, op, void __user *, buffer,
|
||||
unsigned long, nbytes, int __user *, start, void __user *, arg)
|
||||
{
|
||||
unsigned long w;
|
||||
struct percpu_struct *cpu;
|
||||
|
@ -705,9 +698,8 @@ osf_getsysinfo(unsigned long op, void __user *buffer, unsigned long nbytes,
|
|||
return -EOPNOTSUPP;
|
||||
}
|
||||
|
||||
asmlinkage unsigned long
|
||||
osf_setsysinfo(unsigned long op, void __user *buffer, unsigned long nbytes,
|
||||
int __user *start, void __user *arg)
|
||||
SYSCALL_DEFINE5(osf_setsysinfo, unsigned long, op, void __user *, buffer,
|
||||
unsigned long, nbytes, int __user *, start, void __user *, arg)
|
||||
{
|
||||
switch (op) {
|
||||
case SSI_IEEE_FP_CONTROL: {
|
||||
|
@ -880,8 +872,8 @@ jiffies_to_timeval32(unsigned long jiffies, struct timeval32 *value)
|
|||
value->tv_sec = jiffies / HZ;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_gettimeofday(struct timeval32 __user *tv, struct timezone __user *tz)
|
||||
SYSCALL_DEFINE2(osf_gettimeofday, struct timeval32 __user *, tv,
|
||||
struct timezone __user *, tz)
|
||||
{
|
||||
if (tv) {
|
||||
struct timeval ktv;
|
||||
|
@ -896,8 +888,8 @@ osf_gettimeofday(struct timeval32 __user *tv, struct timezone __user *tz)
|
|||
return 0;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_settimeofday(struct timeval32 __user *tv, struct timezone __user *tz)
|
||||
SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 __user *, tv,
|
||||
struct timezone __user *, tz)
|
||||
{
|
||||
struct timespec kts;
|
||||
struct timezone ktz;
|
||||
|
@ -916,8 +908,7 @@ osf_settimeofday(struct timeval32 __user *tv, struct timezone __user *tz)
|
|||
return do_sys_settimeofday(tv ? &kts : NULL, tz ? &ktz : NULL);
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_getitimer(int which, struct itimerval32 __user *it)
|
||||
SYSCALL_DEFINE2(osf_getitimer, int, which, struct itimerval32 __user *, it)
|
||||
{
|
||||
struct itimerval kit;
|
||||
int error;
|
||||
|
@ -929,8 +920,8 @@ osf_getitimer(int which, struct itimerval32 __user *it)
|
|||
return error;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_setitimer(int which, struct itimerval32 __user *in, struct itimerval32 __user *out)
|
||||
SYSCALL_DEFINE3(osf_setitimer, int, which, struct itimerval32 __user *, in,
|
||||
struct itimerval32 __user *, out)
|
||||
{
|
||||
struct itimerval kin, kout;
|
||||
int error;
|
||||
|
@ -952,8 +943,8 @@ osf_setitimer(int which, struct itimerval32 __user *in, struct itimerval32 __use
|
|||
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_utimes(char __user *filename, struct timeval32 __user *tvs)
|
||||
SYSCALL_DEFINE2(osf_utimes, char __user *, filename,
|
||||
struct timeval32 __user *, tvs)
|
||||
{
|
||||
struct timespec tv[2];
|
||||
|
||||
|
@ -979,9 +970,8 @@ osf_utimes(char __user *filename, struct timeval32 __user *tvs)
|
|||
#define MAX_SELECT_SECONDS \
|
||||
((unsigned long) (MAX_SCHEDULE_TIMEOUT / HZ)-1)
|
||||
|
||||
asmlinkage int
|
||||
osf_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp,
|
||||
struct timeval32 __user *tvp)
|
||||
SYSCALL_DEFINE5(osf_select, int, n, fd_set __user *, inp, fd_set __user *, outp,
|
||||
fd_set __user *, exp, struct timeval32 __user *, tvp)
|
||||
{
|
||||
struct timespec end_time, *to = NULL;
|
||||
if (tvp) {
|
||||
|
@ -1026,8 +1016,7 @@ struct rusage32 {
|
|||
long ru_nivcsw; /* involuntary " */
|
||||
};
|
||||
|
||||
asmlinkage int
|
||||
osf_getrusage(int who, struct rusage32 __user *ru)
|
||||
SYSCALL_DEFINE2(osf_getrusage, int, who, struct rusage32 __user *, ru)
|
||||
{
|
||||
struct rusage32 r;
|
||||
|
||||
|
@ -1053,9 +1042,8 @@ osf_getrusage(int who, struct rusage32 __user *ru)
|
|||
return copy_to_user(ru, &r, sizeof(r)) ? -EFAULT : 0;
|
||||
}
|
||||
|
||||
asmlinkage long
|
||||
osf_wait4(pid_t pid, int __user *ustatus, int options,
|
||||
struct rusage32 __user *ur)
|
||||
SYSCALL_DEFINE4(osf_wait4, pid_t, pid, int __user *, ustatus, int, options,
|
||||
struct rusage32 __user *, ur)
|
||||
{
|
||||
struct rusage r;
|
||||
long ret, err;
|
||||
|
@ -1101,8 +1089,8 @@ osf_wait4(pid_t pid, int __user *ustatus, int options,
|
|||
* seems to be a timeval pointer, and I suspect the second
|
||||
* one is the time remaining.. Ho humm.. No documentation.
|
||||
*/
|
||||
asmlinkage int
|
||||
osf_usleep_thread(struct timeval32 __user *sleep, struct timeval32 __user *remain)
|
||||
SYSCALL_DEFINE2(osf_usleep_thread, struct timeval32 __user *, sleep,
|
||||
struct timeval32 __user *, remain)
|
||||
{
|
||||
struct timeval tmp;
|
||||
unsigned long ticks;
|
||||
|
@ -1155,8 +1143,7 @@ struct timex32 {
|
|||
int :32; int :32; int :32; int :32;
|
||||
};
|
||||
|
||||
asmlinkage int
|
||||
sys_old_adjtimex(struct timex32 __user *txc_p)
|
||||
SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
|
||||
{
|
||||
struct timex txc;
|
||||
int ret;
|
||||
|
@ -1267,8 +1254,8 @@ osf_fix_iov_len(const struct iovec __user *iov, unsigned long count)
|
|||
return 0;
|
||||
}
|
||||
|
||||
asmlinkage ssize_t
|
||||
osf_readv(unsigned long fd, const struct iovec __user * vector, unsigned long count)
|
||||
SYSCALL_DEFINE3(osf_readv, unsigned long, fd,
|
||||
const struct iovec __user *, vector, unsigned long, count)
|
||||
{
|
||||
if (unlikely(personality(current->personality) == PER_OSF4))
|
||||
if (osf_fix_iov_len(vector, count))
|
||||
|
@ -1276,8 +1263,8 @@ osf_readv(unsigned long fd, const struct iovec __user * vector, unsigned long co
|
|||
return sys_readv(fd, vector, count);
|
||||
}
|
||||
|
||||
asmlinkage ssize_t
|
||||
osf_writev(unsigned long fd, const struct iovec __user * vector, unsigned long count)
|
||||
SYSCALL_DEFINE3(osf_writev, unsigned long, fd,
|
||||
const struct iovec __user *, vector, unsigned long, count)
|
||||
{
|
||||
if (unlikely(personality(current->personality) == PER_OSF4))
|
||||
if (osf_fix_iov_len(vector, count))
|
||||
|
|
|
@ -109,7 +109,8 @@ sys_pciconfig_write(unsigned long bus, unsigned long dfn,
|
|||
/* Stubs for the routines in pci_iommu.c: */
|
||||
|
||||
void *
|
||||
pci_alloc_consistent(struct pci_dev *pdev, size_t size, dma_addr_t *dma_addrp)
|
||||
__pci_alloc_consistent(struct pci_dev *pdev, size_t size,
|
||||
dma_addr_t *dma_addrp, gfp_t gfp)
|
||||
{
|
||||
return NULL;
|
||||
}
|
||||
|
|
|
@ -93,8 +93,8 @@ common_shutdown_1(void *generic_ptr)
|
|||
if (cpuid != boot_cpuid) {
|
||||
flags |= 0x00040000UL; /* "remain halted" */
|
||||
*pflags = flags;
|
||||
cpu_clear(cpuid, cpu_present_map);
|
||||
cpu_clear(cpuid, cpu_possible_map);
|
||||
set_cpu_present(cpuid, false);
|
||||
set_cpu_possible(cpuid, false);
|
||||
halt();
|
||||
}
|
||||
#endif
|
||||
|
@ -120,8 +120,8 @@ common_shutdown_1(void *generic_ptr)
|
|||
|
||||
#ifdef CONFIG_SMP
|
||||
/* Wait for the secondaries to halt. */
|
||||
cpu_clear(boot_cpuid, cpu_present_map);
|
||||
cpu_clear(boot_cpuid, cpu_possible_map);
|
||||
set_cpu_present(boot_cpuid, false);
|
||||
set_cpu_possible(boot_cpuid, false);
|
||||
while (cpus_weight(cpu_present_map))
|
||||
barrier();
|
||||
#endif
|
||||
|
|
|
@ -19,6 +19,7 @@
|
|||
#include <linux/tty.h>
|
||||
#include <linux/binfmts.h>
|
||||
#include <linux/bitops.h>
|
||||
#include <linux/syscalls.h>
|
||||
|
||||
#include <asm/uaccess.h>
|
||||
#include <asm/sigcontext.h>
|
||||
|
@ -51,8 +52,8 @@ static void do_signal(struct pt_regs *, struct switch_stack *,
|
|||
* Note that we don't need to acquire the kernel lock for SMP
|
||||
* operation, as all of this is local to this thread.
|
||||
*/
|
||||
asmlinkage unsigned long
|
||||
do_osf_sigprocmask(int how, unsigned long newmask, struct pt_regs *regs)
|
||||
SYSCALL_DEFINE3(osf_sigprocmask, int, how, unsigned long, newmask,
|
||||
struct pt_regs *, regs)
|
||||
{
|
||||
unsigned long oldmask = -EINVAL;
|
||||
|
||||
|
@ -81,9 +82,9 @@ do_osf_sigprocmask(int how, unsigned long newmask, struct pt_regs *regs)
|
|||
return oldmask;
|
||||
}
|
||||
|
||||
asmlinkage int
|
||||
osf_sigaction(int sig, const struct osf_sigaction __user *act,
|
||||
struct osf_sigaction __user *oact)
|
||||
SYSCALL_DEFINE3(osf_sigaction, int, sig,
|
||||
const struct osf_sigaction __user *, act,
|
||||
struct osf_sigaction __user *, oact)
|
||||
{
|
||||
struct k_sigaction new_ka, old_ka;
|
||||
int ret;
|
||||
|
@ -112,10 +113,9 @@ osf_sigaction(int sig, const struct osf_sigaction __user *act,
|
|||
return ret;
|
||||
}
|
||||
|
||||
asmlinkage long
|
||||
sys_rt_sigaction(int sig, const struct sigaction __user *act,
|
||||
struct sigaction __user *oact,
|
||||
size_t sigsetsize, void __user *restorer)
|
||||
SYSCALL_DEFINE5(rt_sigaction, int, sig, const struct sigaction __user *, act,
|
||||
struct sigaction __user *, oact,
|
||||
size_t, sigsetsize, void __user *, restorer)
|
||||
{
|
||||
struct k_sigaction new_ka, old_ka;
|
||||
int ret;
|
||||
|
|
|
@ -121,10 +121,11 @@ smp_callin(void)
|
|||
{
|
||||
int cpuid = hard_smp_processor_id();
|
||||
|
||||
if (cpu_test_and_set(cpuid, cpu_online_map)) {
|
||||
if (cpu_online(cpuid)) {
|
||||
printk("??, cpu 0x%x already present??\n", cpuid);
|
||||
BUG();
|
||||
}
|
||||
set_cpu_online(cpuid, true);
|
||||
|
||||
/* Turn on machine checks. */
|
||||
wrmces(7);
|
||||
|
@ -435,8 +436,8 @@ setup_smp(void)
|
|||
((char *)cpubase + i*hwrpb->processor_size);
|
||||
if ((cpu->flags & 0x1cc) == 0x1cc) {
|
||||
smp_num_probed++;
|
||||
cpu_set(i, cpu_possible_map);
|
||||
cpu_set(i, cpu_present_map);
|
||||
set_cpu_possible(i, true);
|
||||
set_cpu_present(i, true);
|
||||
cpu->pal_revision = boot_cpu_palrev;
|
||||
}
|
||||
|
||||
|
@ -469,8 +470,8 @@ smp_prepare_cpus(unsigned int max_cpus)
|
|||
|
||||
/* Nothing to do on a UP box, or when told not to. */
|
||||
if (smp_num_probed == 1 || max_cpus == 0) {
|
||||
cpu_possible_map = cpumask_of_cpu(boot_cpuid);
|
||||
cpu_present_map = cpumask_of_cpu(boot_cpuid);
|
||||
init_cpu_possible(cpumask_of(boot_cpuid));
|
||||
init_cpu_present(cpumask_of(boot_cpuid));
|
||||
printk(KERN_INFO "SMP mode deactivated.\n");
|
||||
return;
|
||||
}
|
||||
|
|
|
@ -17,7 +17,7 @@ sys_call_table:
|
|||
.quad sys_write
|
||||
.quad alpha_ni_syscall /* 5 */
|
||||
.quad sys_close
|
||||
.quad osf_wait4
|
||||
.quad sys_osf_wait4
|
||||
.quad alpha_ni_syscall
|
||||
.quad sys_link
|
||||
.quad sys_unlink /* 10 */
|
||||
|
@ -27,11 +27,11 @@ sys_call_table:
|
|||
.quad sys_mknod
|
||||
.quad sys_chmod /* 15 */
|
||||
.quad sys_chown
|
||||
.quad osf_brk
|
||||
.quad sys_osf_brk
|
||||
.quad alpha_ni_syscall
|
||||
.quad sys_lseek
|
||||
.quad sys_getxpid /* 20 */
|
||||
.quad osf_mount
|
||||
.quad sys_osf_mount
|
||||
.quad sys_umount
|
||||
.quad sys_setuid
|
||||
.quad sys_getxuid
|
||||
|
@ -53,7 +53,7 @@ sys_call_table:
|
|||
.quad alpha_ni_syscall /* 40 */
|
||||
.quad sys_dup
|
||||
.quad sys_alpha_pipe
|
||||
.quad osf_set_program_attributes
|
||||
.quad sys_osf_set_program_attributes
|
||||
.quad alpha_ni_syscall
|
||||
.quad sys_open /* 45 */
|
||||
.quad alpha_ni_syscall
|
||||
|
@ -81,7 +81,7 @@ sys_call_table:
|
|||
.quad sys_newlstat
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 70 */
|
||||
.quad osf_mmap
|
||||
.quad sys_osf_mmap
|
||||
.quad alpha_ni_syscall
|
||||
.quad sys_munmap
|
||||
.quad sys_mprotect
|
||||
|
@ -94,17 +94,17 @@ sys_call_table:
|
|||
.quad sys_setgroups /* 80 */
|
||||
.quad alpha_ni_syscall
|
||||
.quad sys_setpgid
|
||||
.quad osf_setitimer
|
||||
.quad sys_osf_setitimer
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 85 */
|
||||
.quad osf_getitimer
|
||||
.quad sys_osf_getitimer
|
||||
.quad sys_gethostname
|
||||
.quad sys_sethostname
|
||||
.quad sys_getdtablesize
|
||||
.quad sys_dup2 /* 90 */
|
||||
.quad sys_newfstat
|
||||
.quad sys_fcntl
|
||||
.quad osf_select
|
||||
.quad sys_osf_select
|
||||
.quad sys_poll
|
||||
.quad sys_fsync /* 95 */
|
||||
.quad sys_setpriority
|
||||
|
@ -123,22 +123,22 @@ sys_call_table:
|
|||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 110 */
|
||||
.quad sys_sigsuspend
|
||||
.quad osf_sigstack
|
||||
.quad sys_osf_sigstack
|
||||
.quad sys_recvmsg
|
||||
.quad sys_sendmsg
|
||||
.quad alpha_ni_syscall /* 115 */
|
||||
.quad osf_gettimeofday
|
||||
.quad osf_getrusage
|
||||
.quad sys_osf_gettimeofday
|
||||
.quad sys_osf_getrusage
|
||||
.quad sys_getsockopt
|
||||
.quad alpha_ni_syscall
|
||||
#ifdef CONFIG_OSF4_COMPAT
|
||||
.quad osf_readv /* 120 */
|
||||
.quad osf_writev
|
||||
.quad sys_osf_readv /* 120 */
|
||||
.quad sys_osf_writev
|
||||
#else
|
||||
.quad sys_readv /* 120 */
|
||||
.quad sys_writev
|
||||
#endif
|
||||
.quad osf_settimeofday
|
||||
.quad sys_osf_settimeofday
|
||||
.quad sys_fchown
|
||||
.quad sys_fchmod
|
||||
.quad sys_recvfrom /* 125 */
|
||||
|
@ -154,7 +154,7 @@ sys_call_table:
|
|||
.quad sys_socketpair /* 135 */
|
||||
.quad sys_mkdir
|
||||
.quad sys_rmdir
|
||||
.quad osf_utimes
|
||||
.quad sys_osf_utimes
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 140 */
|
||||
.quad sys_getpeername
|
||||
|
@ -172,16 +172,16 @@ sys_call_table:
|
|||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 155 */
|
||||
.quad osf_sigaction
|
||||
.quad sys_osf_sigaction
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad osf_getdirentries
|
||||
.quad osf_statfs /* 160 */
|
||||
.quad osf_fstatfs
|
||||
.quad sys_osf_getdirentries
|
||||
.quad sys_osf_statfs /* 160 */
|
||||
.quad sys_osf_fstatfs
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad osf_getdomainname /* 165 */
|
||||
.quad sys_osf_getdomainname /* 165 */
|
||||
.quad sys_setdomainname
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
|
@ -224,7 +224,7 @@ sys_call_table:
|
|||
.quad sys_semctl
|
||||
.quad sys_semget /* 205 */
|
||||
.quad sys_semop
|
||||
.quad osf_utsname
|
||||
.quad sys_osf_utsname
|
||||
.quad sys_lchown
|
||||
.quad sys_shmat
|
||||
.quad sys_shmctl /* 210 */
|
||||
|
@ -258,23 +258,23 @@ sys_call_table:
|
|||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 240 */
|
||||
.quad osf_sysinfo
|
||||
.quad sys_osf_sysinfo
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad osf_proplist_syscall
|
||||
.quad sys_osf_proplist_syscall
|
||||
.quad alpha_ni_syscall /* 245 */
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 250 */
|
||||
.quad osf_usleep_thread
|
||||
.quad sys_osf_usleep_thread
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad sys_sysfs
|
||||
.quad alpha_ni_syscall /* 255 */
|
||||
.quad osf_getsysinfo
|
||||
.quad osf_setsysinfo
|
||||
.quad sys_osf_getsysinfo
|
||||
.quad sys_osf_setsysinfo
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall
|
||||
.quad alpha_ni_syscall /* 260 */
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue