xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'x86/amd-nb' into x86/apic-cleanups

Browse Source 
Reason: apic cleanup series depends on x86/apic, x86/amd-nb x86/platform

Conflicts:
	arch/x86/include/asm/io_apic.h

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This commit is contained in:
Thomas Gleixner
2010-12-09 18:17:25 +01:00
parent a38c5380ef f658bcfb26
commit d834a9dcec
8833 changed files with 918659 additions and 472983 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Documentation/ABI/obsolete/dv1394
View File

@@ -1,9 +0,0 @@
What: dv1394 (a.k.a. "OHCI-DV I/O support" for FireWire)
Contact: linux1394-devel@lists.sourceforge.net
Description:
New application development should use raw1394 + userspace libraries
instead, notably libiec61883 which is functionally equivalent.
Users:
ffmpeg/libavformat (used by a variety of media players)
dvgrab v1.x (replaced by dvgrab2 on top of raw1394 and resp. libraries)

22
Documentation/ABI/obsolete/proc-pid-oom_adj Normal file
View File

@@ -0,0 +1,22 @@
What: /proc/<pid>/oom_adj
When: August 2012
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
badness heuristic used to determine which task to kill when the kernel
is out of memory.
The badness heuristic has since been rewritten since the introduction of
this tunable such that its meaning is deprecated. The value was
implemented as a bitshift on a score generated by the badness()
function that did not have any precise units of measure. With the
rewrite, the score is given as a proportion of available memory to the
task allocating pages, so using a bitshift which grows the score
exponentially is, thus, impossible to tune with fine granularity.
A much more powerful interface, /proc/<pid>/oom_score_adj, was
introduced with the oom killer rewrite that allows users to increase or
decrease the badness() score linearly. This interface will replace
/proc/<pid>/oom_adj.
A warning will be emitted to the kernel log if an application uses this
deprecated interface. After it is printed once, future warnings will be
suppressed until the kernel is rebooted.

14
Documentation/ABI/removed/dv1394 Normal file
View File

@@ -0,0 +1,14 @@
What: dv1394 (a.k.a. "OHCI-DV I/O support" for FireWire)
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
Contact: linux1394-devel@lists.sourceforge.net
Description:
/dev/dv1394/* were character device files, one for each FireWire
controller and for NTSC and PAL respectively, from which DV data
could be received by read() or transmitted by write(). A few
ioctl()s allowed limited control.
This special-purpose interface has been superseded by libraw1394 +
libiec61883 which are functionally equivalent, support HDV, and
transparently work on top of the newer firewire kernel drivers.
Users:
ffmpeg/libavformat (if configured for DV1394)

15
Documentation/ABI/removed/raw1394 Normal file
View File

@@ -0,0 +1,15 @@
What: raw1394 (a.k.a. "Raw IEEE1394 I/O support" for FireWire)
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
Contact: linux1394-devel@lists.sourceforge.net
Description:
/dev/raw1394 was a character device file that allowed low-level
access to FireWire buses. Its major drawbacks were its inability
to implement sensible device security policies, and its low level
of abstraction that required userspace clients do duplicate much
of the kernel's ieee1394 core functionality.
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
firewire-core.
Users:
libraw1394 (works with firewire-cdev too, transparent to library ABI
users)

16
Documentation/ABI/removed/raw1394_legacy_isochronous
View File

@@ -1,16 +0,0 @@
What: legacy isochronous ABI of raw1394 (1st generation iso ABI)
Date: June 2007 (scheduled), removed in kernel v2.6.23
Contact: linux1394-devel@lists.sourceforge.net
Description:
The two request types RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN have
been deprecated for quite some time. They are very inefficient as they
come with high interrupt load and several layers of callbacks for each
packet. Because of these deficiencies, the video1394 and dv1394 drivers
and the 3rd-generation isochronous ABI in raw1394 (rawiso) were created.
Users:
libraw1394 users via the long deprecated API raw1394_iso_write,
raw1394_start_iso_write, raw1394_start_iso_rcv, raw1394_stop_iso_rcv
libdc1394, which optionally uses these old libraw1394 calls
alternatively to the more efficient video1394 ABI

16
Documentation/ABI/removed/video1394 Normal file
View File

@@ -0,0 +1,16 @@
What: video1394 (a.k.a. "OHCI-1394 Video support" for FireWire)
Date: May 2010 (scheduled), finally removed in kernel v2.6.37
Contact: linux1394-devel@lists.sourceforge.net
Description:
/dev/video1394/* were character device files, one for each FireWire
controller, which were used for isochronous I/O. It was added as an
alternative to raw1394's isochronous I/O functionality which had
performance issues in its first generation. Any video1394 user had
to use raw1394 + libraw1394 too because video1394 did not provide
asynchronous I/O for device discovery and configuration.
Replaced by /dev/fw*, i.e. the <linux/firewire-cdev.h> ABI of
firewire-core.
Users:
libdc1394 (works with firewire-cdev too, transparent to library ABI
users)

99
Documentation/ABI/testing/sysfs-block-zram Normal file
View File

@@ -0,0 +1,99 @@
What: /sys/block/zram<id>/disksize
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is read-write and specifies the disk size
which represents the limit on the *uncompressed* worth of data
that can be stored in this disk.
What: /sys/block/zram<id>/initstate
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is read-only and shows the initialization
state of the device.
What: /sys/block/zram<id>/reset
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is write-only and allows resetting the
device. The reset operation frees all the memory assocaited
with this device.
What: /sys/block/zram<id>/num_reads
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The num_reads file is read-only and specifies the number of
reads (failed or successful) done on this device.
What: /sys/block/zram<id>/num_writes
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The num_writes file is read-only and specifies the number of
writes (failed or successful) done on this device.
What: /sys/block/zram<id>/invalid_io
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The invalid_io file is read-only and specifies the number of
non-page-size-aligned I/O requests issued to this device.
What: /sys/block/zram<id>/notify_free
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The notify_free file is read-only and specifies the number of
swap slot free notifications received by this device. These
notifications are send to a swap block device when a swap slot
is freed. This statistic is applicable only when this disk is
being used as a swap disk.
What: /sys/block/zram<id>/discard
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The discard file is read-only and specifies the number of
discard requests received by this device. These requests
provide information to block device regarding blocks which are
no longer used by filesystem.
What: /sys/block/zram<id>/zero_pages
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The zero_pages file is read-only and specifies number of zero
filled pages written to this disk. No memory is allocated for
such pages.
What: /sys/block/zram<id>/orig_data_size
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The orig_data_size file is read-only and specifies uncompressed
size of data stored in this disk. This excludes zero-filled
pages (zero_pages) since no memory is allocated for them.
Unit: bytes
What: /sys/block/zram<id>/compr_data_size
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The compr_data_size file is read-only and specifies compressed
size of data stored in this disk. So, compression ratio can be
calculated using orig_data_size and this statistic.
Unit: bytes
What: /sys/block/zram<id>/mem_used_total
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The mem_used_total file is read-only and specifies the amount
of memory, including allocator fragmentation and metadata
overhead, allocated for this disk. So, allocator space
efficiency can be calculated using compr_data_size and this
statistic.
Unit: bytes

22
Documentation/ABI/testing/sysfs-devices-system-ibm-rtl Normal file
View File

@@ -0,0 +1,22 @@
What: state
Date: Sep 2010
KernelVersion: 2.6.37
Contact: Vernon Mauery <vernux@us.ibm.com>
Description: The state file allows a means by which to change in and
out of Premium Real-Time Mode (PRTM), as well as the
ability to query the current state.
0 => PRTM off
1 => PRTM enabled
Users: The ibm-prtm userspace daemon uses this interface.
What: version
Date: Sep 2010
KernelVersion: 2.6.37
Contact: Vernon Mauery <vernux@us.ibm.com>
Description: The version file provides a means by which to query
the RTL table version that lives in the Extended
BIOS Data Area (EBDA).
Users: The ibm-prtm userspace daemon uses this interface.

98
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra Normal file
View File

@@ -0,0 +1,98 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_cpi
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: It is possible to switch the cpi setting of the mouse with the
press of a button.
When read, this file returns the raw number of the actual cpi
setting reported by the mouse. This number has to be further
processed to receive the real dpi value.
VALUE DPI
1 400
2 800
4 1600
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 138 means 1.38
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the profile
that's active when the mouse is powered on.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the settings stored in the mouse.
The size of the data is 3 bytes and holds information on the
startup_profile.
When written, this file lets write settings back to the mouse.
The data has to be 3 bytes long. The mouse will reject invalid
data.

12
Documentation/ABI/testing/sysfs-module Normal file
View File

@@ -0,0 +1,12 @@
What: /sys/module/pch_phub/drivers/.../pch_mac
Date: August 2010
KernelVersion: 2.6.35
Contact: masa-korg@dsn.okisemi.com
Description: Write/read GbE MAC address.
What: /sys/module/pch_phub/drivers/.../pch_firmware
Date: August 2010
KernelVersion: 2.6.35
Contact: masa-korg@dsn.okisemi.com
Description: Write/read Option ROM data.

495
Documentation/DocBook/80211.tmpl Normal file
View File

@@ -0,0 +1,495 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<set>
<setinfo>
<title>The 802.11 subsystems &ndash; for kernel developers</title>
<subtitle>
Explaining wireless 802.11 networking in the Linux kernel
</subtitle>
<copyright>
<year>2007-2009</year>
<holder>Johannes Berg</holder>
</copyright>
<authorgroup>
<author>
<firstname>Johannes</firstname>
<surname>Berg</surname>
<affiliation>
<address><email>johannes@sipsolutions.net</email></address>
</affiliation>
</author>
</authorgroup>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This documentation 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 documentation; 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>
<abstract>
<para>
These books attempt to give a description of the
various subsystems that play a role in 802.11 wireless
networking in Linux. Since these books are for kernel
developers they attempts to document the structures
and functions used in the kernel as well as giving a
higher-level overview.
</para>
<para>
The reader is expected to be familiar with the 802.11
standard as published by the IEEE in 802.11-2007 (or
possibly later versions). References to this standard
will be given as "802.11-2007 8.1.5".
</para>
</abstract>
</setinfo>
<book id="cfg80211-developers-guide">
<bookinfo>
<title>The cfg80211 subsystem</title>
<abstract>
!Pinclude/net/cfg80211.h Introduction
</abstract>
</bookinfo>
<chapter>
<title>Device registration</title>
!Pinclude/net/cfg80211.h Device registration
!Finclude/net/cfg80211.h ieee80211_band
!Finclude/net/cfg80211.h ieee80211_channel_flags
!Finclude/net/cfg80211.h ieee80211_channel
!Finclude/net/cfg80211.h ieee80211_rate_flags
!Finclude/net/cfg80211.h ieee80211_rate
!Finclude/net/cfg80211.h ieee80211_sta_ht_cap
!Finclude/net/cfg80211.h ieee80211_supported_band
!Finclude/net/cfg80211.h cfg80211_signal_type
!Finclude/net/cfg80211.h wiphy_params_flags
!Finclude/net/cfg80211.h wiphy_flags
!Finclude/net/cfg80211.h wiphy
!Finclude/net/cfg80211.h wireless_dev
!Finclude/net/cfg80211.h wiphy_new
!Finclude/net/cfg80211.h wiphy_register
!Finclude/net/cfg80211.h wiphy_unregister
!Finclude/net/cfg80211.h wiphy_free
!Finclude/net/cfg80211.h wiphy_name
!Finclude/net/cfg80211.h wiphy_dev
!Finclude/net/cfg80211.h wiphy_priv
!Finclude/net/cfg80211.h priv_to_wiphy
!Finclude/net/cfg80211.h set_wiphy_dev
!Finclude/net/cfg80211.h wdev_priv
</chapter>
<chapter>
<title>Actions and configuration</title>
!Pinclude/net/cfg80211.h Actions and configuration
!Finclude/net/cfg80211.h cfg80211_ops
!Finclude/net/cfg80211.h vif_params
!Finclude/net/cfg80211.h key_params
!Finclude/net/cfg80211.h survey_info_flags
!Finclude/net/cfg80211.h survey_info
!Finclude/net/cfg80211.h beacon_parameters
!Finclude/net/cfg80211.h plink_actions
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags
!Finclude/net/cfg80211.h rate_info
!Finclude/net/cfg80211.h station_info
!Finclude/net/cfg80211.h monitor_flags
!Finclude/net/cfg80211.h mpath_info_flags
!Finclude/net/cfg80211.h mpath_info
!Finclude/net/cfg80211.h bss_parameters
!Finclude/net/cfg80211.h ieee80211_txq_params
!Finclude/net/cfg80211.h cfg80211_crypto_settings
!Finclude/net/cfg80211.h cfg80211_auth_request
!Finclude/net/cfg80211.h cfg80211_assoc_request
!Finclude/net/cfg80211.h cfg80211_deauth_request
!Finclude/net/cfg80211.h cfg80211_disassoc_request
!Finclude/net/cfg80211.h cfg80211_ibss_params
!Finclude/net/cfg80211.h cfg80211_connect_params
!Finclude/net/cfg80211.h cfg80211_pmksa
!Finclude/net/cfg80211.h cfg80211_send_rx_auth
!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
!Finclude/net/cfg80211.h __cfg80211_auth_canceled
!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
!Finclude/net/cfg80211.h cfg80211_send_deauth
!Finclude/net/cfg80211.h __cfg80211_send_deauth
!Finclude/net/cfg80211.h cfg80211_send_disassoc
!Finclude/net/cfg80211.h __cfg80211_send_disassoc
!Finclude/net/cfg80211.h cfg80211_ibss_joined
!Finclude/net/cfg80211.h cfg80211_connect_result
!Finclude/net/cfg80211.h cfg80211_roamed
!Finclude/net/cfg80211.h cfg80211_disconnected
!Finclude/net/cfg80211.h cfg80211_ready_on_channel
!Finclude/net/cfg80211.h cfg80211_remain_on_channel_expired
!Finclude/net/cfg80211.h cfg80211_new_sta
!Finclude/net/cfg80211.h cfg80211_rx_mgmt
!Finclude/net/cfg80211.h cfg80211_mgmt_tx_status
!Finclude/net/cfg80211.h cfg80211_cqm_rssi_notify
!Finclude/net/cfg80211.h cfg80211_michael_mic_failure
</chapter>
<chapter>
<title>Scanning and BSS list handling</title>
!Pinclude/net/cfg80211.h Scanning and BSS list handling
!Finclude/net/cfg80211.h cfg80211_ssid
!Finclude/net/cfg80211.h cfg80211_scan_request
!Finclude/net/cfg80211.h cfg80211_scan_done
!Finclude/net/cfg80211.h cfg80211_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss
!Finclude/net/cfg80211.h cfg80211_unlink_bss
!Finclude/net/cfg80211.h cfg80211_find_ie
!Finclude/net/cfg80211.h ieee80211_bss_get_ie
</chapter>
<chapter>
<title>Utility functions</title>
!Pinclude/net/cfg80211.h Utility functions
!Finclude/net/cfg80211.h ieee80211_channel_to_frequency
!Finclude/net/cfg80211.h ieee80211_frequency_to_channel
!Finclude/net/cfg80211.h ieee80211_get_channel
!Finclude/net/cfg80211.h ieee80211_get_response_rate
!Finclude/net/cfg80211.h ieee80211_hdrlen
!Finclude/net/cfg80211.h ieee80211_get_hdrlen_from_skb
!Finclude/net/cfg80211.h ieee80211_radiotap_iterator
</chapter>
<chapter>
<title>Data path helpers</title>
!Pinclude/net/cfg80211.h Data path helpers
!Finclude/net/cfg80211.h ieee80211_data_to_8023
!Finclude/net/cfg80211.h ieee80211_data_from_8023
!Finclude/net/cfg80211.h ieee80211_amsdu_to_8023s
!Finclude/net/cfg80211.h cfg80211_classify8021d
</chapter>
<chapter>
<title>Regulatory enforcement infrastructure</title>
!Pinclude/net/cfg80211.h Regulatory enforcement infrastructure
!Finclude/net/cfg80211.h regulatory_hint
!Finclude/net/cfg80211.h wiphy_apply_custom_regulatory
!Finclude/net/cfg80211.h freq_reg_info
</chapter>
<chapter>
<title>RFkill integration</title>
!Pinclude/net/cfg80211.h RFkill integration
!Finclude/net/cfg80211.h wiphy_rfkill_set_hw_state
!Finclude/net/cfg80211.h wiphy_rfkill_start_polling
!Finclude/net/cfg80211.h wiphy_rfkill_stop_polling
</chapter>
<chapter>
<title>Test mode</title>
!Pinclude/net/cfg80211.h Test mode
!Finclude/net/cfg80211.h cfg80211_testmode_alloc_reply_skb
!Finclude/net/cfg80211.h cfg80211_testmode_reply
!Finclude/net/cfg80211.h cfg80211_testmode_alloc_event_skb
!Finclude/net/cfg80211.h cfg80211_testmode_event
</chapter>
</book>
<book id="mac80211-developers-guide">
<bookinfo>
<title>The mac80211 subsystem</title>
<abstract>
!Pinclude/net/mac80211.h Introduction
!Pinclude/net/mac80211.h Warning
</abstract>
</bookinfo>
<toc></toc>
<!--
Generally, this document shall be ordered by increasing complexity.
It is important to note that readers should be able to read only
the first few sections to get a working driver and only advanced
usage should require reading the full document.
-->
<part>
<title>The basic mac80211 driver interface</title>
<partintro>
<para>
You should read and understand the information contained
within this part of the book while implementing a driver.
In some chapters, advanced usage is noted, that may be
skipped at first.
</para>
<para>
This part of the book only covers station and monitor mode
functionality, additional information required to implement
the other modes is covered in the second part of the book.
</para>
</partintro>
<chapter id="basics">
<title>Basic hardware handling</title>
<para>TBD</para>
<para>
This chapter shall contain information on getting a hw
struct allocated and registered with mac80211.
</para>
<para>
Since it is required to allocate rates/modes before registering
a hw struct, this chapter shall also contain information on setting
up the rate/mode structs.
</para>
<para>
Additionally, some discussion about the callbacks and
the general programming model should be in here, including
the definition of ieee80211_ops which will be referred to
a lot.
</para>
<para>
Finally, a discussion of hardware capabilities should be done
with references to other parts of the book.
</para>
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h ieee80211_hw
!Finclude/net/mac80211.h ieee80211_hw_flags
!Finclude/net/mac80211.h SET_IEEE80211_DEV
!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
<chapter id="phy-handling">
<title>PHY configuration</title>
<para>TBD</para>
<para>
This chapter should describe PHY handling including
start/stop callbacks and the various structures used.
</para>
!Finclude/net/mac80211.h ieee80211_conf
!Finclude/net/mac80211.h ieee80211_conf_flags
</chapter>
<chapter id="iface-handling">
<title>Virtual interfaces</title>
<para>TBD</para>
<para>
This chapter should describe virtual interface basics
that are relevant to the driver (VLANs, MGMT etc are not.)
It should explain the use of the add_iface/remove_iface
callbacks as well as the interface configuration callbacks.
</para>
<para>Things related to AP mode should be discussed there.</para>
<para>
Things related to supporting multiple interfaces should be
in the appropriate chapter, a BIG FAT note should be here about
this though and the recommendation to allow only a single
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_vif
</chapter>
<chapter id="rx-tx">
<title>Receive and transmit processing</title>
<sect1>
<title>what should be here</title>
<para>TBD</para>
<para>
This should describe the receive and transmit
paths in mac80211/the drivers as well as
transmit status handling.
</para>
</sect1>
<sect1>
<title>Frame format</title>
!Pinclude/net/mac80211.h Frame format
</sect1>
<sect1>
<title>Packet alignment</title>
!Pnet/mac80211/rx.c Packet alignment
</sect1>
<sect1>
<title>Calling into mac80211 from interrupts</title>
!Pinclude/net/mac80211.h Calling mac80211 from interrupts
</sect1>
<sect1>
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h ieee80211_tx_info
!Finclude/net/mac80211.h ieee80211_rx
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
!Finclude/net/mac80211.h ieee80211_tx_status
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
!Finclude/net/mac80211.h ieee80211_rts_get
!Finclude/net/mac80211.h ieee80211_rts_duration
!Finclude/net/mac80211.h ieee80211_ctstoself_get
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
!Finclude/net/mac80211.h ieee80211_wake_queue
!Finclude/net/mac80211.h ieee80211_stop_queue
!Finclude/net/mac80211.h ieee80211_wake_queues
!Finclude/net/mac80211.h ieee80211_stop_queues
</sect1>
</chapter>
<chapter id="filters">
<title>Frame filtering</title>
!Pinclude/net/mac80211.h Frame filtering
!Finclude/net/mac80211.h ieee80211_filter_flags
</chapter>
</part>
<part id="advanced">
<title>Advanced driver interface</title>
<partintro>
<para>
Information contained within this part of the book is
of interest only for advanced interaction of mac80211
with drivers to exploit more hardware capabilities and
improve performance.
</para>
</partintro>
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_flags
</chapter>
<chapter id="powersave">
<title>Powersave support</title>
!Pinclude/net/mac80211.h Powersave support
</chapter>
<chapter id="beacon-filter">
<title>Beacon filter support</title>
!Pinclude/net/mac80211.h Beacon filter support
!Finclude/net/mac80211.h ieee80211_beacon_loss
</chapter>
<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_tx_queue_params
</chapter>
<chapter id="AP">
<title>Access point mode support</title>
<para>TBD</para>
<para>Some parts of the if_conf should be discussed here instead</para>
<para>
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
</chapter>
<chapter id="multi-iface">
<title>Supporting multiple virtual interfaces</title>
<para>TBD</para>
<para>
Note: WDS with identical MAC address should almost always be OK
</para>
<para>
Insert notes about having multiple virtual interfaces with
different MAC addresses here, note which configurations are
supported by mac80211, add notes about supporting hw crypto
with it.
</para>
</chapter>
<chapter id="hardware-scan-offload">
<title>Hardware scan offload</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_scan_completed
</chapter>
</part>
<part id="rate-control">
<title>Rate control interface</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes the rate control algorithm
interface and how it relates to mac80211 and drivers.
</para>
</partintro>
<chapter id="dummy">
<title>dummy chapter</title>
<para>TBD</para>
</chapter>
</part>
<part id="internal">
<title>Internals</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes mac80211 internals.
</para>
</partintro>
<chapter id="key-handling">
<title>Key handling</title>
<sect1>
<title>Key handling basics</title>
!Pnet/mac80211/key.c Key handling basics
</sect1>
<sect1>
<title>MORE TBD</title>
<para>TBD</para>
</sect1>
</chapter>
<chapter id="rx-processing">
<title>Receive processing</title>
<para>TBD</para>
</chapter>
<chapter id="tx-processing">
<title>Transmit processing</title>
<para>TBD</para>
</chapter>
<chapter id="sta-info">
<title>Station info handling</title>
<sect1>
<title>Programming information</title>
!Fnet/mac80211/sta_info.h sta_info
!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
</sect1>
<sect1>
<title>STA information lifetime rules</title>
!Pnet/mac80211/sta_info.c STA information lifetime rules
</sect1>
</chapter>
<chapter id="synchronisation">
<title>Synchronisation</title>
<para>TBD</para>
<para>Locking, lots of RCU</para>
</chapter>
</part>
</book>
</set>

2
Documentation/DocBook/Makefile
View File

@@ -12,7 +12,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml debugobjects.xml sh.xml regulator.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml media.xml drm.xml tracepoint.xml media.xml drm.xml

5
Documentation/DocBook/device-drivers.tmpl
View File

@@ -51,7 +51,12 @@
<sect1><title>Delaying, scheduling, and timer routines</title> <sect1><title>Delaying, scheduling, and timer routines</title>
!Iinclude/linux/sched.h !Iinclude/linux/sched.h
!Ekernel/sched.c !Ekernel/sched.c
!Iinclude/linux/completion.h
!Ekernel/timer.c !Ekernel/timer.c
</sect1>
<sect1><title>Wait queues and Wake events</title>
!Iinclude/linux/wait.h
!Ekernel/wait.c
</sect1> </sect1>
<sect1><title>High-resolution timers</title> <sect1><title>High-resolution timers</title>
!Iinclude/linux/ktime.h !Iinclude/linux/ktime.h

1
Documentation/DocBook/drm.tmpl
View File

@@ -136,6 +136,7 @@
#ifdef CONFIG_COMPAT #ifdef CONFIG_COMPAT
.compat_ioctl = i915_compat_ioctl, .compat_ioctl = i915_compat_ioctl,
#endif #endif
.llseek = noop_llseek,
}, },
.pci_driver = { .pci_driver = {
.name = DRIVER_NAME, .name = DRIVER_NAME,

9
Documentation/DocBook/kernel-api.tmpl
View File

@@ -93,6 +93,12 @@ X!Ilib/string.c
!Elib/crc32.c !Elib/crc32.c
!Elib/crc-ccitt.c !Elib/crc-ccitt.c
</sect1> </sect1>
<sect1 id="idr"><title>idr/ida Functions</title>
!Pinclude/linux/idr.h idr sync
!Plib/idr.c IDA description
!Elib/idr.c
</sect1>
</chapter> </chapter>
<chapter id="mm"> <chapter id="mm">
@@ -257,7 +263,8 @@ X!Earch/x86/kernel/mca_32.c
!Iblock/blk-sysfs.c !Iblock/blk-sysfs.c
!Eblock/blk-settings.c !Eblock/blk-settings.c
!Eblock/blk-exec.c !Eblock/blk-exec.c
!Eblock/blk-barrier.c !Eblock/blk-flush.c
!Eblock/blk-lib.c
!Eblock/blk-tag.c !Eblock/blk-tag.c
!Iblock/blk-tag.c !Iblock/blk-tag.c
!Eblock/blk-integrity.c !Eblock/blk-integrity.c

13
Documentation/DocBook/kgdb.tmpl
View File

@@ -710,7 +710,18 @@ Task Addr Pid Parent [*] cpu State Thread Command
<listitem><para>A simple shell</para></listitem> <listitem><para>A simple shell</para></listitem>
<listitem><para>The kdb core command set</para></listitem> <listitem><para>The kdb core command set</para></listitem>
<listitem><para>A registration API to register additional kdb shell commands.</para> <listitem><para>A registration API to register additional kdb shell commands.</para>
<para>A good example of a self-contained kdb module is the "ftdump" command for dumping the ftrace buffer. See: kernel/trace/trace_kdb.c</para></listitem> <itemizedlist>
<listitem><para>A good example of a self-contained kdb module
is the "ftdump" command for dumping the ftrace buffer. See:
kernel/trace/trace_kdb.c</para></listitem>
<listitem><para>For an example of how to dynamically register
a new kdb command you can build the kdb_hello.ko kernel module
from samples/kdb/kdb_hello.c. To build this example you can
set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your kernel
config. Later run "modprobe kdb_hello" and the next time you
enter the kdb shell, you can run the "hello"
command.</para></listitem>
</itemizedlist></listitem>
<listitem><para>The implementation for kdb_printf() which <listitem><para>The implementation for kdb_printf() which
emits messages directly to I/O drivers, bypassing the kernel emits messages directly to I/O drivers, bypassing the kernel
log.</para></listitem> log.</para></listitem>

337
Documentation/DocBook/mac80211.tmpl
View File

@@ -1,337 +0,0 @@
<?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="mac80211-developers-guide">
<bookinfo>
<title>The mac80211 subsystem for kernel developers</title>
<authorgroup>
<author>
<firstname>Johannes</firstname>
<surname>Berg</surname>
<affiliation>
<address><email>johannes@sipsolutions.net</email></address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2007-2009</year>
<holder>Johannes Berg</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This documentation 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 documentation; 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>
<abstract>
!Pinclude/net/mac80211.h Introduction
!Pinclude/net/mac80211.h Warning
</abstract>
</bookinfo>
<toc></toc>
<!--
Generally, this document shall be ordered by increasing complexity.
It is important to note that readers should be able to read only
the first few sections to get a working driver and only advanced
usage should require reading the full document.
-->
<part>
<title>The basic mac80211 driver interface</title>
<partintro>
<para>
You should read and understand the information contained
within this part of the book while implementing a driver.
In some chapters, advanced usage is noted, that may be
skipped at first.
</para>
<para>
This part of the book only covers station and monitor mode
functionality, additional information required to implement
the other modes is covered in the second part of the book.
</para>
</partintro>
<chapter id="basics">
<title>Basic hardware handling</title>
<para>TBD</para>
<para>
This chapter shall contain information on getting a hw
struct allocated and registered with mac80211.
</para>
<para>
Since it is required to allocate rates/modes before registering
a hw struct, this chapter shall also contain information on setting
up the rate/mode structs.
</para>
<para>
Additionally, some discussion about the callbacks and
the general programming model should be in here, including
the definition of ieee80211_ops which will be referred to
a lot.
</para>
<para>
Finally, a discussion of hardware capabilities should be done
with references to other parts of the book.
</para>
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h ieee80211_hw
!Finclude/net/mac80211.h ieee80211_hw_flags
!Finclude/net/mac80211.h SET_IEEE80211_DEV
!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
<chapter id="phy-handling">
<title>PHY configuration</title>
<para>TBD</para>
<para>
This chapter should describe PHY handling including
start/stop callbacks and the various structures used.
</para>
!Finclude/net/mac80211.h ieee80211_conf
!Finclude/net/mac80211.h ieee80211_conf_flags
</chapter>
<chapter id="iface-handling">
<title>Virtual interfaces</title>
<para>TBD</para>
<para>
This chapter should describe virtual interface basics
that are relevant to the driver (VLANs, MGMT etc are not.)
It should explain the use of the add_iface/remove_iface
callbacks as well as the interface configuration callbacks.
</para>
<para>Things related to AP mode should be discussed there.</para>
<para>
Things related to supporting multiple interfaces should be
in the appropriate chapter, a BIG FAT note should be here about
this though and the recommendation to allow only a single
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_vif
</chapter>
<chapter id="rx-tx">
<title>Receive and transmit processing</title>
<sect1>
<title>what should be here</title>
<para>TBD</para>
<para>
This should describe the receive and transmit
paths in mac80211/the drivers as well as
transmit status handling.
</para>
</sect1>
<sect1>
<title>Frame format</title>
!Pinclude/net/mac80211.h Frame format
</sect1>
<sect1>
<title>Packet alignment</title>
!Pnet/mac80211/rx.c Packet alignment
</sect1>
<sect1>
<title>Calling into mac80211 from interrupts</title>
!Pinclude/net/mac80211.h Calling mac80211 from interrupts
</sect1>
<sect1>
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h ieee80211_tx_info
!Finclude/net/mac80211.h ieee80211_rx
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
!Finclude/net/mac80211.h ieee80211_tx_status
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
!Finclude/net/mac80211.h ieee80211_rts_get
!Finclude/net/mac80211.h ieee80211_rts_duration
!Finclude/net/mac80211.h ieee80211_ctstoself_get
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
!Finclude/net/mac80211.h ieee80211_wake_queue
!Finclude/net/mac80211.h ieee80211_stop_queue
!Finclude/net/mac80211.h ieee80211_wake_queues
!Finclude/net/mac80211.h ieee80211_stop_queues
</sect1>
</chapter>
<chapter id="filters">
<title>Frame filtering</title>
!Pinclude/net/mac80211.h Frame filtering
!Finclude/net/mac80211.h ieee80211_filter_flags
</chapter>
</part>
<part id="advanced">
<title>Advanced driver interface</title>
<partintro>
<para>
Information contained within this part of the book is
of interest only for advanced interaction of mac80211
with drivers to exploit more hardware capabilities and
improve performance.
</para>
</partintro>
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_alg
!Finclude/net/mac80211.h ieee80211_key_flags
</chapter>
<chapter id="powersave">
<title>Powersave support</title>
!Pinclude/net/mac80211.h Powersave support
</chapter>
<chapter id="beacon-filter">
<title>Beacon filter support</title>
!Pinclude/net/mac80211.h Beacon filter support
!Finclude/net/mac80211.h ieee80211_beacon_loss
</chapter>
<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_tx_queue_params
</chapter>
<chapter id="AP">
<title>Access point mode support</title>
<para>TBD</para>
<para>Some parts of the if_conf should be discussed here instead</para>
<para>
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
</chapter>
<chapter id="multi-iface">
<title>Supporting multiple virtual interfaces</title>
<para>TBD</para>
<para>
Note: WDS with identical MAC address should almost always be OK
</para>
<para>
Insert notes about having multiple virtual interfaces with
different MAC addresses here, note which configurations are
supported by mac80211, add notes about supporting hw crypto
with it.
</para>
</chapter>
<chapter id="hardware-scan-offload">
<title>Hardware scan offload</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_scan_completed
</chapter>
</part>
<part id="rate-control">
<title>Rate control interface</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes the rate control algorithm
interface and how it relates to mac80211 and drivers.
</para>
</partintro>
<chapter id="dummy">
<title>dummy chapter</title>
<para>TBD</para>
</chapter>
</part>
<part id="internal">
<title>Internals</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes mac80211 internals.
</para>
</partintro>
<chapter id="key-handling">
<title>Key handling</title>
<sect1>
<title>Key handling basics</title>
!Pnet/mac80211/key.c Key handling basics
</sect1>
<sect1>
<title>MORE TBD</title>
<para>TBD</para>
</sect1>
</chapter>
<chapter id="rx-processing">
<title>Receive processing</title>
<para>TBD</para>
</chapter>
<chapter id="tx-processing">
<title>Transmit processing</title>
<para>TBD</para>
</chapter>
<chapter id="sta-info">
<title>Station info handling</title>
<sect1>
<title>Programming information</title>
!Fnet/mac80211/sta_info.h sta_info
!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
</sect1>
<sect1>
<title>STA information lifetime rules</title>
!Pnet/mac80211/sta_info.c STA information lifetime rules
</sect1>
</chapter>
<chapter id="synchronisation">
<title>Synchronisation</title>
<para>TBD</para>
<para>Locking, lots of RCU</para>
</chapter>
</part>
</book>

6
Documentation/DocBook/media-entities.tmpl
View File

@@ -250,6 +250,9 @@
<!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> <!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml"> <!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml"> <!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml"> <!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
@@ -347,6 +350,9 @@
<!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> <!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
<!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> <!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
<!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> <!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
<!ENTITY srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
<!ENTITY srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
<!ENTITY y10 SYSTEM "v4l/pixfmt-y10.xml">
<!ENTITY cropcap SYSTEM "v4l/vidioc-cropcap.xml"> <!ENTITY cropcap SYSTEM "v4l/vidioc-cropcap.xml">
<!ENTITY dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml"> <!ENTITY dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
<!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml"> <!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml">

24
Documentation/DocBook/v4l/compat.xml
View File

@@ -21,11 +21,15 @@ API.</para>
<title>Opening and Closing Devices</title> <title>Opening and Closing Devices</title>
<para>For compatibility reasons the character device file names <para>For compatibility reasons the character device file names
recommended for V4L2 video capture, overlay, radio, teletext and raw recommended for V4L2 video capture, overlay, radio and raw
vbi capture devices did not change from those used by V4L. They are vbi capture devices did not change from those used by V4L. They are
listed in <xref linkend="devices" /> and below in <xref listed in <xref linkend="devices" /> and below in <xref
linkend="v4l-dev" />.</para> linkend="v4l-dev" />.</para>
<para>The teletext devices (minor range 192-223) have been removed in
V4L2 and no longer exist. There is no hardware available anymore for handling
pure teletext. Instead raw or sliced VBI is used.</para>
<para>The V4L <filename>videodev</filename> module automatically <para>The V4L <filename>videodev</filename> module automatically
assigns minor numbers to drivers in load order, depending on the assigns minor numbers to drivers in load order, depending on the
registered device type. We recommend that V4L2 drivers by default registered device type. We recommend that V4L2 drivers by default
@@ -65,13 +69,6 @@ not compatible with V4L or V4L2.</para> </footnote>,
<filename>/dev/radio63</filename></para></entry> <filename>/dev/radio63</filename></para></entry>
<entry>64-127</entry> <entry>64-127</entry>
</row> </row>
<row>
<entry>Teletext decoder</entry>
<entry><para><filename>/dev/vtx</filename>,
<filename>/dev/vtx0</filename> to
<filename>/dev/vtx31</filename></para></entry>
<entry>192-223</entry>
</row>
<row> <row>
<entry>Raw VBI capture</entry> <entry>Raw VBI capture</entry>
<entry><para><filename>/dev/vbi</filename>, <entry><para><filename>/dev/vbi</filename>,
@@ -2345,6 +2342,17 @@ more information.</para>
</listitem> </listitem>
</orderedlist> </orderedlist>
</section> </section>
<section>
<title>V4L2 in Linux 2.6.37</title>
<orderedlist>
<listitem>
<para>Remove the vtx (videotext/teletext) API. This API was no longer
used and no hardware exists to verify the API. Nor were any userspace applications found
that used it. It was originally scheduled for removal in 2.6.35.
</para>
</listitem>
</orderedlist>
</section>
<section id="other"> <section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title> <title>Relation of V4L2 to other Linux multimedia APIs</title>

12
Documentation/DocBook/v4l/controls.xml
View File

@@ -311,11 +311,18 @@ minimum value disables backlight compensation.</entry>
bits 8-15 Green color information, bits 16-23 Blue color bits 8-15 Green color information, bits 16-23 Blue color
information and bits 24-31 must be zero.</entry> information and bits 24-31 must be zero.</entry>
</row> </row>
<row>
<entry><constant>V4L2_CID_ILLUMINATORS_1</constant>
<constant>V4L2_CID_ILLUMINATORS_2</constant></entry>
<entry>boolean</entry>
<entry>Switch on or off the illuminator 1 or 2 of the device
(usually a microscope).</entry>
</row>
<row> <row>
<entry><constant>V4L2_CID_LASTP1</constant></entry> <entry><constant>V4L2_CID_LASTP1</constant></entry>
<entry></entry> <entry></entry>
<entry>End of the predefined control IDs (currently <entry>End of the predefined control IDs (currently
<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry> <constant>V4L2_CID_ILLUMINATORS_2</constant> + 1).</entry>
</row> </row>
<row> <row>
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry> <entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
@@ -357,9 +364,6 @@ enumerate_menu (void)
querymenu.index++) { querymenu.index++) {
if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &amp;querymenu)) { if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &amp;querymenu)) {
printf (" %s\n", querymenu.name); printf (" %s\n", querymenu.name);
} else {
perror ("VIDIOC_QUERYMENU");
exit (EXIT_FAILURE);
} }
} }
} }

68
Documentation/DocBook/v4l/dev-rds.xml
View File

@@ -3,15 +3,16 @@
<para>The Radio Data System transmits supplementary <para>The Radio Data System transmits supplementary
information in binary format, for example the station name or travel information in binary format, for example the station name or travel
information, on an inaudible audio subcarrier of a radio program. This information, on an inaudible audio subcarrier of a radio program. This
interface is aimed at devices capable of receiving and decoding RDS interface is aimed at devices capable of receiving and/or transmitting RDS
information.</para> information.</para>
<para>For more information see the core RDS standard <xref linkend="en50067" /> <para>For more information see the core RDS standard <xref linkend="en50067" />
and the RBDS standard <xref linkend="nrsc4" />.</para> and the RBDS standard <xref linkend="nrsc4" />.</para>
<para>Note that the RBDS standard as is used in the USA is almost identical <para>Note that the RBDS standard as is used in the USA is almost identical
to the RDS standard. Any RDS decoder can also handle RBDS. Only some of the fields to the RDS standard. Any RDS decoder/encoder can also handle RBDS. Only some of the
have slightly different meanings. See the RBDS standard for more information.</para> fields have slightly different meanings. See the RBDS standard for more
information.</para>
<para>The RBDS standard also specifies support for MMBS (Modified Mobile Search). <para>The RBDS standard also specifies support for MMBS (Modified Mobile Search).
This is a proprietary format which seems to be discontinued. The RDS interface does not This is a proprietary format which seems to be discontinued. The RDS interface does not
@@ -21,16 +22,25 @@ be needed, then please contact the linux-media mailing list: &v4l-ml;.</para>
<section> <section>
<title>Querying Capabilities</title> <title>Querying Capabilities</title>
<para>Devices supporting the RDS capturing API <para>Devices supporting the RDS capturing API set
set the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
the <structfield>capabilities</structfield> field of &v4l2-capability; the <structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. returned by the &VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS
Any tuner that supports RDS will set the will set the <constant>V4L2_TUNER_CAP_RDS</constant> flag in
<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield> the <structfield>capability</structfield> field of &v4l2-tuner;. If
field of &v4l2-tuner;. the driver only passes RDS blocks without interpreting the data
Whether an RDS signal is present can be detected by looking at the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be
the <structfield>rxsubchans</structfield> field of &v4l2-tuner;: the set, see <link linkend="reading-rds-data">Reading RDS data</link>.
<constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data was detected.</para> For future use the
flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> has also been
defined. However, a driver for a radio tuner with this capability does
not yet exist, so if you are planning to write such a driver you
should discuss this on the linux-media mailing list: &v4l-ml;.</para>
<para> Whether an RDS signal is present can be detected by looking
at the <structfield>rxsubchans</structfield> field of &v4l2-tuner;:
the <constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data
was detected.</para>
<para>Devices supporting the RDS output API <para>Devices supporting the RDS output API
set the <constant>V4L2_CAP_RDS_OUTPUT</constant> flag in set the <constant>V4L2_CAP_RDS_OUTPUT</constant> flag in
@@ -40,16 +50,31 @@ Any modulator that supports RDS will set the
<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield> <constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
field of &v4l2-modulator;. field of &v4l2-modulator;.
In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant> In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant>
bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.</para> bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.
If the driver only passes RDS blocks without interpreting the data
the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be set. If the
tuner is capable of handling RDS entities like program identification codes and radio
text, the flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> should be set,
see <link linkend="writing-rds-data">Writing RDS data</link> and
<link linkend="fm-tx-controls">FM Transmitter Control Reference</link>.</para>
</section> </section>
<section> <section id="reading-rds-data">
<title>Reading RDS data</title> <title>Reading RDS data</title>
<para>RDS data can be read from the radio device <para>RDS data can be read from the radio device
with the &func-read; function. The data is packed in groups of three bytes, with the &func-read; function. The data is packed in groups of three bytes.</para>
</section>
<section id="writing-rds-data">
<title>Writing RDS data</title>
<para>RDS data can be written to the radio device
with the &func-write; function. The data is packed in groups of three bytes,
as follows:</para> as follows:</para>
</section>
<section>
<table frame="none" pgwide="1" id="v4l2-rds-data"> <table frame="none" pgwide="1" id="v4l2-rds-data">
<title>struct <title>struct
<structname>v4l2_rds_data</structname></title> <structname>v4l2_rds_data</structname></title>
@@ -111,48 +136,57 @@ as follows:</para>
<tbody valign="top"> <tbody valign="top">
<row> <row>
<entry>V4L2_RDS_BLOCK_MSK</entry> <entry>V4L2_RDS_BLOCK_MSK</entry>
<entry> </entry>
<entry>7</entry> <entry>7</entry>
<entry>Mask for bits 0-2 to get the block ID.</entry> <entry>Mask for bits 0-2 to get the block ID.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_A</entry> <entry>V4L2_RDS_BLOCK_A</entry>
<entry> </entry>
<entry>0</entry> <entry>0</entry>
<entry>Block A.</entry> <entry>Block A.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_B</entry> <entry>V4L2_RDS_BLOCK_B</entry>
<entry> </entry>
<entry>1</entry> <entry>1</entry>
<entry>Block B.</entry> <entry>Block B.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_C</entry> <entry>V4L2_RDS_BLOCK_C</entry>
<entry> </entry>
<entry>2</entry> <entry>2</entry>
<entry>Block C.</entry> <entry>Block C.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_D</entry> <entry>V4L2_RDS_BLOCK_D</entry>
<entry> </entry>
<entry>3</entry> <entry>3</entry>
<entry>Block D.</entry> <entry>Block D.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_C_ALT</entry> <entry>V4L2_RDS_BLOCK_C_ALT</entry>
<entry> </entry>
<entry>4</entry> <entry>4</entry>
<entry>Block C'.</entry> <entry>Block C'.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_INVALID</entry> <entry>V4L2_RDS_BLOCK_INVALID</entry>
<entry>read-only</entry>
<entry>7</entry> <entry>7</entry>
<entry>An invalid block.</entry> <entry>An invalid block.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_CORRECTED</entry> <entry>V4L2_RDS_BLOCK_CORRECTED</entry>
<entry>read-only</entry>
<entry>0x40</entry> <entry>0x40</entry>
<entry>A bit error was detected but corrected.</entry> <entry>A bit error was detected but corrected.</entry>
</row> </row>
<row> <row>
<entry>V4L2_RDS_BLOCK_ERROR</entry> <entry>V4L2_RDS_BLOCK_ERROR</entry>
<entry>read-only</entry>
<entry>0x80</entry> <entry>0x80</entry>
<entry>An incorrectable error occurred.</entry> <entry>An uncorrectable error occurred.</entry>
</row> </row>
</tbody> </tbody>
</tgroup> </tgroup>

29
Documentation/DocBook/v4l/dev-teletext.xml
View File

@@ -1,35 +1,32 @@
<title>Teletext Interface</title> <title>Teletext Interface</title>
<para>This interface aims at devices receiving and demodulating <para>This interface was aimed at devices receiving and demodulating
Teletext data [<xref linkend="ets300706" />, <xref linkend="itu653" />], evaluating the Teletext data [<xref linkend="ets300706" />, <xref linkend="itu653" />], evaluating the
Teletext packages and storing formatted pages in cache memory. Such Teletext packages and storing formatted pages in cache memory. Such
devices are usually implemented as microcontrollers with serial devices are usually implemented as microcontrollers with serial
interface (I<superscript>2</superscript>C) and can be found on older interface (I<superscript>2</superscript>C) and could be found on old
TV cards, dedicated Teletext decoding cards and home-brew devices TV cards, dedicated Teletext decoding cards and home-brew devices
connected to the PC parallel port.</para> connected to the PC parallel port.</para>
<para>The Teletext API was designed by Martin Buck. It is defined in <para>The Teletext API was designed by Martin Buck. It was defined in
the kernel header file <filename>linux/videotext.h</filename>, the the kernel header file <filename>linux/videotext.h</filename>, the
specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/"> specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/">
ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of
the German public television Teletext service.) Conventional character the German public television Teletext service.)</para>
device file names are <filename>/dev/vtx</filename> and
<filename>/dev/vttuner</filename>, with device number 83, 0 and 83, 16
respectively. A similar interface exists for the Philips SAA5249
Teletext decoder [specification?] with character device file names
<filename>/dev/tlkN</filename>, device number 102, N.</para>
<para>Eventually the Teletext API was integrated into the V4L API <para>Eventually the Teletext API was integrated into the V4L API
with character device file names <filename>/dev/vtx0</filename> to with character device file names <filename>/dev/vtx0</filename> to
<filename>/dev/vtx31</filename>, device major number 81, minor numbers <filename>/dev/vtx31</filename>, device major number 81, minor numbers
192 to 223. For reference the V4L Teletext API specification is 192 to 223.</para>
reproduced here in full: "Teletext interfaces talk the existing VTX
API." Teletext devices with major number 83 and 102 will be removed in
Linux 2.6.</para>
<para>There are no plans to replace the Teletext API or to integrate <para>However, teletext decoders were quickly replaced by more
it into V4L2. Please write to the linux-media mailing list: &v4l-ml; generic VBI demodulators and those dedicated teletext decoders no longer exist.
when the need arises.</para> For many years the vtx devices were still around, even though nobody used
them. So the decision was made to finally remove support for the Teletext API in
kernel 2.6.37.</para>
<para>Modern devices all use the <link linkend="raw-vbi">raw</link> or
<link linkend="sliced">sliced</link> VBI API.</para>
<!-- <!--
Local Variables: Local Variables:

2
Documentation/DocBook/v4l/pixfmt-packed-rgb.xml
View File

@@ -739,7 +739,7 @@ defined in error. Drivers may interpret them as in <xref
<entry>b<subscript>1</subscript></entry> <entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry> <entry>b<subscript>0</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-BGR666"> <row><!-- id="V4L2-PIX-FMT-BGR666" -->
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
<entry>'BGRH'</entry> <entry>'BGRH'</entry>
<entry></entry> <entry></entry>

90
Documentation/DocBook/v4l/pixfmt-srggb10.xml Normal file
View File

@@ -0,0 +1,90 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_SRGGB10 ('RG10'),
V4L2_PIX_FMT_SGRBG10 ('BA10'),
V4L2_PIX_FMT_SGBRG10 ('GB10'),
V4L2_PIX_FMT_SBGGR10 ('BG10'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SRGGB10"><constant>V4L2_PIX_FMT_SRGGB10</constant></refname>
<refname id="V4L2-PIX-FMT-SGRBG10"><constant>V4L2_PIX_FMT_SGRBG10</constant></refname>
<refname id="V4L2-PIX-FMT-SGBRG10"><constant>V4L2_PIX_FMT_SGBRG10</constant></refname>
<refname id="V4L2-PIX-FMT-SBGGR10"><constant>V4L2_PIX_FMT_SBGGR10</constant></refname>
<refpurpose>10-bit Bayer formats expanded to 16 bits</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats with
10 bits per colour. Each colour component is stored in a 16-bit word, with 6
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
stored in memory in little endian order. They are conventionally described
as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
formats</para>
<example>
<title><constant>V4L2_PIX_FMT_SBGGR10</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte, high 6 bits in high bytes are 0.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>B<subscript>00low</subscript></entry>
<entry>B<subscript>00high</subscript></entry>
<entry>G<subscript>01low</subscript></entry>
<entry>G<subscript>01high</subscript></entry>
<entry>B<subscript>02low</subscript></entry>
<entry>B<subscript>02high</subscript></entry>
<entry>G<subscript>03low</subscript></entry>
<entry>G<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>G<subscript>10low</subscript></entry>
<entry>G<subscript>10high</subscript></entry>
<entry>R<subscript>11low</subscript></entry>
<entry>R<subscript>11high</subscript></entry>
<entry>G<subscript>12low</subscript></entry>
<entry>G<subscript>12high</subscript></entry>
<entry>R<subscript>13low</subscript></entry>
<entry>R<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>B<subscript>20low</subscript></entry>
<entry>B<subscript>20high</subscript></entry>
<entry>G<subscript>21low</subscript></entry>
<entry>G<subscript>21high</subscript></entry>
<entry>B<subscript>22low</subscript></entry>
<entry>B<subscript>22high</subscript></entry>
<entry>G<subscript>23low</subscript></entry>
<entry>G<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>G<subscript>30low</subscript></entry>
<entry>G<subscript>30high</subscript></entry>
<entry>R<subscript>31low</subscript></entry>
<entry>R<subscript>31high</subscript></entry>
<entry>G<subscript>32low</subscript></entry>
<entry>G<subscript>32high</subscript></entry>
<entry>R<subscript>33low</subscript></entry>
<entry>R<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

67
Documentation/DocBook/v4l/pixfmt-srggb8.xml Normal file
View File

@@ -0,0 +1,67 @@
<refentry id="V4L2-PIX-FMT-SRGGB8">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_SRGGB8 ('RGGB')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_SRGGB8</constant></refname>
<refpurpose>Bayer RGB format</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is commonly the native format of digital cameras,
reflecting the arrangement of sensors on the CCD device. Only one red,
green or blue value is given for each pixel. Missing components must
be interpolated from neighbouring pixels. From left to right the first
row consists of a red and green value, the second row of a green and
blue value. This scheme repeats to the right and down for every two
columns and rows.</para>
<example>
<title><constant>V4L2_PIX_FMT_SRGGB8</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>R<subscript>00</subscript></entry>
<entry>G<subscript>01</subscript></entry>
<entry>R<subscript>02</subscript></entry>
<entry>G<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>G<subscript>10</subscript></entry>
<entry>B<subscript>11</subscript></entry>
<entry>G<subscript>12</subscript></entry>
<entry>B<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>R<subscript>20</subscript></entry>
<entry>G<subscript>21</subscript></entry>
<entry>R<subscript>22</subscript></entry>
<entry>G<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>G<subscript>30</subscript></entry>
<entry>B<subscript>31</subscript></entry>
<entry>G<subscript>32</subscript></entry>
<entry>B<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

79
Documentation/DocBook/v4l/pixfmt-y10.xml Normal file
View File

@@ -0,0 +1,79 @@
<refentry id="V4L2-PIX-FMT-Y10">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y10 ('Y10 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y10</constant></refname>
<refpurpose>Grey-scale image</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 10 bits per pixel. Pixels
are stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).</para>
<example>
<title><constant>V4L2_PIX_FMT_Y10</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00low</subscript></entry>
<entry>Y'<subscript>00high</subscript></entry>
<entry>Y'<subscript>01low</subscript></entry>
<entry>Y'<subscript>01high</subscript></entry>
<entry>Y'<subscript>02low</subscript></entry>
<entry>Y'<subscript>02high</subscript></entry>
<entry>Y'<subscript>03low</subscript></entry>
<entry>Y'<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10low</subscript></entry>
<entry>Y'<subscript>10high</subscript></entry>
<entry>Y'<subscript>11low</subscript></entry>
<entry>Y'<subscript>11high</subscript></entry>
<entry>Y'<subscript>12low</subscript></entry>
<entry>Y'<subscript>12high</subscript></entry>
<entry>Y'<subscript>13low</subscript></entry>
<entry>Y'<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20low</subscript></entry>
<entry>Y'<subscript>20high</subscript></entry>
<entry>Y'<subscript>21low</subscript></entry>
<entry>Y'<subscript>21high</subscript></entry>
<entry>Y'<subscript>22low</subscript></entry>
<entry>Y'<subscript>22high</subscript></entry>
<entry>Y'<subscript>23low</subscript></entry>
<entry>Y'<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30low</subscript></entry>
<entry>Y'<subscript>30high</subscript></entry>
<entry>Y'<subscript>31low</subscript></entry>
<entry>Y'<subscript>31high</subscript></entry>
<entry>Y'<subscript>32low</subscript></entry>
<entry>Y'<subscript>32high</subscript></entry>
<entry>Y'<subscript>33low</subscript></entry>
<entry>Y'<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

32
Documentation/DocBook/v4l/pixfmt.xml
View File

@@ -566,7 +566,9 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
&sub-sbggr8; &sub-sbggr8;
&sub-sgbrg8; &sub-sgbrg8;
&sub-sgrbg8; &sub-sgrbg8;
&sub-srggb8;
&sub-sbggr16; &sub-sbggr16;
&sub-srggb10;
</section> </section>
<section id="yuv-formats"> <section id="yuv-formats">
@@ -589,6 +591,7 @@ information.</para>
&sub-packed-yuv; &sub-packed-yuv;
&sub-grey; &sub-grey;
&sub-y10;
&sub-y16; &sub-y16;
&sub-yuyv; &sub-yuyv;
&sub-uyvy; &sub-uyvy;
@@ -685,6 +688,11 @@ http://www.ivtvdriver.org/</ulink></para><para>The format is documented in the
kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename> kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename>
</para></entry> </para></entry>
</row> </row>
<row id="V4L2-PIX-FMT-CPIA1">
<entry><constant>V4L2_PIX_FMT_CPIA1</constant></entry>
<entry>'CPIA'</entry>
<entry>YUV format used by the gspca cpia1 driver.</entry>
</row>
<row id="V4L2-PIX-FMT-SPCA501"> <row id="V4L2-PIX-FMT-SPCA501">
<entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry> <entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry>
<entry>'S501'</entry> <entry>'S501'</entry>
@@ -705,11 +713,6 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
<entry>'S561'</entry> <entry>'S561'</entry>
<entry>Compressed GBRG Bayer format used by the gspca driver.</entry> <entry>Compressed GBRG Bayer format used by the gspca driver.</entry>
</row> </row>
<row id="V4L2-PIX-FMT-SGRBG10">
<entry><constant>V4L2_PIX_FMT_SGRBG10</constant></entry>
<entry>'DA10'</entry>
<entry>10 bit raw Bayer, expanded to 16 bits.</entry>
</row>
<row id="V4L2-PIX-FMT-SGRBG10DPCM8"> <row id="V4L2-PIX-FMT-SGRBG10DPCM8">
<entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry> <entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry>
<entry>'DB10'</entry> <entry>'DB10'</entry>
@@ -770,6 +773,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
<entry>'S920'</entry> <entry>'S920'</entry>
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry> <entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
</row> </row>
<row id="V4L2-PIX-FMT-SN9C2028">
<entry><constant>V4L2_PIX_FMT_SN9C2028</constant></entry>
<entry>'SONX'</entry>
<entry>Compressed GBRG bayer format of the gspca sn9c2028 driver.</entry>
</row>
<row id="V4L2-PIX-FMT-STV0680"> <row id="V4L2-PIX-FMT-STV0680">
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry> <entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
<entry>'S680'</entry> <entry>'S680'</entry>
@@ -787,6 +795,20 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
<entry>'TM60'</entry> <entry>'TM60'</entry>
<entry><para>Used by Trident tm6000</para></entry> <entry><para>Used by Trident tm6000</para></entry>
</row> </row>
<row id="V4L2-PIX-FMT-CIT-YYVYUY">
<entry><constant>V4L2_PIX_FMT_CIT_YYVYUY</constant></entry>
<entry>'CITV'</entry>
<entry><para>Used by xirlink CIT, found at IBM webcams.</para>
<para>Uses one line of Y then 1 line of VYUY</para>
</entry>
</row>
<row id="V4L2-PIX-FMT-KONICA420">
<entry><constant>V4L2_PIX_FMT_KONICA420</constant></entry>
<entry>'KONI'</entry>
<entry><para>Used by Konica webcams.</para>
<para>YUV420 planar in blocks of 256 pixels.</para>
</entry>
</row>
<row id="V4L2-PIX-FMT-YYUV"> <row id="V4L2-PIX-FMT-YYUV">
<entry><constant>V4L2_PIX_FMT_YYUV</constant></entry> <entry><constant>V4L2_PIX_FMT_YYUV</constant></entry>
<entry>'YYUV'</entry> <entry>'YYUV'</entry>

10
Documentation/DocBook/v4l/v4l2.xml
View File

@@ -99,6 +99,7 @@ Remote Controller chapter.</contrib>
<year>2007</year> <year>2007</year>
<year>2008</year> <year>2008</year>
<year>2009</year> <year>2009</year>
<year>2010</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder> Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
</copyright> </copyright>
@@ -110,9 +111,16 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
<!-- Put document revisions here, newest first. --> <!-- Put document revisions here, newest first. -->
<!-- API revisions (changes and additions of defines, enums, <!-- API revisions (changes and additions of defines, enums,
structs, ioctls) must be noted in more detail in the history chapter structs, ioctls) must be noted in more detail in the history chapter
(compat.sgml), along with the possible impact on existing drivers and (compat.xml), along with the possible impact on existing drivers and
applications. --> applications. -->
<revision>
<revnumber>2.6.37</revnumber>
<date>2010-08-06</date>
<authorinitials>hv</authorinitials>
<revremark>Removed obsolete vtx (videotext) API.</revremark>
</revision>
<revision> <revision>
<revnumber>2.6.33</revnumber> <revnumber>2.6.33</revnumber>
<date>2009-12-03</date> <date>2009-12-03</date>

106
Documentation/DocBook/v4l/videodev2.h.xml
View File

@@ -154,23 +154,13 @@ enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> {
V4L2_BUF_TYPE_VBI_OUTPUT = 5, V4L2_BUF_TYPE_VBI_OUTPUT = 5,
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6, V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6,
V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7, V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
#if 1 /*KEEP*/ #if 1
/* Experimental */ /* Experimental */
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
#endif #endif
V4L2_BUF_TYPE_PRIVATE = 0x80, V4L2_BUF_TYPE_PRIVATE = 0x80,
}; };
enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> {
V4L2_CTRL_TYPE_INTEGER = 1,
V4L2_CTRL_TYPE_BOOLEAN = 2,
V4L2_CTRL_TYPE_MENU = 3,
V4L2_CTRL_TYPE_BUTTON = 4,
V4L2_CTRL_TYPE_INTEGER64 = 5,
V4L2_CTRL_TYPE_CTRL_CLASS = 6,
V4L2_CTRL_TYPE_STRING = 7,
};
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> { enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> {
V4L2_TUNER_RADIO = 1, V4L2_TUNER_RADIO = 1,
V4L2_TUNER_ANALOG_TV = 2, V4L2_TUNER_ANALOG_TV = 2,
@@ -288,6 +278,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-RGB565">V4L2_PIX_FMT_RGB565</link> v4l2_fourcc('R', 'G', 'B', 'P') /* 16 RGB-5-6-5 */ #define <link linkend="V4L2-PIX-FMT-RGB565">V4L2_PIX_FMT_RGB565</link> v4l2_fourcc('R', 'G', 'B', 'P') /* 16 RGB-5-6-5 */
#define <link linkend="V4L2-PIX-FMT-RGB555X">V4L2_PIX_FMT_RGB555X</link> v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5 BE */ #define <link linkend="V4L2-PIX-FMT-RGB555X">V4L2_PIX_FMT_RGB555X</link> v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5 BE */
#define <link linkend="V4L2-PIX-FMT-RGB565X">V4L2_PIX_FMT_RGB565X</link> v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5 BE */ #define <link linkend="V4L2-PIX-FMT-RGB565X">V4L2_PIX_FMT_RGB565X</link> v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5 BE */
#define <link linkend="V4L2-PIX-FMT-BGR666">V4L2_PIX_FMT_BGR666</link> v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6 */
#define <link linkend="V4L2-PIX-FMT-BGR24">V4L2_PIX_FMT_BGR24</link> v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8 */ #define <link linkend="V4L2-PIX-FMT-BGR24">V4L2_PIX_FMT_BGR24</link> v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8 */
#define <link linkend="V4L2-PIX-FMT-RGB24">V4L2_PIX_FMT_RGB24</link> v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8 */ #define <link linkend="V4L2-PIX-FMT-RGB24">V4L2_PIX_FMT_RGB24</link> v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8 */
#define <link linkend="V4L2-PIX-FMT-BGR32">V4L2_PIX_FMT_BGR32</link> v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */ #define <link linkend="V4L2-PIX-FMT-BGR32">V4L2_PIX_FMT_BGR32</link> v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */
@@ -295,6 +286,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
/* Grey formats */ /* Grey formats */
#define <link linkend="V4L2-PIX-FMT-GREY">V4L2_PIX_FMT_GREY</link> v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */ #define <link linkend="V4L2-PIX-FMT-GREY">V4L2_PIX_FMT_GREY</link> v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */
#define <link linkend="V4L2-PIX-FMT-Y4">V4L2_PIX_FMT_Y4</link> v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */
#define <link linkend="V4L2-PIX-FMT-Y6">V4L2_PIX_FMT_Y6</link> v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale */
#define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link> v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */
#define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */ #define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */
/* Palette formats */ /* Palette formats */
@@ -330,7 +324,11 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */ #define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
#define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */ #define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */
#define <link linkend="V4L2-PIX-FMT-SGRBG8">V4L2_PIX_FMT_SGRBG8</link> v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */ #define <link linkend="V4L2-PIX-FMT-SGRBG8">V4L2_PIX_FMT_SGRBG8</link> v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */
#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw bayer */ #define <link linkend="V4L2-PIX-FMT-SRGGB8">V4L2_PIX_FMT_SRGGB8</link> v4l2_fourcc('R', 'G', 'G', 'B') /* 8 RGRG.. GBGB.. */
#define <link linkend="V4L2-PIX-FMT-SBGGR10">V4L2_PIX_FMT_SBGGR10</link> v4l2_fourcc('B', 'G', '1', '0') /* 10 BGBG.. GRGR.. */
#define <link linkend="V4L2-PIX-FMT-SGBRG10">V4L2_PIX_FMT_SGBRG10</link> v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB.. RGRG.. */
#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR.. BGBG.. */
#define <link linkend="V4L2-PIX-FMT-SRGGB10">V4L2_PIX_FMT_SRGGB10</link> v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG.. GBGB.. */
/* 10bit raw bayer DPCM compressed to 8 bits */ /* 10bit raw bayer DPCM compressed to 8 bits */
#define <link linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8</link> v4l2_fourcc('B', 'D', '1', '0') #define <link linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8</link> v4l2_fourcc('B', 'D', '1', '0')
/* /*
@@ -346,6 +344,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-MPEG">V4L2_PIX_FMT_MPEG</link> v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 */ #define <link linkend="V4L2-PIX-FMT-MPEG">V4L2_PIX_FMT_MPEG</link> v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 */
/* Vendor-specific formats */ /* Vendor-specific formats */
#define <link linkend="V4L2-PIX-FMT-CPIA1">V4L2_PIX_FMT_CPIA1</link> v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
#define <link linkend="V4L2-PIX-FMT-WNVA">V4L2_PIX_FMT_WNVA</link> v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */ #define <link linkend="V4L2-PIX-FMT-WNVA">V4L2_PIX_FMT_WNVA</link> v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */
#define <link linkend="V4L2-PIX-FMT-SN9C10X">V4L2_PIX_FMT_SN9C10X</link> v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */ #define <link linkend="V4L2-PIX-FMT-SN9C10X">V4L2_PIX_FMT_SN9C10X</link> v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */
#define <link linkend="V4L2-PIX-FMT-SN9C20X-I420">V4L2_PIX_FMT_SN9C20X_I420</link> v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */ #define <link linkend="V4L2-PIX-FMT-SN9C20X-I420">V4L2_PIX_FMT_SN9C20X_I420</link> v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */
@@ -358,12 +357,15 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-SPCA561">V4L2_PIX_FMT_SPCA561</link> v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */ #define <link linkend="V4L2-PIX-FMT-SPCA561">V4L2_PIX_FMT_SPCA561</link> v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */
#define <link linkend="V4L2-PIX-FMT-PAC207">V4L2_PIX_FMT_PAC207</link> v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */ #define <link linkend="V4L2-PIX-FMT-PAC207">V4L2_PIX_FMT_PAC207</link> v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */
#define <link linkend="V4L2-PIX-FMT-MR97310A">V4L2_PIX_FMT_MR97310A</link> v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */ #define <link linkend="V4L2-PIX-FMT-MR97310A">V4L2_PIX_FMT_MR97310A</link> v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */
#define <link linkend="V4L2-PIX-FMT-SN9C2028">V4L2_PIX_FMT_SN9C2028</link> v4l2_fourcc('S', 'O', 'N', 'X') /* compressed GBRG bayer */
#define <link linkend="V4L2-PIX-FMT-SQ905C">V4L2_PIX_FMT_SQ905C</link> v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */ #define <link linkend="V4L2-PIX-FMT-SQ905C">V4L2_PIX_FMT_SQ905C</link> v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */
#define <link linkend="V4L2-PIX-FMT-PJPG">V4L2_PIX_FMT_PJPG</link> v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */ #define <link linkend="V4L2-PIX-FMT-PJPG">V4L2_PIX_FMT_PJPG</link> v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */
#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */ #define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */ #define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
#define <link linkend="V4L2-PIX-FMT-CIT-YYVYUY">V4L2_PIX_FMT_CIT_YYVYUY</link> v4l2_fourcc('C', 'I', 'T', 'V') /* one line of Y then 1 line of VYUY */
#define <link linkend="V4L2-PIX-FMT-KONICA420">V4L2_PIX_FMT_KONICA420</link> v4l2_fourcc('K', 'O', 'N', 'I') /* YUV420 planar in blocks of 256 pixels */
/* /*
* F O R M A T E N U M E R A T I O N * F O R M A T E N U M E R A T I O N
@@ -380,7 +382,7 @@ struct <link linkend="v4l2-fmtdesc">v4l2_fmtdesc</link> {
#define V4L2_FMT_FLAG_COMPRESSED 0x0001 #define V4L2_FMT_FLAG_COMPRESSED 0x0001
#define V4L2_FMT_FLAG_EMULATED 0x0002 #define V4L2_FMT_FLAG_EMULATED 0x0002
#if 1 /*KEEP*/ #if 1
/* Experimental Frame Size and frame rate enumeration */ /* Experimental Frame Size and frame rate enumeration */
/* /*
* F R A M E S I Z E E N U M E R A T I O N * F R A M E S I Z E E N U M E R A T I O N
@@ -544,6 +546,8 @@ struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
#define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */ #define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */
#define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */ #define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */
#define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */ #define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */
/* Buffer is ready, but the data contained within is corrupted. */
#define V4L2_BUF_FLAG_ERROR 0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */ #define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */ #define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
@@ -934,6 +938,16 @@ struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link> {
#define V4L2_CTRL_ID2CLASS(id) ((id) &amp; 0x0fff0000UL) #define V4L2_CTRL_ID2CLASS(id) ((id) &amp; 0x0fff0000UL)
#define V4L2_CTRL_DRIVER_PRIV(id) (((id) &amp; 0xffff) &gt;= 0x1000) #define V4L2_CTRL_DRIVER_PRIV(id) (((id) &amp; 0xffff) &gt;= 0x1000)
enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> {
V4L2_CTRL_TYPE_INTEGER = 1,
V4L2_CTRL_TYPE_BOOLEAN = 2,
V4L2_CTRL_TYPE_MENU = 3,
V4L2_CTRL_TYPE_BUTTON = 4,
V4L2_CTRL_TYPE_INTEGER64 = 5,
V4L2_CTRL_TYPE_CTRL_CLASS = 6,
V4L2_CTRL_TYPE_STRING = 7,
};
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */ /* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> { struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> {
__u32 id; __u32 id;
@@ -1018,21 +1032,27 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
V4L2_COLORFX_NONE = 0, V4L2_COLORFX_NONE = 0,
V4L2_COLORFX_BW = 1, V4L2_COLORFX_BW = 1,
V4L2_COLORFX_SEPIA = 2, V4L2_COLORFX_SEPIA = 2,
V4L2_COLORFX_NEGATIVE = 3, V4L2_COLORFX_NEGATIVE = 3,
V4L2_COLORFX_EMBOSS = 4, V4L2_COLORFX_EMBOSS = 4,
V4L2_COLORFX_SKETCH = 5, V4L2_COLORFX_SKETCH = 5,
V4L2_COLORFX_SKY_BLUE = 6, V4L2_COLORFX_SKY_BLUE = 6,
V4L2_COLORFX_GRASS_GREEN = 7, V4L2_COLORFX_GRASS_GREEN = 7,
V4L2_COLORFX_SKIN_WHITEN = 8, V4L2_COLORFX_SKIN_WHITEN = 8,
V4L2_COLORFX_VIVID = 9. V4L2_COLORFX_VIVID = 9,
}; };
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32) #define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33) #define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34) #define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35) #define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
#define V4L2_CID_CHROMA_GAIN (V4L2_CID_BASE+36)
#define V4L2_CID_ILLUMINATORS_1 (V4L2_CID_BASE+37)
#define V4L2_CID_ILLUMINATORS_2 (V4L2_CID_BASE+38)
/* last CID + 1 */ /* last CID + 1 */
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36) #define V4L2_CID_LASTP1 (V4L2_CID_BASE+39)
/* MPEG-class control IDs defined by V4L2 */ /* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900) #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
@@ -1349,6 +1369,8 @@ struct <link linkend="v4l2-modulator">v4l2_modulator</link> {
#define V4L2_TUNER_CAP_SAP 0x0020 #define V4L2_TUNER_CAP_SAP 0x0020
#define V4L2_TUNER_CAP_LANG1 0x0040 #define V4L2_TUNER_CAP_LANG1 0x0040
#define V4L2_TUNER_CAP_RDS 0x0080 #define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
/* Flags for the 'rxsubchans' field */ /* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001 #define V4L2_TUNER_SUB_MONO 0x0001
@@ -1378,7 +1400,8 @@ struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link> {
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type; enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type;
__u32 seek_upward; __u32 seek_upward;
__u32 wrap_around; __u32 wrap_around;
__u32 reserved[8]; __u32 spacing;
__u32 reserved[7];
}; };
/* /*
@@ -1433,7 +1456,7 @@ struct <link linkend="v4l2-audioout">v4l2_audioout</link> {
* *
* NOTE: EXPERIMENTAL API * NOTE: EXPERIMENTAL API
*/ */
#if 1 /*KEEP*/ #if 1
#define V4L2_ENC_IDX_FRAME_I (0) #define V4L2_ENC_IDX_FRAME_I (0)
#define V4L2_ENC_IDX_FRAME_P (1) #define V4L2_ENC_IDX_FRAME_P (1)
#define V4L2_ENC_IDX_FRAME_B (2) #define V4L2_ENC_IDX_FRAME_B (2)
@@ -1625,6 +1648,38 @@ struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> {
} parm; } parm;
}; };
/*
* E V E N T S
*/
#define V4L2_EVENT_ALL 0
#define V4L2_EVENT_VSYNC 1
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_PRIVATE_START 0x08000000
/* Payload for V4L2_EVENT_VSYNC */
struct <link linkend="v4l2-event-vsync">v4l2_event_vsync</link> {
/* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */
__u8 field;
} __attribute__ ((packed));
struct <link linkend="v4l2-event">v4l2_event</link> {
__u32 type;
union {
struct <link linkend="v4l2-event-vsync">v4l2_event_vsync</link> vsync;
__u8 data[64];
} u;
__u32 pending;
__u32 sequence;
struct timespec timestamp;
__u32 reserved[9];
};
struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link> {
__u32 type;
__u32 reserved[7];
};
/* /*
* A D V A N C E D D E B U G G I N G * A D V A N C E D D E B U G G I N G
* *
@@ -1720,7 +1775,7 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
#define VIDIOC_G_EXT_CTRLS _IOWR('V', 71, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>) #define VIDIOC_G_EXT_CTRLS _IOWR('V', 71, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
#define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>) #define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
#define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>) #define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
#if 1 /*KEEP*/ #if 1
#define VIDIOC_ENUM_FRAMESIZES _IOWR('V', 74, struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link>) #define VIDIOC_ENUM_FRAMESIZES _IOWR('V', 74, struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link>)
#define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link>) #define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link>)
#define VIDIOC_G_ENC_INDEX _IOR('V', 76, struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link>) #define VIDIOC_G_ENC_INDEX _IOR('V', 76, struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link>)
@@ -1728,7 +1783,7 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
#define VIDIOC_TRY_ENCODER_CMD _IOWR('V', 78, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>) #define VIDIOC_TRY_ENCODER_CMD _IOWR('V', 78, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>)
#endif #endif
#if 1 /*KEEP*/ #if 1
/* Experimental, meant for debugging, testing and internal use. /* Experimental, meant for debugging, testing and internal use.
Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined. Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
You must be root to use these ioctls. Never use these in applications! */ You must be root to use these ioctls. Never use these in applications! */
@@ -1747,6 +1802,9 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
#define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) #define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
#define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>) #define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
#define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>) #define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
#define VIDIOC_DQEVENT _IOR('V', 89, struct <link linkend="v4l2-event">v4l2_event</link>)
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link>)
#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link>)
/* Reminder: when adding new ioctls please add support for them to /* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */ drivers/media/video/v4l2-compat-ioctl32.c as well! */

3
Documentation/DocBook/v4l/vidioc-g-dv-preset.xml
View File

@@ -16,8 +16,7 @@
<funcdef>int <function>ioctl</function></funcdef> <funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef> <paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef> <paramdef>int <parameter>request</parameter></paramdef>
<paramdef>&v4l2-dv-preset; <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
*<parameter>argp</parameter></paramdef>
</funcprototype> </funcprototype>
</funcsynopsis> </funcsynopsis>
</refsynopsisdiv> </refsynopsisdiv>

3
Documentation/DocBook/v4l/vidioc-g-dv-timings.xml
View File

@@ -16,8 +16,7 @@
<funcdef>int <function>ioctl</function></funcdef> <funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef> <paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef> <paramdef>int <parameter>request</parameter></paramdef>
<paramdef>&v4l2-dv-timings; <paramdef>struct v4l2_dv_timings *<parameter>argp</parameter></paramdef>
*<parameter>argp</parameter></paramdef>
</funcprototype> </funcprototype>
</funcsynopsis> </funcsynopsis>
</refsynopsisdiv> </refsynopsisdiv>

2
Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
View File

@@ -16,7 +16,7 @@ input</refpurpose>
<funcdef>int <function>ioctl</function></funcdef> <funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef> <paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef> <paramdef>int <parameter>request</parameter></paramdef>
<paramdef>&v4l2-dv-preset; *<parameter>argp</parameter></paramdef> <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
</funcprototype> </funcprototype>
</funcsynopsis> </funcsynopsis>
</refsynopsisdiv> </refsynopsisdiv>

7
Documentation/DocBook/v4l/vidioc-querycap.xml
View File

@@ -184,7 +184,7 @@ data.</entry>
<row> <row>
<entry><constant>V4L2_CAP_RDS_CAPTURE</constant></entry> <entry><constant>V4L2_CAP_RDS_CAPTURE</constant></entry>
<entry>0x00000100</entry> <entry>0x00000100</entry>
<entry>The device supports the <link linkend="rds">RDS</link> interface.</entry> <entry>The device supports the <link linkend="rds">RDS</link> capture interface.</entry>
</row> </row>
<row> <row>
<entry><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant></entry> <entry><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant></entry>
@@ -205,6 +205,11 @@ driver capabilities.</para></footnote></entry>
<entry>The device supports the &VIDIOC-S-HW-FREQ-SEEK; ioctl for <entry>The device supports the &VIDIOC-S-HW-FREQ-SEEK; ioctl for
hardware frequency seeking.</entry> hardware frequency seeking.</entry>
</row> </row>
<row>
<entry><constant>V4L2_CAP_RDS_OUTPUT</constant></entry>
<entry>0x00000800</entry>
<entry>The device supports the <link linkend="rds">RDS</link> output interface.</entry>
</row>
<row> <row>
<entry><constant>V4L2_CAP_TUNER</constant></entry> <entry><constant>V4L2_CAP_TUNER</constant></entry>
<entry>0x00010000</entry> <entry>0x00010000</entry>

18
Documentation/DocBook/v4l/vidioc-queryctrl.xml
View File

@@ -103,8 +103,12 @@ structure. The driver fills the rest of the structure or returns an
<structfield>index</structfield> is invalid. Menu items are enumerated <structfield>index</structfield> is invalid. Menu items are enumerated
by calling <constant>VIDIOC_QUERYMENU</constant> with successive by calling <constant>VIDIOC_QUERYMENU</constant> with successive
<structfield>index</structfield> values from &v4l2-queryctrl; <structfield>index</structfield> values from &v4l2-queryctrl;
<structfield>minimum</structfield> (0) to <structfield>minimum</structfield> to
<structfield>maximum</structfield>, inclusive.</para> <structfield>maximum</structfield>, inclusive. Note that it is possible
for <constant>VIDIOC_QUERYMENU</constant> to return an &EINVAL; for some
indices between <structfield>minimum</structfield> and <structfield>maximum</structfield>.
In that case that particular menu item is not supported by this driver. Also note that
the <structfield>minimum</structfield> value is not necessarily 0.</para>
<para>See also the examples in <xref linkend="control" />.</para> <para>See also the examples in <xref linkend="control" />.</para>
@@ -139,7 +143,7 @@ string. This information is intended for the user.</entry>
<entry><structfield>minimum</structfield></entry> <entry><structfield>minimum</structfield></entry>
<entry>Minimum value, inclusive. This field gives a lower <entry>Minimum value, inclusive. This field gives a lower
bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the
lowest valid index (always 0) for <constant>V4L2_CTRL_TYPE_MENU</constant> controls. lowest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> controls.
For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value
gives the minimum length of the string. This length <emphasis>does not include the terminating gives the minimum length of the string. This length <emphasis>does not include the terminating
zero</emphasis>. It may not be valid for any other type of control, including zero</emphasis>. It may not be valid for any other type of control, including
@@ -279,7 +283,7 @@ values which are actually different on the hardware.</entry>
</row> </row>
<row> <row>
<entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry> <entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry>
<entry>0</entry> <entry>&ge; 0</entry>
<entry>1</entry> <entry>1</entry>
<entry>N-1</entry> <entry>N-1</entry>
<entry>The control has a menu of N choices. The names of <entry>The control has a menu of N choices. The names of
@@ -405,8 +409,10 @@ writing a value will cause the device to carry out a given action
<term><errorcode>EINVAL</errorcode></term> <term><errorcode>EINVAL</errorcode></term>
<listitem> <listitem>
<para>The &v4l2-queryctrl; <structfield>id</structfield> <para>The &v4l2-queryctrl; <structfield>id</structfield>
is invalid. The &v4l2-querymenu; <structfield>id</structfield> or is invalid. The &v4l2-querymenu; <structfield>id</structfield> is
<structfield>index</structfield> is invalid.</para> invalid or <structfield>index</structfield> is out of range (less than
<structfield>minimum</structfield> or greater than <structfield>maximum</structfield>)
or this particular menu item is not supported by the driver.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>

10
Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml
View File

@@ -51,7 +51,8 @@
<para>Start a hardware frequency seek from the current frequency. <para>Start a hardware frequency seek from the current frequency.
To do this applications initialize the <structfield>tuner</structfield>, To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield>, <structfield>seek_upward</structfield> and <structfield>type</structfield>, <structfield>seek_upward</structfield>,
<structfield>spacing</structfield> and
<structfield>wrap_around</structfield> fields, and zero out the <structfield>wrap_around</structfield> fields, and zero out the
<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and <structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
@@ -89,7 +90,12 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
</row> </row>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
<entry><structfield>reserved</structfield>[8]</entry> <entry><structfield>spacing</structfield></entry>
<entry>If non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[7]</entry>
<entry>Reserved for future extensions. Drivers and <entry>Reserved for future extensions. Drivers and
applications must set the array to zero.</entry> applications must set the array to zero.</entry>
</row> </row>

38
Documentation/accounting/getdelays.c
View File

@@ -21,6 +21,7 @@
#include <sys/types.h> #include <sys/types.h>
#include <sys/stat.h> #include <sys/stat.h>
#include <sys/socket.h> #include <sys/socket.h>
#include <sys/wait.h>
#include <signal.h> #include <signal.h>
#include <linux/genetlink.h> #include <linux/genetlink.h>
@@ -266,11 +267,13 @@ int main(int argc, char *argv[])
int containerset = 0; int containerset = 0;
char containerpath[1024]; char containerpath[1024];
int cfd = 0; int cfd = 0;
int forking = 0;
sigset_t sigset;
struct msgtemplate msg; struct msgtemplate msg;
while (1) { while (!forking) {
c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:"); c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:");
if (c < 0) if (c < 0)
break; break;
@@ -319,6 +322,28 @@ int main(int argc, char *argv[])
err(1, "Invalid pid\n"); err(1, "Invalid pid\n");
cmd_type = TASKSTATS_CMD_ATTR_PID; cmd_type = TASKSTATS_CMD_ATTR_PID;
break; break;
case 'c':
/* Block SIGCHLD for sigwait() later */
if (sigemptyset(&sigset) == -1)
err(1, "Failed to empty sigset");
if (sigaddset(&sigset, SIGCHLD))
err(1, "Failed to set sigchld in sigset");
sigprocmask(SIG_BLOCK, &sigset, NULL);
/* fork/exec a child */
tid = fork();
if (tid < 0)
err(1, "Fork failed\n");
if (tid == 0)
if (execvp(argv[optind - 1],
&argv[optind - 1]) < 0)
exit(-1);
/* Set the command type and avoid further processing */
cmd_type = TASKSTATS_CMD_ATTR_PID;
forking = 1;
break;
case 'v': case 'v':
printf("debug on\n"); printf("debug on\n");
dbg = 1; dbg = 1;
@@ -370,6 +395,15 @@ int main(int argc, char *argv[])
goto err; goto err;
} }
/*
* If we forked a child, wait for it to exit. Cannot use waitpid()
* as all the delicious data would be reaped as part of the wait
*/
if (tid && forking) {
int sig_received;
sigwait(&sigset, &sig_received);
}
if (tid) { if (tid) {
rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
cmd_type, &tid, sizeof(__u32)); cmd_type, &tid, sizeof(__u32));

7
Documentation/arm/OMAP/DSS
View File

@@ -255,9 +255,10 @@ framebuffer parameters.
Kernel boot arguments Kernel boot arguments
--------------------- ---------------------
vram=<size> vram=<size>[,<physaddr>]
- Amount of total VRAM to preallocate. For example, "10M". omapfb - Amount of total VRAM to preallocate and optionally a physical start
allocates memory for framebuffers from VRAM. memory address. For example, "10M". omapfb allocates memory for
framebuffers from VRAM.
omapfb.mode=<display>:<mode>[,...] omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example, - Default video mode for specified displays. For example,

4
Documentation/arm/SA1100/FreeBird
View File

@@ -1,6 +1,6 @@
Freebird-1.1 is produced by Legned(C) ,Inc. Freebird-1.1 is produced by Legend(C), Inc.
http://web.archive.org/web/*/http://www.legend.com.cn http://web.archive.org/web/*/http://www.legend.com.cn
and software/linux mainatined by Coventive(C),Inc. and software/linux maintained by Coventive(C), Inc.
(http://www.coventive.com) (http://www.coventive.com)
Based on the Nicolas's strongarm kernel tree. Based on the Nicolas's strongarm kernel tree.

4
Documentation/block/00-INDEX
View File

@@ -1,7 +1,5 @@
00-INDEX 00-INDEX
- This file - This file
barrier.txt
- I/O Barriers
biodoc.txt biodoc.txt
- Notes on the Generic Block Layer Rewrite in Linux 2.5 - Notes on the Generic Block Layer Rewrite in Linux 2.5
capability.txt capability.txt
@@ -16,3 +14,5 @@ stat.txt
- Block layer statistics in /sys/block/<dev>/stat - Block layer statistics in /sys/block/<dev>/stat
switching-sched.txt switching-sched.txt
- Switching I/O schedulers at runtime - Switching I/O schedulers at runtime
writeback_cache_control.txt
- Control of volatile write back caches

261
Documentation/block/barrier.txt
View File

@@ -1,261 +0,0 @@
I/O Barriers
============
Tejun Heo <htejun@gmail.com>, July 22 2005
I/O barrier requests are used to guarantee ordering around the barrier
requests. Unless you're crazy enough to use disk drives for
implementing synchronization constructs (wow, sounds interesting...),
the ordering is meaningful only for write requests for things like
journal checkpoints. All requests queued before a barrier request
must be finished (made it to the physical medium) before the barrier
request is started, and all requests queued after the barrier request
must be started only after the barrier request is finished (again,
made it to the physical medium).
In other words, I/O barrier requests have the following two properties.
1. Request ordering
Requests cannot pass the barrier request. Preceding requests are
processed before the barrier and following requests after.
Depending on what features a drive supports, this can be done in one
of the following three ways.
i. For devices which have queue depth greater than 1 (TCQ devices) and
support ordered tags, block layer can just issue the barrier as an
ordered request and the lower level driver, controller and drive
itself are responsible for making sure that the ordering constraint is
met. Most modern SCSI controllers/drives should support this.
NOTE: SCSI ordered tag isn't currently used due to limitation in the
SCSI midlayer, see the following random notes section.
ii. For devices which have queue depth greater than 1 but don't
support ordered tags, block layer ensures that the requests preceding
a barrier request finishes before issuing the barrier request. Also,
it defers requests following the barrier until the barrier request is
finished. Older SCSI controllers/drives and SATA drives fall in this
category.
iii. Devices which have queue depth of 1. This is a degenerate case
of ii. Just keeping issue order suffices. Ancient SCSI
controllers/drives and IDE drives are in this category.
2. Forced flushing to physical medium
Again, if you're not gonna do synchronization with disk drives (dang,
it sounds even more appealing now!), the reason you use I/O barriers
is mainly to protect filesystem integrity when power failure or some
other events abruptly stop the drive from operating and possibly make
the drive lose data in its cache. So, I/O barriers need to guarantee
that requests actually get written to non-volatile medium in order.
There are four cases,
i. No write-back cache. Keeping requests ordered is enough.
ii. Write-back cache but no flush operation. There's no way to
guarantee physical-medium commit order. This kind of devices can't to
I/O barriers.
iii. Write-back cache and flush operation but no FUA (forced unit
access). We need two cache flushes - before and after the barrier
request.
iv. Write-back cache, flush operation and FUA. We still need one
flush to make sure requests preceding a barrier are written to medium,
but post-barrier flush can be avoided by using FUA write on the
barrier itself.
How to support barrier requests in drivers
------------------------------------------
All barrier handling is done inside block layer proper. All low level
drivers have to are implementing its prepare_flush_fn and using one
the following two functions to indicate what barrier type it supports
and how to prepare flush requests. Note that the term 'ordered' is
used to indicate the whole sequence of performing barrier requests
including draining and flushing.
typedef void (prepare_flush_fn)(struct request_queue *q, struct request *rq);
int blk_queue_ordered(struct request_queue *q, unsigned ordered,
prepare_flush_fn *prepare_flush_fn);
@q : the queue in question
@ordered : the ordered mode the driver/device supports
@prepare_flush_fn : this function should prepare @rq such that it
flushes cache to physical medium when executed
For example, SCSI disk driver's prepare_flush_fn looks like the
following.
static void sd_prepare_flush(struct request_queue *q, struct request *rq)
{
memset(rq->cmd, 0, sizeof(rq->cmd));
rq->cmd_type = REQ_TYPE_BLOCK_PC;
rq->timeout = SD_TIMEOUT;
rq->cmd[0] = SYNCHRONIZE_CACHE;
rq->cmd_len = 10;
}
The following seven ordered modes are supported. The following table
shows which mode should be used depending on what features a
device/driver supports. In the leftmost column of table,
QUEUE_ORDERED_ prefix is omitted from the mode names to save space.
The table is followed by description of each mode. Note that in the
descriptions of QUEUE_ORDERED_DRAIN*, '=>' is used whereas '->' is
used for QUEUE_ORDERED_TAG* descriptions. '=>' indicates that the
preceding step must be complete before proceeding to the next step.
'->' indicates that the next step can start as soon as the previous
step is issued.
write-back cache ordered tag flush FUA
-----------------------------------------------------------------------
NONE yes/no N/A no N/A
DRAIN no no N/A N/A
DRAIN_FLUSH yes no yes no
DRAIN_FUA yes no yes yes
TAG no yes N/A N/A
TAG_FLUSH yes yes yes no
TAG_FUA yes yes yes yes
QUEUE_ORDERED_NONE
I/O barriers are not needed and/or supported.
Sequence: N/A
QUEUE_ORDERED_DRAIN
Requests are ordered by draining the request queue and cache
flushing isn't needed.
Sequence: drain => barrier
QUEUE_ORDERED_DRAIN_FLUSH
Requests are ordered by draining the request queue and both
pre-barrier and post-barrier cache flushings are needed.
Sequence: drain => preflush => barrier => postflush
QUEUE_ORDERED_DRAIN_FUA
Requests are ordered by draining the request queue and
pre-barrier cache flushing is needed. By using FUA on barrier
request, post-barrier flushing can be skipped.
Sequence: drain => preflush => barrier
QUEUE_ORDERED_TAG
Requests are ordered by ordered tag and cache flushing isn't
needed.
Sequence: barrier
QUEUE_ORDERED_TAG_FLUSH
Requests are ordered by ordered tag and both pre-barrier and
post-barrier cache flushings are needed.
Sequence: preflush -> barrier -> postflush
QUEUE_ORDERED_TAG_FUA
Requests are ordered by ordered tag and pre-barrier cache
flushing is needed. By using FUA on barrier request,
post-barrier flushing can be skipped.
Sequence: preflush -> barrier
Random notes/caveats
--------------------
* SCSI layer currently can't use TAG ordering even if the drive,
controller and driver support it. The problem is that SCSI midlayer
request dispatch function is not atomic. It releases queue lock and
switch to SCSI host lock during issue and it's possible and likely to
happen in time that requests change their relative positions. Once
this problem is solved, TAG ordering can be enabled.
* Currently, no matter which ordered mode is used, there can be only
one barrier request in progress. All I/O barriers are held off by
block layer until the previous I/O barrier is complete. This doesn't
make any difference for DRAIN ordered devices, but, for TAG ordered
devices with very high command latency, passing multiple I/O barriers
to low level *might* be helpful if they are very frequent. Well, this
certainly is a non-issue. I'm writing this just to make clear that no
two I/O barrier is ever passed to low-level driver.
* Completion order. Requests in ordered sequence are issued in order
but not required to finish in order. Barrier implementation can
handle out-of-order completion of ordered sequence. IOW, the requests
MUST be processed in order but the hardware/software completion paths
are allowed to reorder completion notifications - eg. current SCSI
midlayer doesn't preserve completion order during error handling.
* Requeueing order. Low-level drivers are free to requeue any request
after they removed it from the request queue with
blkdev_dequeue_request(). As barrier sequence should be kept in order
when requeued, generic elevator code takes care of putting requests in
order around barrier. See blk_ordered_req_seq() and
ELEVATOR_INSERT_REQUEUE handling in __elv_add_request() for details.
Note that block drivers must not requeue preceding requests while
completing latter requests in an ordered sequence. Currently, no
error checking is done against this.
* Error handling. Currently, block layer will report error to upper
layer if any of requests in an ordered sequence fails. Unfortunately,
this doesn't seem to be enough. Look at the following request flow.
QUEUE_ORDERED_TAG_FLUSH is in use.
[0] [1] [2] [3] [pre] [barrier] [post] < [4] [5] [6] ... >
still in elevator
Let's say request [2], [3] are write requests to update file system
metadata (journal or whatever) and [barrier] is used to mark that
those updates are valid. Consider the following sequence.
i. Requests [0] ~ [post] leaves the request queue and enters
low-level driver.
ii. After a while, unfortunately, something goes wrong and the
drive fails [2]. Note that any of [0], [1] and [3] could have
completed by this time, but [pre] couldn't have been finished
as the drive must process it in order and it failed before
processing that command.
iii. Error handling kicks in and determines that the error is
unrecoverable and fails [2], and resumes operation.
iv. [pre] [barrier] [post] gets processed.
v. *BOOM* power fails
The problem here is that the barrier request is *supposed* to indicate
that filesystem update requests [2] and [3] made it safely to the
physical medium and, if the machine crashes after the barrier is
written, filesystem recovery code can depend on that. Sadly, that
isn't true in this case anymore. IOW, the success of a I/O barrier
should also be dependent on success of some of the preceding requests,
where only upper layer (filesystem) knows what 'some' is.
This can be solved by implementing a way to tell the block layer which
requests affect the success of the following barrier request and
making lower lever drivers to resume operation on error only after
block layer tells it to do so.
As the probability of this happening is very low and the drive should
be faulty, implementing the fix is probably an overkill. But, still,
it's there.
* In previous drafts of barrier implementation, there was fallback
mechanism such that, if FUA or ordered TAG fails, less fancy ordered
mode can be selected and the failed barrier request is retried
automatically. The rationale for this feature was that as FUA is
pretty new in ATA world and ordered tag was never used widely, there
could be devices which report to support those features but choke when
actually given such requests.
This was removed for two reasons 1. it's an overkill 2. it's
impossible to implement properly when TAG ordering is used as low
level drivers resume after an error automatically. If it's ever
needed adding it back and modifying low level drivers accordingly
shouldn't be difficult.

8
Documentation/block/switching-sched.txt
View File

@@ -16,7 +16,7 @@ you can do so by typing:
As of the Linux 2.6.10 kernel, it is now possible to change the As of the Linux 2.6.10 kernel, it is now possible to change the
IO scheduler for a given block device on the fly (thus making it possible, IO scheduler for a given block device on the fly (thus making it possible,
for instance, to set the CFQ scheduler for the system default, but for instance, to set the CFQ scheduler for the system default, but
set a specific device to use the anticipatory or noop schedulers - which set a specific device to use the deadline or noop schedulers - which
can improve that device's throughput). can improve that device's throughput).
To set a specific scheduler, simply do this: To set a specific scheduler, simply do this:
@@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
will be displayed, with the currently selected scheduler in brackets: will be displayed, with the currently selected scheduler in brackets:
# cat /sys/block/hda/queue/scheduler # cat /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq] noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler # echo deadline > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler # cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq noop [deadline] cfq

86
Documentation/block/writeback_cache_control.txt Normal file
View File

@@ -0,0 +1,86 @@
Explicit volatile write back cache control
=====================================
Introduction
------------
Many storage devices, especially in the consumer market, come with volatile
write back caches. That means the devices signal I/O completion to the
operating system before data actually has hit the non-volatile storage. This
behavior obviously speeds up various workloads, but it means the operating
system needs to force data out to the non-volatile storage when it performs
a data integrity operation like fsync, sync or an unmount.
The Linux block layer provides two simple mechanisms that let filesystems
control the caching behavior of the storage device. These mechanisms are
a forced cache flush, and the Force Unit Access (FUA) flag for requests.
Explicit cache flushes
----------------------
The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from
the filesystem and will make sure the volatile cache of the storage device
has been flushed before the actual I/O operation is started. This explicitly
guarantees that previously completed write requests are on non-volatile
storage before the flagged bio starts. In addition the REQ_FLUSH flag can be
set on an otherwise empty bio structure, which causes only an explicit cache
flush without any dependent I/O. It is recommend to use
the blkdev_issue_flush() helper for a pure cache flush.
Forced Unit Access
-----------------
The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the
filesystem and will make sure that I/O completion for this request is only
signaled after the data has been committed to non-volatile storage.
Implementation details for filesystems
--------------------------------------
Filesystems can simply set the REQ_FLUSH and REQ_FUA bits and do not have to
worry if the underlying devices need any explicit cache flushing and how
the Forced Unit Access is implemented. The REQ_FLUSH and REQ_FUA flags
may both be set on a single bio.
Implementation details for make_request_fn based block drivers
--------------------------------------------------------------
These drivers will always see the REQ_FLUSH and REQ_FUA bits as they sit
directly below the submit_bio interface. For remapping drivers the REQ_FUA
bits need to be propagated to underlying devices, and a global flush needs
to be implemented for bios with the REQ_FLUSH bit set. For real device
drivers that do not have a volatile cache the REQ_FLUSH and REQ_FUA bits
on non-empty bios can simply be ignored, and REQ_FLUSH requests without
data can be completed successfully without doing any work. Drivers for
devices with volatile caches need to implement the support for these
flags themselves without any help from the block layer.
Implementation details for request_fn based block drivers
--------------------------------------------------------------
For devices that do not support volatile write caches there is no driver
support required, the block layer completes empty REQ_FLUSH requests before
entering the driver and strips off the REQ_FLUSH and REQ_FUA bits from
requests that have a payload. For devices with volatile write caches the
driver needs to tell the block layer that it supports flushing caches by
doing:
blk_queue_flush(sdkp->disk->queue, REQ_FLUSH);
and handle empty REQ_FLUSH requests in its prep_fn/request_fn. Note that
REQ_FLUSH requests with a payload are automatically turned into a sequence
of an empty REQ_FLUSH request followed by the actual write by the block
layer. For devices that also support the FUA bit the block layer needs
to be told to pass through the REQ_FUA bit using:
blk_queue_flush(sdkp->disk->queue, REQ_FLUSH | REQ_FUA);
and the driver must handle write requests that have the REQ_FUA bit set
in prep_fn/request_fn. If the FUA bit is not natively supported the block
layer turns it into an empty REQ_FLUSH request after the actual write.

106
Documentation/cgroups/blkio-controller.txt
View File

@@ -8,12 +8,17 @@ both at leaf nodes as well as at intermediate nodes in a storage hierarchy.
Plan is to use the same cgroup based management interface for blkio controller Plan is to use the same cgroup based management interface for blkio controller
and based on user options switch IO policies in the background. and based on user options switch IO policies in the background.
In the first phase, this patchset implements proportional weight time based Currently two IO control policies are implemented. First one is proportional
division of disk policy. It is implemented in CFQ. Hence this policy takes weight time based division of disk policy. It is implemented in CFQ. Hence
effect only on leaf nodes when CFQ is being used. this policy takes effect only on leaf nodes when CFQ is being used. The second
one is throttling policy which can be used to specify upper IO rate limits
on devices. This policy is implemented in generic block layer and can be
used on leaf nodes as well as higher level logical devices like device mapper.
HOWTO HOWTO
===== =====
Proportional Weight division of bandwidth
-----------------------------------------
You can do a very simple testing of running two dd threads in two different You can do a very simple testing of running two dd threads in two different
cgroups. Here is what you can do. cgroups. Here is what you can do.
@@ -55,6 +60,35 @@ cgroups. Here is what you can do.
group dispatched to the disk. We provide fairness in terms of disk time, so group dispatched to the disk. We provide fairness in terms of disk time, so
ideally io.disk_time of cgroups should be in proportion to the weight. ideally io.disk_time of cgroups should be in proportion to the weight.
Throttling/Upper Limit policy
-----------------------------
- Enable Block IO controller
CONFIG_BLK_CGROUP=y
- Enable throttling in block layer
CONFIG_BLK_DEV_THROTTLING=y
- Mount blkio controller
mount -t cgroup -o blkio none /cgroup/blkio
- Specify a bandwidth rate on particular device for root group. The format
for policy is "<major>:<minor> <byes_per_second>".
echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
Above will put a limit of 1MB/second on reads happening for root group
on device having major/minor number 8:16.
- Run dd to read a file and see if rate is throttled to 1MB/s or not.
# dd if=/mnt/common/zerofile of=/dev/null bs=4K count=1024
# iflag=direct
1024+0 records in
1024+0 records out
4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s
Limits for writes can be put using blkio.write_bps_device file.
Various user visible config options Various user visible config options
=================================== ===================================
CONFIG_BLK_CGROUP CONFIG_BLK_CGROUP
@@ -68,8 +102,13 @@ CONFIG_CFQ_GROUP_IOSCHED
- Enables group scheduling in CFQ. Currently only 1 level of group - Enables group scheduling in CFQ. Currently only 1 level of group
creation is allowed. creation is allowed.
CONFIG_BLK_DEV_THROTTLING
- Enable block device throttling support in block layer.
Details of cgroup files Details of cgroup files
======================= =======================
Proportional weight policy files
--------------------------------
- blkio.weight - blkio.weight
- Specifies per cgroup weight. This is default weight of the group - Specifies per cgroup weight. This is default weight of the group
on all the devices until and unless overridden by per device rule. on all the devices until and unless overridden by per device rule.
@@ -210,6 +249,67 @@ Details of cgroup files
and minor number of the device and third field specifies the number and minor number of the device and third field specifies the number
of times a group was dequeued from a particular device. of times a group was dequeued from a particular device.
Throttling/Upper limit policy files
-----------------------------------
- blkio.throttle.read_bps_device
- Specifies upper limit on READ rate from the device. IO rate is
specified in bytes per second. Rules are per deivce. Following is
the format.
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.read_bps_device
- blkio.throttle.write_bps_device
- Specifies upper limit on WRITE rate to the device. IO rate is
specified in bytes per second. Rules are per deivce. Following is
the format.
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.write_bps_device
- blkio.throttle.read_iops_device
- Specifies upper limit on READ rate from the device. IO rate is
specified in IO per second. Rules are per deivce. Following is
the format.
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.read_iops_device
- blkio.throttle.write_iops_device
- Specifies upper limit on WRITE rate to the device. IO rate is
specified in io per second. Rules are per deivce. Following is
the format.
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.write_iops_device
Note: If both BW and IOPS rules are specified for a device, then IO is
subjectd to both the constraints.
- blkio.throttle.io_serviced
- Number of IOs (bio) completed to/from the disk by the group (as
seen by throttling policy). These are further divided by the type
of operation - read or write, sync or async. First two fields specify
the major and minor number of the device, third field specifies the
operation type and the fourth field specifies the number of IOs.
blkio.io_serviced does accounting as seen by CFQ and counts are in
number of requests (struct request). On the other hand,
blkio.throttle.io_serviced counts number of IO in terms of number
of bios as seen by throttling policy. These bios can later be
merged by elevator and total number of requests completed can be
lesser.
- blkio.throttle.io_service_bytes
- Number of bytes transferred to/from the disk by the group. These
are further divided by the type of operation - read or write, sync
or async. First two fields specify the major and minor number of the
device, third field specifies the operation type and the fourth field
specifies the number of bytes.
These numbers should roughly be same as blkio.io_service_bytes as
updated by CFQ. The difference between two is that
blkio.io_service_bytes will not be updated if CFQ is not operating
on request queue.
Common files among various policies
-----------------------------------
- blkio.reset_stats - blkio.reset_stats
- Writing an int to this file will result in resetting all the stats - Writing an int to this file will result in resetting all the stats
for that cgroup. for that cgroup.

14
Documentation/cgroups/cgroups.txt
View File

@@ -18,7 +18,8 @@ CONTENTS:
1.2 Why are cgroups needed ? 1.2 Why are cgroups needed ?
1.3 How are cgroups implemented ? 1.3 How are cgroups implemented ?
1.4 What does notify_on_release do ? 1.4 What does notify_on_release do ?
1.5 How do I use cgroups ? 1.5 What does clone_children do ?
1.6 How do I use cgroups ?
2. Usage Examples and Syntax 2. Usage Examples and Syntax
2.1 Basic Usage 2.1 Basic Usage
2.2 Attaching processes 2.2 Attaching processes
@@ -293,7 +294,16 @@ notify_on_release in the root cgroup at system boot is disabled
value of their parents notify_on_release setting. The default value of value of their parents notify_on_release setting. The default value of
a cgroup hierarchy's release_agent path is empty. a cgroup hierarchy's release_agent path is empty.
1.5 How do I use cgroups ? 1.5 What does clone_children do ?
---------------------------------
If the clone_children flag is enabled (1) in a cgroup, then all
cgroups created beneath will call the post_clone callbacks for each
subsystem of the newly created cgroup. Usually when this callback is
implemented for a subsystem, it copies the values of the parent
subsystem, this is the case for the cpuset.
1.6 How do I use cgroups ?
-------------------------- --------------------------
To start a new job that is to be contained within a cgroup, using To start a new job that is to be contained within a cgroup, using

50
Documentation/coccinelle.txt
View File

@@ -24,6 +24,9 @@ of many distributions, e.g. :
You can get the latest version released from the Coccinelle homepage at You can get the latest version released from the Coccinelle homepage at
http://coccinelle.lip6.fr/ http://coccinelle.lip6.fr/
Information and tips about Coccinelle are also provided on the wiki
pages at http://cocci.ekstranet.diku.dk/wiki/doku.php
Once you have it, run the following command: Once you have it, run the following command:
./configure ./configure
@@ -41,20 +44,22 @@ A Coccinelle-specific target is defined in the top level
Makefile. This target is named 'coccicheck' and calls the 'coccicheck' Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
front-end in the 'scripts' directory. front-end in the 'scripts' directory.
Four modes are defined: report, patch, context, and org. The mode to Four modes are defined: patch, report, context, and org. The mode to
use is specified by setting the MODE variable with 'MODE=<mode>'. use is specified by setting the MODE variable with 'MODE=<mode>'.
'patch' proposes a fix, when possible.
'report' generates a list in the following format: 'report' generates a list in the following format:
file:line:column-column: message file:line:column-column: message
'patch' proposes a fix, when possible.
'context' highlights lines of interest and their context in a 'context' highlights lines of interest and their context in a
diff-like style.Lines of interest are indicated with '-'. diff-like style.Lines of interest are indicated with '-'.
'org' generates a report in the Org mode format of Emacs. 'org' generates a report in the Org mode format of Emacs.
Note that not all semantic patches implement all modes. Note that not all semantic patches implement all modes. For easy use
of Coccinelle, the default mode is "chain" which tries the previous
modes in the order above until one succeeds.
To make a report for every semantic patch, run the following command: To make a report for every semantic patch, run the following command:
@@ -68,9 +73,9 @@ To produce patches, run:
The coccicheck target applies every semantic patch available in the The coccicheck target applies every semantic patch available in the
subdirectories of 'scripts/coccinelle' to the entire Linux kernel. sub-directories of 'scripts/coccinelle' to the entire Linux kernel.
For each semantic patch, a changelog message is proposed. It gives a For each semantic patch, a commit message is proposed. It gives a
description of the problem being checked by the semantic patch, and description of the problem being checked by the semantic patch, and
includes a reference to Coccinelle. includes a reference to Coccinelle.
@@ -93,12 +98,35 @@ or
make coccicheck COCCI=<my_SP.cocci> MODE=report make coccicheck COCCI=<my_SP.cocci> MODE=report
Using Coccinelle on (modified) files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To apply Coccinelle on a file basis, instead of a directory basis, the
following command may be used:
make C=1 CHECK="scripts/coccicheck"
To check only newly edited code, use the value 2 for the C flag, i.e.
make C=2 CHECK="scripts/coccicheck"
This runs every semantic patch in scripts/coccinelle by default. The
COCCI variable may additionally be used to only apply a single
semantic patch as shown in the previous section.
The "chain" mode is the default. You can select another one with the
MODE variable explained above.
In this mode, there is no information about semantic patches
displayed, and no commit message proposed.
Proposing new semantic patches Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New semantic patches can be proposed and submitted by kernel New semantic patches can be proposed and submitted by kernel
developers. For sake of clarity, they should be organized in the developers. For sake of clarity, they should be organized in the
subdirectories of 'scripts/coccinelle/'. sub-directories of 'scripts/coccinelle/'.
Detailed description of the 'report' mode Detailed description of the 'report' mode
@@ -111,7 +139,7 @@ Example:
Running Running
make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci
will execute the following part of the SmPL script. will execute the following part of the SmPL script.
@@ -149,7 +177,7 @@ identified.
Example: Example:
Running Running
make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
will execute the following part of the SmPL script. will execute the following part of the SmPL script.
@@ -193,7 +221,7 @@ NOTE: The diff-like output generated is NOT an applicable patch. The
Example: Example:
Running Running
make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci
will execute the following part of the SmPL script. will execute the following part of the SmPL script.
@@ -228,7 +256,7 @@ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
Example: Example:
Running Running
make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
will execute the following part of the SmPL script. will execute the following part of the SmPL script.

15
Documentation/devices.txt
View File

@@ -239,6 +239,7 @@ Your cooperation is appreciated.
0 = /dev/tty Current TTY device 0 = /dev/tty Current TTY device
1 = /dev/console System console 1 = /dev/console System console
2 = /dev/ptmx PTY master multiplex 2 = /dev/ptmx PTY master multiplex
3 = /dev/ttyprintk User messages via printk TTY device
64 = /dev/cua0 Callout device for ttyS0 64 = /dev/cua0 Callout device for ttyS0
... ...
255 = /dev/cua191 Callout device for ttyS191 255 = /dev/cua191 Callout device for ttyS191
@@ -1495,9 +1496,6 @@ Your cooperation is appreciated.
64 = /dev/radio0 Radio device 64 = /dev/radio0 Radio device
... ...
127 = /dev/radio63 Radio device 127 = /dev/radio63 Radio device
192 = /dev/vtx0 Teletext device
...
223 = /dev/vtx31 Teletext device
224 = /dev/vbi0 Vertical blank interrupt 224 = /dev/vbi0 Vertical blank interrupt
... ...
255 = /dev/vbi31 Vertical blank interrupt 255 = /dev/vbi31 Vertical blank interrupt
@@ -2519,6 +2517,12 @@ Your cooperation is appreciated.
8 = /dev/mmcblk1 Second SD/MMC card 8 = /dev/mmcblk1 Second SD/MMC card
... ...
The start of next SD/MMC card can be configured with
CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
time using the mmcblk.perdev_minors option. That would
bump the offset between each card to be the configured
value instead of the default 8.
179 char CCube DVXChip-based PCI products 179 char CCube DVXChip-based PCI products
0 = /dev/dvxirq0 First DVX device 0 = /dev/dvxirq0 First DVX device
1 = /dev/dvxirq1 Second DVX device 1 = /dev/dvxirq1 Second DVX device
@@ -2553,7 +2557,10 @@ Your cooperation is appreciated.
175 = /dev/usb/legousbtower15 16th USB Legotower device 175 = /dev/usb/legousbtower15 16th USB Legotower device
176 = /dev/usb/usbtmc1 First USB TMC device 176 = /dev/usb/usbtmc1 First USB TMC device
... ...
192 = /dev/usb/usbtmc16 16th USB TMC device 191 = /dev/usb/usbtmc16 16th USB TMC device
192 = /dev/usb/yurex1 First USB Yurex device
...
209 = /dev/usb/yurex16 16th USB Yurex device
240 = /dev/usb/dabusb0 First daubusb device 240 = /dev/usb/dabusb0 First daubusb device
... ...
243 = /dev/usb/dabusb3 Fourth dabusb device 243 = /dev/usb/dabusb3 Fourth dabusb device

46
Documentation/dvb/get_dvb_firmware
View File

@@ -26,7 +26,8 @@ use IO::Handle;
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
"or51211", "or51132_qam", "or51132_vsb", "bluebird", "or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene", "az6027"); "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
"lme2510c_s7395_old");
# Check args # Check args
syntax() if (scalar(@ARGV) != 1); syntax() if (scalar(@ARGV) != 1);
@@ -584,6 +585,49 @@ sub az6027{
$firmware; $firmware;
} }
sub lme2510_lg {
my $sourcefile = "LMEBDA_DVBS.sys";
my $hash = "fc6017ad01e79890a97ec53bea157ed2";
my $outfile = "dvb-usb-lme2510-lg.fw";
my $hasho = "caa065d5fdbd2c09ad57b399bbf55cad";
checkstandard();
verify($sourcefile, $hash);
extract($sourcefile, 4168, 3841, $outfile);
verify($outfile, $hasho);
$outfile;
}
sub lme2510c_s7395 {
my $sourcefile = "US2A0D.sys";
my $hash = "b0155a8083fb822a3bd47bc360e74601";
my $outfile = "dvb-usb-lme2510c-s7395.fw";
my $hasho = "3a3cf1aeebd17b6ddc04cebe131e94cf";
checkstandard();
verify($sourcefile, $hash);
extract($sourcefile, 37248, 3720, $outfile);
verify($outfile, $hasho);
$outfile;
}
sub lme2510c_s7395_old {
my $sourcefile = "LMEBDA_DVBS7395C.sys";
my $hash = "7572ae0eb9cdf91baabd7c0ba9e09b31";
my $outfile = "dvb-usb-lme2510c-s7395.fw";
my $hasho = "90430c5b435eb5c6f88fd44a9d950674";
checkstandard();
verify($sourcefile, $hash);
extract($sourcefile, 4208, 3881, $outfile);
verify($outfile, $hasho);
$outfile;
}
# --------------------------------------------------------------- # ---------------------------------------------------------------
# Utilities # Utilities

58
Documentation/dvb/lmedm04.txt Normal file
View File

@@ -0,0 +1,58 @@
To extract firmware for the DM04/QQBOX you need to copy the
following file(s) to this directory.
for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
-------------------------------------------
The Sharp 7395 driver can be found in windows/system32/driver
US2A0D.sys (dated 17 Mar 2009)
and run
./get_dvb_firmware lme2510c_s7395
will produce
dvb-usb-lme2510c-s7395.fw
An alternative but older firmware can be found on the driver
disk DVB-S_EN_3.5A in BDADriver/driver
LMEBDA_DVBS7395C.sys (dated 18 Jan 2008)
and run
./get_dvb_firmware lme2510c_s7395_old
will produce
dvb-usb-lme2510c-s7395.fw
--------------------------------------------------------------------
The LG firmware can be found on the driver
disk DM04+_5.1A[LG] in BDADriver/driver
for DM04 LME2510 (LG Tuner)
---------------------------
LMEBDA_DVBS.sys (dated 13 Nov 2007)
and run
./get_dvb_firmware lme2510_lg
will produce
dvb-usb-lme2510-lg.fw
Other LG firmware can be extracted manually from US280D.sys
only found in windows/system32/driver.
dd if=US280D.sys ibs=1 skip=42616 count=3668 of=dvb-usb-lme2510-lg.fw
for DM04 LME2510C (LG Tuner)
---------------------------
dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
---------------------------------------------------------------------
Copy the firmware file(s) to /lib/firmware

22
Documentation/dynamic-debug-howto.txt
View File

@@ -24,7 +24,7 @@ Dynamic debug has even more useful features:
read to display the complete list of known debug statements, to help guide you read to display the complete list of known debug statements, to help guide you
Controlling dynamic debug Behaviour Controlling dynamic debug Behaviour
=============================== ===================================
The behaviour of pr_debug()/dev_debug()s are controlled via writing to a 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 control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs
@@ -212,6 +212,26 @@ Note the regexp ^[-+=][scp]+$ matches a flags specification.
Note also that there is no convenient syntax to remove all Note also that there is no convenient syntax to remove all
the flags at once, you need to use "-psc". the flags at once, you need to use "-psc".
Debug messages during boot process
==================================
To be able to activate debug messages during the boot process,
even before userspace and debugfs exists, use the boot parameter:
ddebug_query="QUERY"
QUERY follows the syntax described above, but must not exceed 1023
characters. The enablement of debug messages is done as an arch_initcall.
Thus you can enable debug messages in all code processed after this
arch_initcall via this boot parameter.
On an x86 system for example ACPI enablement is a subsys_initcall and
ddebug_query="file ec.c +p"
will show early Embedded Controller transactions during ACPI setup if
your machine (typically a laptop) has an Embedded Controller.
PCI (or other devices) initialization also is a hot candidate for using
this boot parameter for debugging purposes.
Examples Examples
======== ========

48
Documentation/fb/viafb.txt
View File

@@ -197,6 +197,54 @@ Notes:
example, example,
# fbset -depth 16 # fbset -depth 16
[Configure viafb via /proc]
---------------------------
The following files exist in /proc/viafb
supported_output_devices
This read-only file contains a full ',' seperated list containing all
output devices that could be available on your platform. It is likely
that not all of those have a connector on your hardware but it should
provide a good starting point to figure out which of those names match
a real connector.
Example:
# cat /proc/viafb/supported_output_devices
iga1/output_devices
iga2/output_devices
These two files are readable and writable. iga1 and iga2 are the two
independent units that produce the screen image. Those images can be
forwarded to one or more output devices. Reading those files is a way
to query which output devices are currently used by an iga.
Example:
# cat /proc/viafb/iga1/output_devices
If there are no output devices printed the output of this iga is lost.
This can happen for example if only one (the other) iga is used.
Writing to these files allows adjusting the output devices during
runtime. One can add new devices, remove existing ones or switch
between igas. Essentially you can write a ',' seperated list of device
names (or a single one) in the same format as the output to those
files. You can add a '+' or '-' as a prefix allowing simple addition
and removal of devices. So a prefix '+' adds the devices from your list
to the already existing ones, '-' removes the listed devices from the
existing ones and if no prefix is given it replaces all existing ones
with the listed ones. If you remove devices they are expected to turn
off. If you add devices that are already part of the other iga they are
removed there and added to the new one.
Examples:
Add CRT as output device to iga1
# echo +CRT > /proc/viafb/iga1/output_devices
Remove (turn off) DVP1 and LVDS1 as output devices of iga2
# echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices
Replace all iga1 output devices by CRT
# echo CRT > /proc/viafb/iga1/output_devices
[Bootup with viafb]: [Bootup with viafb]:
-------------------- --------------------
Add the following line to your grub.conf: Add the following line to your grub.conf:

96
Documentation/feature-removal-schedule.txt
View File

@@ -98,7 +98,7 @@ Who: Pavel Machek <pavel@ucw.cz>
--------------------------- ---------------------------
What: Video4Linux API 1 ioctls and from Video devices. What: Video4Linux API 1 ioctls and from Video devices.
When: July 2009 When: kernel 2.6.38
Files: include/linux/videodev.h Files: include/linux/videodev.h
Check: include/linux/videodev.h Check: include/linux/videodev.h
Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
@@ -116,6 +116,21 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
--------------------------- ---------------------------
What: Video4Linux obsolete drivers using V4L1 API
When: kernel 2.6.38
Files: drivers/staging/cpia/* drivers/staging/stradis/*
Check: drivers/staging/cpia/cpia.c drivers/staging/stradis/stradis.c
Why: There are some drivers still using V4L1 API, despite all efforts we've done
to migrate. Those drivers are for obsolete hardware that the old maintainer
didn't care (or not have the hardware anymore), and that no other developer
could find any hardware to buy. They probably have no practical usage today,
and people with such old hardware could probably keep using an older version
of the kernel. Those drivers will be moved to staging on 2.6.37 and, if nobody
care enough to port and test them with V4L2 API, they'll be removed on 2.6.38.
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: sys_sysctl What: sys_sysctl
When: September 2010 When: September 2010
Option: CONFIG_SYSCTL_SYSCALL Option: CONFIG_SYSCTL_SYSCALL
@@ -470,29 +485,6 @@ When: April 2011
Why: Superseded by xt_CT Why: Superseded by xt_CT
Who: Netfilter developer team <netfilter-devel@vger.kernel.org> Who: Netfilter developer team <netfilter-devel@vger.kernel.org>
---------------------------
What: video4linux /dev/vtx teletext API support
When: 2.6.35
Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c
include/linux/videotext.h
Why: The vtx device nodes have been superseded by vbi device nodes
for many years. No applications exist that use the vtx support.
Of the two i2c drivers that actually support this API the saa5249
has been impossible to use for a year now and no known hardware
that supports this device exists. The saa5246a is theoretically
supported by the old mxb boards, but it never actually worked.
In summary: there is no hardware that can use this API and there
are no applications actually implementing this API.
The vtx support still reserves minors 192-223 and we would really
like to reuse those for upcoming new functionality. In the unlikely
event that new hardware appears that wants to use the functionality
provided by the vtx API, then that functionality should be build
around the sliced VBI API instead.
Who: Hans Verkuil <hverkuil@xs4all.nl>
---------------------------- ----------------------------
What: IRQF_DISABLED What: IRQF_DISABLED
@@ -502,16 +494,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
---------------------------- ----------------------------
What: old ieee1394 subsystem (CONFIG_IEEE1394)
When: 2.6.37
Files: drivers/ieee1394/ except init_ohci1394_dma.c
Why: superseded by drivers/firewire/ (CONFIG_FIREWIRE) which offers more
features, better performance, and better security, all with smaller
and more modern code base
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
----------------------------
What: The acpi_sleep=s4_nonvs command line option What: The acpi_sleep=s4_nonvs command line option
When: 2.6.37 When: 2.6.37
Files: arch/x86/kernel/acpi/sleep.c Files: arch/x86/kernel/acpi/sleep.c
@@ -536,3 +518,49 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---------------------------- ----------------------------
What: namespace cgroup (ns_cgroup)
When: 2.6.38
Why: The ns_cgroup leads to some problems:
* cgroup creation is out-of-control
* cgroup name can conflict when pids are looping
* it is not possible to have a single process handling
a lot of namespaces without falling in a exponential creation time
* we may want to create a namespace without creating a cgroup
The ns_cgroup is replaced by a compatibility flag 'clone_children',
where a newly created cgroup will copy the parent cgroup values.
The userspace has to manually create a cgroup and add a task to
the 'tasks' file.
Who: Daniel Lezcano <daniel.lezcano@free.fr>
----------------------------
What: iwlwifi disable_hw_scan module parameters
When: 2.6.40
Why: Hareware scan is the prefer method for iwlwifi devices for
scanning operation. Remove software scan support for all the
iwlwifi devices.
Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
----------------------------
What: access to nfsd auth cache through sys_nfsservctl or '.' files
in the 'nfsd' filesystem.
When: 2.6.40
Why: This is a legacy interface which have been replaced by a more
dynamic cache. Continuing to maintain this interface is an
unnecessary burden.
Who: NeilBrown <neilb@suse.de>
----------------------------
What: i2c_adapter.id
When: June 2011
Why: This field is deprecated. I2C device drivers shouldn't change their
behavior based on the underlying I2C adapter. Instead, the I2C
adapter driver should instantiate the I2C devices and provide the
needed platform-specific information.
Who: Jean Delvare <khali@linux-fr.org>
----------------------------

2
Documentation/filesystems/00-INDEX
View File

@@ -96,8 +96,6 @@ seq_file.txt
- how to use the seq_file API - how to use the seq_file API
sharedsubtree.txt sharedsubtree.txt
- a description of shared subtrees for namespaces. - a description of shared subtrees for namespaces.
smbfs.txt
- info on using filesystems with the SMB protocol (Win 3.11 and NT).
spufs.txt spufs.txt
- info and mount options for the SPU filesystem used on Cell. - info and mount options for the SPU filesystem used on Cell.
sysfs-pci.txt sysfs-pci.txt

4
Documentation/filesystems/9p.txt
View File

@@ -111,7 +111,7 @@ OPTIONS
This can be used to share devices/named pipes/sockets between This can be used to share devices/named pipes/sockets between
hosts. This functionality will be expanded in later versions. hosts. This functionality will be expanded in later versions.
access there are three access modes. access there are four access modes.
user = if a user tries to access a file on v9fs user = if a user tries to access a file on v9fs
filesystem for the first time, v9fs sends an filesystem for the first time, v9fs sends an
attach command (Tattach) for that user. attach command (Tattach) for that user.
@@ -120,6 +120,8 @@ OPTIONS
the files on the mounted filesystem the files on the mounted filesystem
any = v9fs does single attach and performs all any = v9fs does single attach and performs all
operations as one user operations as one user
client = ACL based access check on the 9p client
side for access validation
cachetag cache tag to use the specified persistent cache. cachetag cache tag to use the specified persistent cache.
cache tags for existing cache sessions can be listed at cache tags for existing cache sessions can be listed at

33
Documentation/filesystems/Locking
View File

@@ -322,7 +322,6 @@ fl_release_private: yes yes
prototypes: prototypes:
int (*fl_compare_owner)(struct file_lock *, struct file_lock *); int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
void (*fl_notify)(struct file_lock *); /* unblock callback */ void (*fl_notify)(struct file_lock *); /* unblock callback */
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
void (*fl_release_private)(struct file_lock *); void (*fl_release_private)(struct file_lock *);
void (*fl_break)(struct file_lock *); /* break_lease callback */ void (*fl_break)(struct file_lock *); /* break_lease callback */
@@ -330,7 +329,6 @@ locking rules:
BKL may block BKL may block
fl_compare_owner: yes no fl_compare_owner: yes no
fl_notify: yes no fl_notify: yes no
fl_copy_lock: yes no
fl_release_private: yes yes fl_release_private: yes yes
fl_break: yes no fl_break: yes no
@@ -349,21 +347,36 @@ call this method upon the IO completion.
--------------------------- block_device_operations ----------------------- --------------------------- block_device_operations -----------------------
prototypes: prototypes:
int (*open) (struct inode *, struct file *); int (*open) (struct block_device *, fmode_t);
int (*release) (struct inode *, struct file *); int (*release) (struct gendisk *, fmode_t);
int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long); int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
int (*direct_access) (struct block_device *, sector_t, void **, unsigned long *);
int (*media_changed) (struct gendisk *); int (*media_changed) (struct gendisk *);
void (*unlock_native_capacity) (struct gendisk *);
int (*revalidate_disk) (struct gendisk *); int (*revalidate_disk) (struct gendisk *);
int (*getgeo)(struct block_device *, struct hd_geometry *);
void (*swap_slot_free_notify) (struct block_device *, unsigned long);
locking rules: locking rules:
BKL bd_sem BKL bd_mutex
open: yes yes open: no yes
release: yes yes release: no yes
ioctl: yes no ioctl: no no
compat_ioctl: no no
direct_access: no no
media_changed: no no media_changed: no no
unlock_native_capacity: no no
revalidate_disk: no no revalidate_disk: no no
getgeo: no no
swap_slot_free_notify: no no (see below)
media_changed, unlock_native_capacity and revalidate_disk are called only from
check_disk_change().
swap_slot_free_notify is called with swap_lock and sometimes the page lock
held.
The last two are called only from check_disk_change().
--------------------------- file_operations ------------------------------- --------------------------- file_operations -------------------------------
prototypes: prototypes:

14
Documentation/filesystems/ext4.txt
View File

@@ -353,6 +353,20 @@ noauto_da_alloc replacing existing files via patterns such as
system crashes before the delayed allocation system crashes before the delayed allocation
blocks are forced to disk. blocks are forced to disk.
noinit_itable Do not initialize any uninitialized inode table
blocks in the background. This feature may be
used by installation CD's so that the install
process can complete as quickly as possible; the
inode table initialization process would then be
deferred until the next time the file system
is unmounted.
init_itable=n The lazy itable init code will wait n times the
number of milliseconds it took to zero out the
previous block group's inode table. This
minimizes the impact on the systme performance
while file system's inode table is being initialized.
discard Controls whether ext4 should issue discard/TRIM discard Controls whether ext4 should issue discard/TRIM
nodiscard(*) commands to the underlying block device when nodiscard(*) commands to the underlying block device when
blocks are freed. This is useful for SSD devices blocks are freed. This is useful for SSD devices

4
Documentation/filesystems/nfs/00-INDEX
View File

@@ -12,5 +12,9 @@ nfs-rdma.txt
- how to install and setup the Linux NFS/RDMA client and server software - how to install and setup the Linux NFS/RDMA client and server software
nfsroot.txt nfsroot.txt
- short guide on setting up a diskless box with NFS root filesystem. - short guide on setting up a diskless box with NFS root filesystem.
pnfs.txt
- short explanation of some of the internals of the pnfs client code
rpc-cache.txt rpc-cache.txt
- introduction to the caching mechanisms in the sunrpc layer. - introduction to the caching mechanisms in the sunrpc layer.
idmapper.txt
- information for configuring request-keys to be used by idmapper

67
Documentation/filesystems/nfs/idmapper.txt Normal file
View File

@@ -0,0 +1,67 @@
=========
ID Mapper
=========
Id mapper is used by NFS to translate user and group ids into names, and to
translate user and group names into ids. Part of this translation involves
performing an upcall to userspace to request the information. Id mapper will
user request-key to perform this upcall and cache the result. The program
/usr/sbin/nfs.idmap should be called by request-key, and will perform the
translation and initialize a key with the resulting information.
NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this
feature.
===========
Configuring
===========
The file /etc/request-key.conf will need to be modified so /sbin/request-key can
direct the upcall. The following line should be added:
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== =============== ===============================
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
This will direct all id_resolver requests to the program /usr/sbin/nfs.idmap.
The last parameter, 600, defines how many seconds into the future the key will
expire. This parameter is optional for /usr/sbin/nfs.idmap. When the timeout
is not specified, nfs.idmap will default to 600 seconds.
id mapper uses for key descriptions:
uid: Find the UID for the given user
gid: Find the GID for the given group
user: Find the user name for the given UID
group: Find the group name for the given GID
You can handle any of these individually, rather than using the generic upcall
program. If you would like to use your own program for a uid lookup then you
would edit your request-key.conf so it look similar to this:
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== =============== ===============================
create id_resolver uid:* * /some/other/program %k %d 600
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
Notice that the new line was added above the line for the generic program.
request-key will find the first matching line and corresponding program. In
this case, /some/other/program will handle all uid lookups and
/usr/sbin/nfs.idmap will handle gid, user, and group lookups.
See <file:Documentation/keys-request-keys.txt> for more information about the
request-key function.
=========
nfs.idmap
=========
nfs.idmap is designed to be called by request-key, and should not be run "by
hand". This program takes two arguments, a serialized key and a key
description. The serialized key is first converted into a key_serial_t, and
then passed as an argument to keyctl_instantiate (both are part of keyutils.h).
The actual lookups are performed by functions found in nfsidmap.h. nfs.idmap
determines the correct function to call by looking at the first part of the
description string. For example, a uid lookup description will appear as
"uid:user@domain".
nfs.idmap will return 0 if the key was instantiated, and non-zero otherwise.

22
Documentation/filesystems/nfs/nfsroot.txt
View File

@@ -159,6 +159,28 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Default: any Default: any
nfsrootdebug
This parameter enables debugging messages to appear in the kernel
log at boot time so that administrators can verify that the correct
NFS mount options, server address, and root path are passed to the
NFS client.
rdinit=<executable file>
To specify which file contains the program that starts system
initialization, administrators can use this command line parameter.
The default value of this parameter is "/init". If the specified
file exists and the kernel can execute it, root filesystem related
kernel command line parameters, including `nfsroot=', are ignored.
A description of the process of mounting the root file system can be
found in:
Documentation/early-userspace/README
3.) Boot Loader 3.) Boot Loader

48
Documentation/filesystems/nfs/pnfs.txt Normal file
View File

@@ -0,0 +1,48 @@
Reference counting in pnfs:
==========================
The are several inter-related caches. We have layouts which can
reference multiple devices, each of which can reference multiple data servers.
Each data server can be referenced by multiple devices. Each device
can be referenced by multiple layouts. To keep all of this straight,
we need to reference count.
struct pnfs_layout_hdr
----------------------
The on-the-wire command LAYOUTGET corresponds to struct
pnfs_layout_segment, usually referred to by the variable name lseg.
Each nfs_inode may hold a pointer to a cache of of these layout
segments in nfsi->layout, of type struct pnfs_layout_hdr.
We reference the header for the inode pointing to it, across each
outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN,
LAYOUTCOMMIT), and for each lseg held within.
Each header is also (when non-empty) put on a list associated with
struct nfs_client (cl_layouts). Being put on this list does not bump
the reference count, as the layout is kept around by the lseg that
keeps it in the list.
deviceid_cache
--------------
lsegs reference device ids, which are resolved per nfs_client and
layout driver type. The device ids are held in a RCU cache (struct
nfs4_deviceid_cache). The cache itself is referenced across each
mount. The entries (struct nfs4_deviceid) themselves are held across
the lifetime of each lseg referencing them.
RCU is used because the deviceid is basically a write once, read many
data structure. The hlist size of 32 buckets needs better
justification, but seems reasonable given that we can have multiple
deviceid's per filesystem, and multiple filesystems per nfs_client.
The hash code is copied from the nfsd code base. A discussion of
hashing and variations of this algorithm can be found at:
http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809
data server cache
-----------------
file driver devices refer to data servers, which are kept in a module
level cache. Its reference is held over the lifetime of the deviceid
pointing to it.

25
Documentation/filesystems/proc.txt
View File

@@ -136,6 +136,7 @@ Table 1-1: Process specific entries in /proc
statm Process memory status information statm Process memory status information
status Process status in human readable form status Process status in human readable form
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
pagemap Page table
stack Report full stack trace, enable via CONFIG_STACKTRACE stack Report full stack trace, enable via CONFIG_STACKTRACE
smaps a extension based on maps, showing the memory consumption of smaps a extension based on maps, showing the memory consumption of
each mapping each mapping
@@ -370,17 +371,24 @@ Shared_Dirty: 0 kB
Private_Clean: 0 kB Private_Clean: 0 kB
Private_Dirty: 0 kB Private_Dirty: 0 kB
Referenced: 892 kB Referenced: 892 kB
Anonymous: 0 kB
Swap: 0 kB Swap: 0 kB
KernelPageSize: 4 kB KernelPageSize: 4 kB
MMUPageSize: 4 kB MMUPageSize: 4 kB
The first of these lines shows the same information as is displayed for the The first of these lines shows the same information as is displayed for the
mapping in /proc/PID/maps. The remaining lines show the size of the mapping, mapping in /proc/PID/maps. The remaining lines show the size of the mapping
the amount of the mapping that is currently resident in RAM, the "proportional (size), the amount of the mapping that is currently resident in RAM (RSS), the
set size” (divide each shared page by the number of processes sharing it), the process' proportional share of this mapping (PSS), the number of clean and
number of clean and dirty shared pages in the mapping, and the number of clean dirty private pages in the mapping. Note that even a page which is part of a
and dirty private pages in the mapping. The "Referenced" indicates the amount MAP_SHARED mapping, but has only a single pte mapped, i.e. is currently used
of memory currently marked as referenced or accessed. by only one process, is accounted as private and not as shared. "Referenced"
indicates the amount of memory currently marked as referenced or accessed.
"Anonymous" shows the amount of memory that does not belong to any file. Even
a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
and a page is modified, the file page is replaced by a private anonymous copy.
"Swap" shows how much would-be-anonymous memory is also used, but out on
swap.
This file is only present if the CONFIG_MMU kernel configuration option is This file is only present if the CONFIG_MMU kernel configuration option is
enabled. enabled.
@@ -397,6 +405,9 @@ To clear the bits for the file mapped pages associated with the process
> echo 3 > /proc/PID/clear_refs > echo 3 > /proc/PID/clear_refs
Any other value written to /proc/PID/clear_refs will have no effect. Any other value written to /proc/PID/clear_refs will have no effect.
The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
using /proc/kpageflags and number of times a page is mapped using
/proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt.
1.2 Kernel data 1.2 Kernel data
--------------- ---------------

4
Documentation/filesystems/sharedsubtree.txt
View File

@@ -62,10 +62,10 @@ replicas continue to be exactly same.
# mount /dev/sd0 /tmp/a # mount /dev/sd0 /tmp/a
#ls /tmp/a #ls /tmp/a
t1 t2 t2 t1 t2 t3
#ls /mnt/a #ls /mnt/a
t1 t2 t2 t1 t2 t3
Note that the mount has propagated to the mount at /mnt as well. Note that the mount has propagated to the mount at /mnt as well.

11
Documentation/filesystems/xfs-delayed-logging-design.txt
View File

@@ -794,17 +794,6 @@ designed.
Roadmap: Roadmap:
2.6.37 Remove experimental tag from mount option
=> should be roughly 6 months after initial merge
=> enough time to:
=> gain confidence and fix problems reported by early
adopters (a.k.a. guinea pigs)
=> address worst performance regressions and undesired
behaviours
=> start tuning/optimising code for parallelism
=> start tuning/optimising algorithms consuming
excessive CPU time
2.6.39 Switch default mount option to use delayed logging 2.6.39 Switch default mount option to use delayed logging
=> should be roughly 12 months after initial merge => should be roughly 12 months after initial merge
=> enough time to shake out remaining problems before next round of => enough time to shake out remaining problems before next round of

28
Documentation/hwmon/it87
View File

@@ -22,6 +22,10 @@ Supported chips:
Prefix: 'it8720' Prefix: 'it8720'
Addresses scanned: from Super I/O config space (8 I/O ports) Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available Datasheet: Not publicly available
* IT8721F/IT8758E
Prefix: 'it8721'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* SiS950 [clone of IT8705F] * SiS950 [clone of IT8705F]
Prefix: 'it87' Prefix: 'it87'
Addresses scanned: from Super I/O config space (8 I/O ports) Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -67,7 +71,7 @@ Description
----------- -----------
This driver implements support for the IT8705F, IT8712F, IT8716F, This driver implements support for the IT8705F, IT8712F, IT8716F,
IT8718F, IT8720F, IT8726F and SiS950 chips. IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports, These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -86,14 +90,15 @@ the driver won't notice and report changes in the VID value. The two
upper VID bits share their pins with voltage inputs (in5 and in6) so you upper VID bits share their pins with voltage inputs (in5 and in6) so you
can't have both on a given board. can't have both on a given board.
The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions
2 additional fans. The additional fans are supported by the driver. have support for 2 additional fans. The additional fans are supported by the
driver.
The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and
optional 16-bit tachometer counters for fans 1 to 3. This is better (no more IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This
fan clock divider mess) but not compatible with the older chips and is better (no more fan clock divider mess) but not compatible with the older
revisions. The 16-bit tachometer mode is enabled by the driver when one chips and revisions. The 16-bit tachometer mode is enabled by the driver when
of the above chips is detected. one of the above chips is detected.
The IT8726F is just bit enhanced IT8716F with additional hardware The IT8726F is just bit enhanced IT8716F with additional hardware
for AMD power sequencing. Therefore the chip will appear as IT8716F for AMD power sequencing. Therefore the chip will appear as IT8716F
@@ -115,7 +120,12 @@ alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to maximum limit. Note that minimum in this case always means 'closest to
zero'; this is important for negative voltage measurements. All voltage zero'; this is important for negative voltage measurements. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution of inputs can measure voltages between 0 and 4.08 volts, with a resolution of
0.016 volt. The battery voltage in8 does not have limit registers. 0.016 volt (except IT8721F/IT8758E: 0.012 volt.) The battery voltage in8 does
not have limit registers.
On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside
the chip (in7, in8 and optionally in3). The driver handles this transparently
so user-space doesn't have to care.
The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value: The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
the voltage level your processor should work with. This is hardcoded by the voltage level your processor should work with. This is hardcoded by

60
Documentation/hwmon/lm85
View File

@@ -14,6 +14,10 @@ Supported chips:
Prefix: 'adt7463' Prefix: 'adt7463'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463
* Analog Devices ADT7468
Prefix: 'adt7468'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7468
* SMSC EMC6D100, SMSC EMC6D101 * SMSC EMC6D100, SMSC EMC6D101
Prefix: 'emc6d100' Prefix: 'emc6d100'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e Addresses scanned: I2C 0x2c, 0x2d, 0x2e
@@ -34,7 +38,7 @@ Description
----------- -----------
This driver implements support for the National Semiconductor LM85 and This driver implements support for the National Semiconductor LM85 and
compatible chips including the Analog Devices ADM1027, ADT7463 and compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and
SMSC EMC6D10x chips family. SMSC EMC6D10x chips family.
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0 The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
@@ -87,14 +91,22 @@ To smooth the response of fans to changes in temperature, the LM85 has an
optional filter for smoothing temperatures. The ADM1027 has the same optional filter for smoothing temperatures. The ADM1027 has the same
config option but uses it to rate limit the changes to fan speed instead. config option but uses it to rate limit the changes to fan speed instead.
The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure The ADM1027, ADT7463 and ADT7468 have a 10-bit ADC and can therefore
temperatures with 0.25 degC resolution. They also provide an offset to the measure temperatures with 0.25 degC resolution. They also provide an offset
temperature readings that is automatically applied during measurement. to the temperature readings that is automatically applied during
This offset can be used to zero out any errors due to traces and placement. measurement. This offset can be used to zero out any errors due to traces
The documentation says that the offset is in 0.25 degC steps, but in and placement. The documentation says that the offset is in 0.25 degC
initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has steps, but in initial testing of the ADM1027 it was 1.00 degC steps. Analog
confirmed this "bug". The ADT7463 is reported to work as described in the Devices has confirmed this "bug". The ADT7463 is reported to work as
documentation. The current lm85 driver does not show the offset register. described in the documentation. The current lm85 driver does not show the
offset register.
The ADT7468 has a high-frequency PWM mode, where all PWM outputs are
driven by a 22.5 kHz clock. This is a global mode, not per-PWM output,
which means that setting any PWM frequency above 11.3 kHz will switch
all 3 PWM outputs to a 22.5 kHz frequency. Conversely, setting any PWM
frequency below 11.3 kHz will switch all 3 PWM outputs to a frequency
between 10 and 100 Hz, which can then be tuned separately.
See the vendor datasheets for more information. There is application note See the vendor datasheets for more information. There is application note
from National (AN-1260) with some additional information about the LM85. from National (AN-1260) with some additional information about the LM85.
@@ -125,17 +137,17 @@ datasheet for a complete description of the differences. Other than
identifying the chip, the driver behaves no differently with regard to identifying the chip, the driver behaves no differently with regard to
these two chips. The LM85B is recommended for new designs. these two chips. The LM85B is recommended for new designs.
The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be The ADM1027, ADT7463 and ADT7468 chips have an optional SMBALERT output
used to signal the chipset in case a limit is exceeded or the temperature that can be used to signal the chipset in case a limit is exceeded or the
sensors fail. Individual sensor interrupts can be masked so they won't temperature sensors fail. Individual sensor interrupts can be masked so
trigger SMBALERT. The SMBALERT output if configured replaces one of the other they won't trigger SMBALERT. The SMBALERT output if configured replaces one
functions (PWM2 or IN0). This functionality is not implemented in current of the other functions (PWM2 or IN0). This functionality is not implemented
driver. in current driver.
The ADT7463 also has an optional THERM output/input which can be connected The ADT7463 and ADT7468 also have an optional THERM output/input which can
to the processor PROC_HOT output. If available, the autofan control be connected to the processor PROC_HOT output. If available, the autofan
dynamic Tmin feature can be enabled to keep the system temperature within control dynamic Tmin feature can be enabled to keep the system temperature
spec (just?!) with the least possible fan noise. within spec (just?!) with the least possible fan noise.
Configuration Notes Configuration Notes
------------------- -------------------
@@ -201,8 +213,8 @@ the temperatures to compensate for systemic errors in the
measurements. These features are not currently supported by the lm85 measurements. These features are not currently supported by the lm85
driver. driver.
In addition to the ADM1027 features, the ADT7463 also has Tmin control In addition to the ADM1027 features, the ADT7463 and ADT7468 also have
and THERM asserted counts. Automatic Tmin control acts to adjust the Tmin control and THERM asserted counts. Automatic Tmin control acts to
Tmin value to maintain the measured temperature sensor at a specified adjust the Tmin value to maintain the measured temperature sensor at a
temperature. There isn't much documentation on this feature in the specified temperature. There isn't much documentation on this feature in
ADT7463 data sheet. This is not supported by current driver. the ADT7463 data sheet. This is not supported by current driver.

44
Documentation/hwmon/lm90
View File

@@ -63,8 +63,8 @@ Supported chips:
Datasheet: Publicly available at the Maxim website Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
* Maxim MAX6659 * Maxim MAX6659
Prefix: 'max6657' Prefix: 'max6659'
Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e) Addresses scanned: I2C 0x4c, 0x4d, 0x4e
Datasheet: Publicly available at the Maxim website Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
* Maxim MAX6680 * Maxim MAX6680
@@ -84,6 +84,21 @@ Supported chips:
Addresses scanned: I2C 0x4c Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Maxim website Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
* Maxim MAX6695
Prefix: 'max6695'
Addresses scanned: I2C 0x18
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/datasheet/index.mvp/id/4199
* Maxim MAX6696
Prefix: 'max6695'
Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b,
0x4c, 0x4d and 0x4e
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/datasheet/index.mvp/id/4199
* Winbond/Nuvoton W83L771W/G
Prefix: 'w83l771'
Addresses scanned: I2C 0x4c
Datasheet: No longer available
* Winbond/Nuvoton W83L771AWG/ASG * Winbond/Nuvoton W83L771AWG/ASG
Prefix: 'w83l771' Prefix: 'w83l771'
Addresses scanned: I2C 0x4c Addresses scanned: I2C 0x4c
@@ -101,10 +116,11 @@ well as the temperature of up to one external diode. It is compatible
with many other devices, many of which are supported by this driver. with many other devices, many of which are supported by this driver.
Note that there is no easy way to differentiate between the MAX6657, Note that there is no easy way to differentiate between the MAX6657,
MAX6658 and MAX6659 variants. The extra address and features of the MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only
MAX6659 are not supported by this driver. The MAX6680 and MAX6681 only supported by this driver if the chip is located at address 0x4d or 0x4e,
differ in their pinout, therefore they obviously can't (and don't need to) or if the chip type is explicitly selected as max6659.
be distinguished. The MAX6680 and MAX6681 only differ in their pinout, therefore they obviously
can't (and don't need to) be distinguished.
The specificity of this family of chipsets over the ADM1021/LM84 The specificity of this family of chipsets over the ADM1021/LM84
family is that it features critical limits with hysteresis, and an family is that it features critical limits with hysteresis, and an
@@ -151,12 +167,22 @@ MAX6680 and MAX6681:
* Selectable address * Selectable address
* Remote sensor type selection * Remote sensor type selection
W83L771AWG/ASG MAX6695 and MAX6696:
* The AWG and ASG variants only differ in package format. * Better local resolution
* Selectable address (max6696)
* Second critical temperature limit
* Two remote sensors
W83L771W/G
* The G variant is lead-free, otherwise similar to the W.
* Filter and alert configuration register at 0xBF * Filter and alert configuration register at 0xBF
* Diode ideality factor configuration (remote sensor) at 0xE3
* Moving average (depending on conversion rate) * Moving average (depending on conversion rate)
W83L771AWG/ASG
* Successor of the W83L771W/G, same features.
* The AWG and ASG variants only differ in package format.
* Diode ideality factor configuration (remote sensor) at 0xE3
All temperature values are given in degrees Celsius. Resolution All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature, 0.125 degree for the remote is 1.0 degree for the local temperature, 0.125 degree for the remote
temperature, except for the MAX6657, MAX6658 and MAX6659 which have a temperature, except for the MAX6657, MAX6658 and MAX6659 which have a

63
Documentation/hwmon/ltc4261 Normal file
View File

@@ -0,0 +1,63 @@
Kernel driver ltc4261
=====================
Supported chips:
* Linear Technology LTC4261
Prefix: 'ltc4261'
Addresses scanned: -
Datasheet:
http://cds.linear.com/docs/Datasheet/42612fb.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
The LTC4261/LTC4261-2 negative voltage Hot Swap controllers allow a board
to be safely inserted and removed from a live backplane.
Usage Notes
-----------
This driver does not probe for LTC4261 devices, since there is no register
which can be safely used to identify the chip. You will have to instantiate
the devices explicitly.
Example: the following will load the driver for an LTC4261 at address 0x10
on I2C bus #1:
$ modprobe ltc4261
$ echo ltc4261 0x10 > /sys/bus/i2c/devices/i2c-1/new_device
Sysfs entries
-------------
Voltage readings provided by this driver are reported as obtained from the ADC
registers. If a set of voltage divider resistors is installed, calculate the
real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the
value of the divider resistor against the measured voltage and R2 is the value
of the divider resistor against Ground.
Current reading provided by this driver is reported as obtained from the ADC
Current Sense register. The reported value assumes that a 1 mOhm sense resistor
is installed. If a different sense resistor is installed, calculate the real
current by dividing the reported value by the sense resistor value in mOhm.
The chip has two voltage sensors, but only one set of voltage alarm status bits.
In many many designs, those alarms are associated with the ADIN2 sensor, due to
the proximity of the ADIN2 pin to the OV pin. ADIN2 is, however, not available
on all chip variants. To ensure that the alarm condition is reported to the user,
report it with both voltage sensors.
in1_input ADIN2 voltage (mV)
in1_min_alarm ADIN/ADIN2 Undervoltage alarm
in1_max_alarm ADIN/ADIN2 Overvoltage alarm
in2_input ADIN voltage (mV)
in2_min_alarm ADIN/ADIN2 Undervoltage alarm
in2_max_alarm ADIN/ADIN2 Overvoltage alarm
curr1_input SENSE current (mA)
curr1_alarm SENSE overcurrent alarm

18
Documentation/hwmon/pcf8591
View File

@@ -4,7 +4,7 @@ Kernel driver pcf8591
Supported chips: Supported chips:
* Philips/NXP PCF8591 * Philips/NXP PCF8591
Prefix: 'pcf8591' Prefix: 'pcf8591'
Addresses scanned: I2C 0x48 - 0x4f Addresses scanned: none
Datasheet: Publicly available at the NXP website Datasheet: Publicly available at the NXP website
http://www.nxp.com/pip/PCF8591_6.html http://www.nxp.com/pip/PCF8591_6.html
@@ -58,18 +58,16 @@ Module parameters
Accessing PCF8591 via /sys interface Accessing PCF8591 via /sys interface
------------------------------------- -------------------------------------
! Be careful ! The PCF8591 is plainly impossible to detect! Thus the driver won't even
The PCF8591 is plainly impossible to detect! Stupid chip. try. You have to explicitly instantiate the device at the relevant
So every chip with address in the interval [0x48..0x4f] is address (in the interval [0x48..0x4f]) either through platform data, or
detected as PCF8591. If you have other chips in this address using the sysfs interface. See Documentation/i2c/instantiating-devices
range, the workaround is to load this module after the one for details.
for your others chips.
On detection (i.e. insmod, modprobe et al.), directories are being Directories are being created for each instantiated PCF8591:
created for each detected PCF8591:
/sys/bus/i2c/devices/<0>-<1>/ /sys/bus/i2c/devices/<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0) where <0> is the bus the chip is connected to (e. g. i2c-0)
and <1> the chip address ([48..4f]) and <1> the chip address ([48..4f])
Inside these directories, there are such files: Inside these directories, there are such files:

15
Documentation/hwmon/sysfs-interface
View File

@@ -309,6 +309,20 @@ temp[1-*]_crit_hyst
from the critical value. from the critical value.
RW RW
temp[1-*]_emergency
Temperature emergency max value, for chips supporting more than
two upper temperature limits. Must be equal or greater than
corresponding temp_crit values.
Unit: millidegree Celsius
RW
temp[1-*]_emergency_hyst
Temperature hysteresis value for emergency limit.
Unit: millidegree Celsius
Must be reported as an absolute temperature, NOT a delta
from the emergency value.
RW
temp[1-*]_lcrit Temperature critical min value, typically lower than temp[1-*]_lcrit Temperature critical min value, typically lower than
corresponding temp_min values. corresponding temp_min values.
Unit: millidegree Celsius Unit: millidegree Celsius
@@ -505,6 +519,7 @@ fan[1-*]_max_alarm
temp[1-*]_min_alarm temp[1-*]_min_alarm
temp[1-*]_max_alarm temp[1-*]_max_alarm
temp[1-*]_crit_alarm temp[1-*]_crit_alarm
temp[1-*]_emergency_alarm
Limit alarm Limit alarm
0: no alarm 0: no alarm
1: alarm 1: alarm

6
Documentation/i2c/busses/i2c-i801
View File

@@ -15,10 +15,14 @@ Supported adapters:
* Intel 82801I (ICH9) * Intel 82801I (ICH9)
* Intel EP80579 (Tolapai) * Intel EP80579 (Tolapai)
* Intel 82801JI (ICH10) * Intel 82801JI (ICH10)
* Intel 3400/5 Series (PCH) * Intel 5/3400 Series (PCH)
* Intel Cougar Point (PCH) * Intel Cougar Point (PCH)
* Intel Patsburg (PCH)
Datasheets: Publicly available at the Intel website Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller
and the additional 'Integrated Device Function' controllers are supported.
Authors: Authors:
Mark Studebaker <mdsxyz123@yahoo.com> Mark Studebaker <mdsxyz123@yahoo.com>
Jean Delvare <khali@linux-fr.org> Jean Delvare <khali@linux-fr.org>

126
Documentation/input/ntrig.txt Normal file
View File

@@ -0,0 +1,126 @@
N-Trig touchscreen Driver
-------------------------
Copyright (c) 2008-2010 Rafi Rubin <rafi@seas.upenn.edu>
Copyright (c) 2009-2010 Stephane Chatty
This driver provides support for N-Trig pen and multi-touch sensors. Single
and multi-touch events are translated to the appropriate protocols for
the hid and input systems. Pen events are sufficiently hid compliant and
are left to the hid core. The driver also provides additional filtering
and utility functions accessible with sysfs and module parameters.
This driver has been reported to work properly with multiple N-Trig devices
attached.
Parameters
----------
Note: values set at load time are global and will apply to all applicable
devices. Adjusting parameters with sysfs will override the load time values,
but only for that one device.
The following parameters are used to configure filters to reduce noise:
activate_slack number of fingers to ignore before processing events
activation_height size threshold to activate immediately
activation_width
min_height size threshold bellow which fingers are ignored
min_width both to decide activation and during activity
deactivate_slack the number of "no contact" frames to ignore before
propagating the end of activity events
When the last finger is removed from the device, it sends a number of empty
frames. By holding off on deactivation for a few frames we can tolerate false
erroneous disconnects, where the sensor may mistakenly not detect a finger that
is still present. Thus deactivate_slack addresses problems where a users might
see breaks in lines during drawing, or drop an object during a long drag.
Additional sysfs items
----------------------
These nodes just provide easy access to the ranges reported by the device.
sensor_logical_height the range for positions reported during activity
sensor_logical_width
sensor_physical_height internal ranges not used for normal events but
sensor_physical_width useful for tuning
All N-Trig devices with product id of 1 report events in the ranges of
X: 0-9600
Y: 0-7200
However not all of these devices have the same physical dimensions. Most
seem to be 12" sensors (Dell Latitude XT and XT2 and the HP TX2), and
at least one model (Dell Studio 17) has a 17" sensor. The ratio of physical
to logical sizes is used to adjust the size based filter parameters.
Filtering
---------
With the release of the early multi-touch firmwares it became increasingly
obvious that these sensors were prone to erroneous events. Users reported
seeing both inappropriately dropped contact and ghosts, contacts reported
where no finger was actually touching the screen.
Deactivation slack helps prevent dropped contact for single touch use, but does
not address the problem of dropping one of more contacts while other contacts
are still active. Drops in the multi-touch context require additional
processing and should be handled in tandem with tacking.
As observed ghost contacts are similar to actual use of the sensor, but they
seem to have different profiles. Ghost activity typically shows up as small
short lived touches. As such, I assume that the longer the continuous stream
of events the more likely those events are from a real contact, and that the
larger the size of each contact the more likely it is real. Balancing the
goals of preventing ghosts and accepting real events quickly (to minimize
user observable latency), the filter accumulates confidence for incoming
events until it hits thresholds and begins propagating. In the interest in
minimizing stored state as well as the cost of operations to make a decision,
I've kept that decision simple.
Time is measured in terms of the number of fingers reported, not frames since
the probability of multiple simultaneous ghosts is expected to drop off
dramatically with increasing numbers. Rather than accumulate weight as a
function of size, I just use it as a binary threshold. A sufficiently large
contact immediately overrides the waiting period and leads to activation.
Setting the activation size thresholds to large values will result in deciding
primarily on activation slack. If you see longer lived ghosts, turning up the
activation slack while reducing the size thresholds may suffice to eliminate
the ghosts while keeping the screen quite responsive to firm taps.
Contacts continue to be filtered with min_height and min_width even after
the initial activation filter is satisfied. The intent is to provide
a mechanism for filtering out ghosts in the form of an extra finger while
you actually are using the screen. In practice this sort of ghost has
been far less problematic or relatively rare and I've left the defaults
set to 0 for both parameters, effectively turning off that filter.
I don't know what the optimal values are for these filters. If the defaults
don't work for you, please play with the parameters. If you do find other
values more comfortable, I would appreciate feedback.
The calibration of these devices does drift over time. If ghosts or contact
dropping worsen and interfere with the normal usage of your device, try
recalibrating it.
Calibration
-----------
The N-Trig windows tools provide calibration and testing routines. Also an
unofficial unsupported set of user space tools including a calibrator is
available at:
http://code.launchpad.net/~rafi-seas/+junk/ntrig_calib
Tracking
--------
As of yet, all tested N-Trig firmwares do not track fingers. When multiple
contacts are active they seem to be sorted primarily by Y position.

3
Documentation/ioctl/ioctl-number.txt
View File

@@ -259,7 +259,7 @@ Code Seq#(hex) Include File Comments
't' 00-7F linux/if_ppp.h 't' 00-7F linux/if_ppp.h
't' 80-8F linux/isdn_ppp.h 't' 80-8F linux/isdn_ppp.h
't' 90 linux/toshiba.h 't' 90 linux/toshiba.h
'u' 00-1F linux/smb_fs.h 'u' 00-1F linux/smb_fs.h gone
'v' all linux/videodev.h conflict! 'v' all linux/videodev.h conflict!
'v' 00-1F linux/ext2_fs.h conflict! 'v' 00-1F linux/ext2_fs.h conflict!
'v' 00-1F linux/fs.h conflict! 'v' 00-1F linux/fs.h conflict!
@@ -278,7 +278,6 @@ Code Seq#(hex) Include File Comments
<mailto:oe@port.de> <mailto:oe@port.de>
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
0x80 00-1F linux/fb.h 0x80 00-1F linux/fb.h
0x81 00-1F linux/videotext.h
0x88 00-3F media/ovcamchip.h 0x88 00-3F media/ovcamchip.h
0x89 00-06 arch/x86/include/asm/sockios.h 0x89 00-06 arch/x86/include/asm/sockios.h
0x89 0B-DF linux/sockios.h 0x89 0B-DF linux/sockios.h

3
Documentation/kbuild/kconfig-language.txt
View File

@@ -322,7 +322,8 @@ mainmenu:
"mainmenu" <prompt> "mainmenu" <prompt>
This sets the config program's title bar if the config program chooses This sets the config program's title bar if the config program chooses
to use it. to use it. It should be placed at the top of the configuration, before any
other statement.
Kconfig hints Kconfig hints

7
Documentation/kbuild/makefiles.txt
View File

@@ -776,6 +776,13 @@ This will delete the directory debian, including all subdirectories.
Kbuild will assume the directories to be in the same relative path as the Kbuild will assume the directories to be in the same relative path as the
Makefile if no absolute path is specified (path does not start with '/'). Makefile if no absolute path is specified (path does not start with '/').
To exclude certain files from make clean, use the $(no-clean-files) variable.
This is only a special case used in the top level Kbuild file:
Example:
#Kbuild
no-clean-files := $(bounds-file) $(offsets-file)
Usually kbuild descends down in subdirectories due to "obj-* := dir/", Usually kbuild descends down in subdirectories due to "obj-* := dir/",
but in the architecture makefiles where the kbuild infrastructure but in the architecture makefiles where the kbuild infrastructure
is not sufficient this sometimes needs to be explicit. is not sufficient this sometimes needs to be explicit.

723
Documentation/kbuild/modules.txt
View File

@@ -1,215 +1,185 @@
Building External Modules
In this document you will find information about: This document describes how to build an out-of-tree kernel module.
- how to build external modules
- how to make your module use the kbuild infrastructure
- how kbuild will install a kernel
- how to install modules in a non-standard location
=== Table of Contents === Table of Contents
=== 1 Introduction === 1 Introduction
=== 2 How to build external modules === 2 How to Build External Modules
--- 2.1 Building external modules --- 2.1 Command Syntax
--- 2.2 Available targets --- 2.2 Options
--- 2.3 Available options --- 2.3 Targets
--- 2.4 Preparing the kernel tree for module build --- 2.4 Building Separate Files
--- 2.5 Building separate files for a module === 3. Creating a Kbuild File for an External Module
=== 3. Example commands --- 3.1 Shared Makefile
=== 4. Creating a kbuild file for an external module --- 3.2 Separate Kbuild file and Makefile
=== 5. Include files --- 3.3 Binary Blobs
--- 5.1 How to include files from the kernel include dir --- 3.4 Building Multiple Modules
--- 5.2 External modules using an include/ dir === 4. Include Files
--- 5.3 External modules using several directories --- 4.1 Kernel Includes
=== 6. Module installation --- 4.2 Single Subdirectory
--- 6.1 INSTALL_MOD_PATH --- 4.3 Several Subdirectories
--- 6.2 INSTALL_MOD_DIR === 5. Module Installation
=== 7. Module versioning & Module.symvers --- 5.1 INSTALL_MOD_PATH
--- 7.1 Symbols from the kernel (vmlinux + modules) --- 5.2 INSTALL_MOD_DIR
--- 7.2 Symbols and external modules === 6. Module Versioning
--- 7.3 Symbols from another external module --- 6.1 Symbols From the Kernel (vmlinux + modules)
=== 8. Tips & Tricks --- 6.2 Symbols and External Modules
--- 8.1 Testing for CONFIG_FOO_BAR --- 6.3 Symbols From Another External Module
=== 7. Tips & Tricks
--- 7.1 Testing for CONFIG_FOO_BAR
=== 1. Introduction === 1. Introduction
kbuild includes functionality for building modules both "kbuild" is the build system used by the Linux kernel. Modules must use
within the kernel source tree and outside the kernel source tree. kbuild to stay compatible with changes in the build infrastructure and
The latter is usually referred to as external or "out-of-tree" to pick up the right flags to "gcc." Functionality for building modules
modules and is used both during development and for modules that both in-tree and out-of-tree is provided. The method for building
are not planned to be included in the kernel tree. either is similar, and all modules are initially developed and built
out-of-tree.
What is covered within this file is mainly information to authors Covered in this document is information aimed at developers interested
of modules. The author of an external module should supply in building out-of-tree (or "external") modules. The author of an
a makefile that hides most of the complexity, so one only has to type external module should supply a makefile that hides most of the
'make' to build the module. A complete example will be presented in complexity, so one only has to type "make" to build the module. This is
chapter 4, "Creating a kbuild file for an external module". easily accomplished, and a complete example will be presented in
section 3.
=== 2. How to build external modules === 2. How to Build External Modules
kbuild offers functionality to build external modules, with the To build external modules, you must have a prebuilt kernel available
prerequisite that there is a pre-built kernel available with full source. that contains the configuration and header files used in the build.
A subset of the targets available when building the kernel is available Also, the kernel must have been built with modules enabled. If you are
when building an external module. using a distribution kernel, there will be a package for the kernel you
are running provided by your distribution.
--- 2.1 Building external modules An alternative is to use the "make" target "modules_prepare." This will
make sure the kernel contains the information required. The target
exists solely as a simple way to prepare a kernel source tree for
building external modules.
Use the following command to build an external module: NOTE: "modules_prepare" will not build Module.symvers even if
CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
executed to make module versioning work.
make -C <path-to-kernel> M=`pwd` --- 2.1 Command Syntax
For the running kernel use: The command to build an external module is:
make -C /lib/modules/`uname -r`/build M=`pwd` $ make -C <path_to_kernel_src> M=$PWD
For the above command to succeed, the kernel must have been The kbuild system knows that an external module is being built
built with modules enabled. due to the "M=<dir>" option given in the command.
To install the modules that were just built: To build against the running kernel use:
make -C <path-to-kernel> M=`pwd` modules_install $ make -C /lib/modules/`uname -r`/build M=$PWD
More complex examples will be shown later, the above should Then to install the module(s) just built, add the target
be enough to get you started. "modules_install" to the command:
--- 2.2 Available targets $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install
$KDIR refers to the path to the kernel source top-level directory --- 2.2 Options
make -C $KDIR M=`pwd` ($KDIR refers to the path of the kernel source directory.)
Will build the module(s) located in current directory.
All output files will be located in the same directory
as the module source.
No attempts are made to update the kernel source, and it is
a precondition that a successful make has been executed
for the kernel.
make -C $KDIR M=`pwd` modules make -C $KDIR M=$PWD
The modules target is implied when no target is given.
Same functionality as if no target was specified.
See description above.
make -C $KDIR M=`pwd` modules_install -C $KDIR
Install the external module(s). The directory where the kernel source is located.
Installation default is in /lib/modules/<kernel-version>/extra, "make" will actually change to the specified directory
but may be prefixed with INSTALL_MOD_PATH - see separate when executing and will change back when finished.
chapter.
make -C $KDIR M=`pwd` clean M=$PWD
Remove all generated files for the module - the kernel Informs kbuild that an external module is being built.
source directory is not modified. The value given to "M" is the absolute path of the
directory where the external module (kbuild file) is
located.
make -C $KDIR M=`pwd` help --- 2.3 Targets
help will list the available target when building external
modules.
--- 2.3 Available options: When building an external module, only a subset of the "make"
targets are available.
$KDIR refers to the path to the kernel source top-level directory make -C $KDIR M=$PWD [target]
make -C $KDIR The default will build the module(s) located in the current
Used to specify where to find the kernel source. directory, so a target does not need to be specified. All
'$KDIR' represent the directory where the kernel source is. output files will also be generated in this directory. No
Make will actually change directory to the specified directory attempts are made to update the kernel source, and it is a
when executed but change back when finished. precondition that a successful "make" has been executed for the
kernel.
make -C $KDIR M=`pwd` modules
M= is used to tell kbuild that an external module is The default target for external modules. It has the
being built. same functionality as if no target was specified. See
The option given to M= is the directory where the external description above.
module (kbuild file) is located.
When an external module is being built only a subset of the
usual targets are available.
make -C $KDIR SUBDIRS=`pwd` modules_install
Same as M=. The SUBDIRS= syntax is kept for backwards Install the external module(s). The default location is
compatibility. /lib/modules/<kernel_release>/extra/, but a prefix may
be added with INSTALL_MOD_PATH (discussed in section 5).
--- 2.4 Preparing the kernel tree for module build clean
Remove all generated files in the module directory only.
To make sure the kernel contains the information required to help
build external modules the target 'modules_prepare' must be used. List the available targets for external modules.
'modules_prepare' exists solely as a simple way to prepare
a kernel source tree for building external modules.
Note: modules_prepare will not build Module.symvers even if
CONFIG_MODVERSIONS is set. Therefore a full kernel build
needs to be executed to make module versioning work.
--- 2.5 Building separate files for a module --- 2.4 Building Separate Files
It is possible to build single files which are part of a module.
This works equally well for the kernel, a module and even for It is possible to build single files that are part of a module.
This works equally well for the kernel, a module, and even for
external modules. external modules.
Examples (module foo.ko, consist of bar.o, baz.o):
make -C $KDIR M=`pwd` bar.lst Example (The module foo.ko, consist of bar.o and baz.o):
make -C $KDIR M=`pwd` bar.o make -C $KDIR M=$PWD bar.lst
make -C $KDIR M=`pwd` foo.ko make -C $KDIR M=$PWD baz.o
make -C $KDIR M=`pwd` / make -C $KDIR M=$PWD foo.ko
make -C $KDIR M=$PWD /
=== 3. Example commands === 3. Creating a Kbuild File for an External Module
This example shows the actual commands to be executed when building In the last section we saw the command to build a module for the
an external module for the currently running kernel. running kernel. The module is not actually built, however, because a
In the example below, the distribution is supposed to use the build file is required. Contained in this file will be the name of
facility to locate output files for a kernel compile in a different the module(s) being built, along with the list of requisite source
directory than the kernel source - but the examples will also work files. The file may be as simple as a single line:
when the source and the output files are mixed in the same directory.
# Kernel source obj-m := <module_name>.o
/lib/modules/<kernel-version>/source -> /usr/src/linux-<version>
# Output from kernel compile The kbuild system will build <module_name>.o from <module_name>.c,
/lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up and, after linking, will result in the kernel module <module_name>.ko.
The above line can be put in either a "Kbuild" file or a "Makefile."
When the module is built from multiple sources, an additional line is
needed listing the files:
Change to the directory where the kbuild file is located and execute <module_name>-y := <src1>.o <src2>.o ...
the following commands to build the module:
cd /home/user/src/module NOTE: Further documentation describing the syntax used by kbuild is
make -C /usr/src/`uname -r`/source \ located in Documentation/kbuild/makefiles.txt.
O=/lib/modules/`uname-r`/build \
M=`pwd`
Then, to install the module use the following command: The examples below demonstrate how to create a build file for the
module 8123.ko, which is built from the following files:
make -C /usr/src/`uname -r`/source \
O=/lib/modules/`uname-r`/build \
M=`pwd` \
modules_install
If you look closely you will see that this is the same command as
listed before - with the directories spelled out.
The above are rather long commands, and the following chapter
lists a few tricks to make it all easier.
=== 4. Creating a kbuild file for an external module
kbuild is the build system for the kernel, and external modules
must use kbuild to stay compatible with changes in the build system
and to pick up the right flags to gcc etc.
The kbuild file used as input shall follow the syntax described
in Documentation/kbuild/makefiles.txt. This chapter will introduce a few
more tricks to be used when dealing with external modules.
In the following a Makefile will be created for a module with the
following files:
8123_if.c 8123_if.c
8123_if.h 8123_if.h
8123_pci.c 8123_pci.c
8123_bin.o_shipped <= Binary blob 8123_bin.o_shipped <= Binary blob
--- 4.1 Shared Makefile for module and kernel --- 3.1 Shared Makefile
An external module always includes a wrapper Makefile supporting An external module always includes a wrapper makefile that
building the module using 'make' with no arguments. supports building the module using "make" with no arguments.
The Makefile provided will most likely include additional This target is not used by kbuild; it is only for convenience.
functionality such as test targets etc. and this part shall Additional functionality, such as test targets, can be included
be filtered away from kbuild since it may impact kbuild if but should be filtered out from kbuild due to possible name
name clashes occurs. clashes.
Example 1: Example 1:
--> filename: Makefile --> filename: Makefile
@@ -219,11 +189,11 @@ following files:
8123-y := 8123_if.o 8123_pci.o 8123_bin.o 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
else else
# Normal Makefile # normal makefile
KDIR ?= /lib/modules/`uname -r`/build
KERNELDIR := /lib/modules/`uname -r`/build default:
all:: $(MAKE) -C $(KDIR) M=$$PWD
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
# Module specific targets # Module specific targets
genbin: genbin:
@@ -231,15 +201,20 @@ following files:
endif endif
In example 1, the check for KERNELRELEASE is used to separate The check for KERNELRELEASE is used to separate the two parts
the two parts of the Makefile. kbuild will only see the two of the makefile. In the example, kbuild will only see the two
assignments whereas make will see everything except the two assignments, whereas "make" will see everything except these
kbuild assignments. two assignments. This is due to two passes made on the file:
the first pass is by the "make" instance run on the command
line; the second pass is by the kbuild system, which is
initiated by the parameterized "make" in the default target.
In recent versions of the kernel, kbuild will look for a file named --- 3.2 Separate Kbuild File and Makefile
Kbuild and as second option look for a file named Makefile.
Utilising the Kbuild file makes us split up the Makefile in example 1 In newer versions of the kernel, kbuild will first look for a
into two files as shown in example 2: file named "Kbuild," and only if that is not found, will it
then look for a makefile. Utilizing a "Kbuild" file allows us
to split up the makefile from example 1 into two files:
Example 2: Example 2:
--> filename: Kbuild --> filename: Kbuild
@@ -247,20 +222,21 @@ following files:
8123-y := 8123_if.o 8123_pci.o 8123_bin.o 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
--> filename: Makefile --> filename: Makefile
KERNELDIR := /lib/modules/`uname -r`/build KDIR ?= /lib/modules/`uname -r`/build
all::
$(MAKE) -C $(KERNELDIR) M=`pwd` $@ default:
$(MAKE) -C $(KDIR) M=$$PWD
# Module specific targets # Module specific targets
genbin: genbin:
echo "X" > 8123_bin.o_shipped echo "X" > 8123_bin.o_shipped
The split in example 2 is questionable due to the simplicity of
each file; however, some external modules use makefiles
consisting of several hundred lines, and here it really pays
off to separate the kbuild part from the rest.
In example 2, we are down to two fairly simple files and for simple The next example shows a backward compatible version.
files as used in this example the split is questionable. But some
external modules use Makefiles of several hundred lines and here it
really pays off to separate the kbuild part from the rest.
Example 3 shows a backward compatible version.
Example 3: Example 3:
--> filename: Kbuild --> filename: Kbuild
@@ -269,13 +245,15 @@ following files:
--> filename: Makefile --> filename: Makefile
ifneq ($(KERNELRELEASE),) ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
include Kbuild include Kbuild
else
# Normal Makefile
KERNELDIR := /lib/modules/`uname -r`/build else
all:: # normal makefile
$(MAKE) -C $(KERNELDIR) M=`pwd` $@ KDIR ?= /lib/modules/`uname -r`/build
default:
$(MAKE) -C $(KDIR) M=$$PWD
# Module specific targets # Module specific targets
genbin: genbin:
@@ -283,260 +261,271 @@ following files:
endif endif
The trick here is to include the Kbuild file from Makefile, so Here the "Kbuild" file is included from the makefile. This
if an older version of kbuild picks up the Makefile, the Kbuild allows an older version of kbuild, which only knows of
file will be included. makefiles, to be used when the "make" and kbuild parts are
split into separate files.
--- 4.2 Binary blobs included in a module --- 3.3 Binary Blobs
Some external modules needs to include a .o as a blob. kbuild Some external modules need to include an object file as a blob.
has support for this, but requires the blob file to be named kbuild has support for this, but requires the blob file to be
<filename>_shipped. In our example the blob is named named <filename>_shipped. When the kbuild rules kick in, a copy
8123_bin.o_shipped and when the kbuild rules kick in the file of <filename>_shipped is created with _shipped stripped off,
8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file giving us <filename>. This shortened filename can be used in
with the _shipped part stripped of the filename. the assignment to the module.
This allows the 8123_bin.o filename to be used in the assignment to
the module. Throughout this section, 8123_bin.o_shipped has been used to
build the kernel module 8123.ko; it has been included as
8123_bin.o.
Example 4:
obj-m := 8123.o
8123-y := 8123_if.o 8123_pci.o 8123_bin.o 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
In example 4, there is no distinction between the ordinary .c/.h files Although there is no distinction between the ordinary source
and the binary file. But kbuild will pick up different rules to create files and the binary file, kbuild will pick up different rules
the .o file. when creating the object file for the module.
--- 3.4 Building Multiple Modules
kbuild supports building multiple modules with a single build
file. For example, if you wanted to build two modules, foo.ko
and bar.ko, the kbuild lines would be:
obj-m := foo.o bar.o
foo-y := <foo_srcs>
bar-y := <bar_srcs>
It is that simple!
=== 5. Include files === 4. Include Files
Include files are a necessity when a .c file uses something from other .c Within the kernel, header files are kept in standard locations
files (not strictly in the sense of C, but if good programming practice is according to the following rule:
used). Any module that consists of more than one .c file will have a .h file
for one of the .c files.
- If the .h file only describes a module internal interface, then the .h file * If the header file only describes the internal interface of a
shall be placed in the same directory as the .c files. module, then the file is placed in the same directory as the
- If the .h files describe an interface used by other parts of the kernel source files.
located in different directories, the .h files shall be located in * If the header file describes an interface used by other parts
include/linux/ or other include/ directories as appropriate. of the kernel that are located in different directories, then
the file is placed in include/linux/.
One exception for this rule is larger subsystems that have their own directory NOTE: There are two notable exceptions to this rule: larger
under include/ such as include/scsi. Another exception is arch-specific subsystems have their own directory under include/, such as
.h files which are located under include/asm-$(ARCH)/*. include/scsi; and architecture specific headers are located
under arch/$(ARCH)/include/.
External modules have a tendency to locate include files in a separate include/ --- 4.1 Kernel Includes
directory and therefore need to deal with this in their kbuild file.
--- 5.1 How to include files from the kernel include dir To include a header file located under include/linux/, simply
use:
When a module needs to include a file from include/linux/, then one #include <linux/module.h>
just uses:
#include <linux/modules.h> kbuild will add options to "gcc" so the relevant directories
are searched.
kbuild will make sure to add options to gcc so the relevant --- 4.2 Single Subdirectory
directories are searched.
Likewise for .h files placed in the same directory as the .c file.
#include "8123_if.h" External modules tend to place header files in a separate
include/ directory where their source is located, although this
is not the usual kernel style. To inform kbuild of the
directory, use either ccflags-y or CFLAGS_<filename>.o.
will do the job. Using the example from section 3, if we moved 8123_if.h to a
subdirectory named include, the resulting kbuild file would
--- 5.2 External modules using an include/ dir look like:
External modules often locate their .h files in a separate include/
directory although this is not usual kernel style. When an external
module uses an include/ dir then kbuild needs to be told so.
The trick here is to use either EXTRA_CFLAGS (take effect for all .c
files) or CFLAGS_$F.o (take effect only for a single file).
In our example, if we move 8123_if.h to a subdirectory named include/
the resulting Kbuild file would look like:
--> filename: Kbuild --> filename: Kbuild
obj-m := 8123.o obj-m := 8123.o
EXTRA_CFLAGS := -Iinclude ccflags-y := -Iinclude
8123-y := 8123_if.o 8123_pci.o 8123_bin.o 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
Note that in the assignment there is no space between -I and the path. Note that in the assignment there is no space between -I and
This is a kbuild limitation: there must be no space present. the path. This is a limitation of kbuild: there must be no
space present.
--- 5.3 External modules using several directories --- 4.3 Several Subdirectories
If an external module does not follow the usual kernel style, but
decides to spread files over several directories, then kbuild can
handle this too.
kbuild can handle files that are spread over several directories.
Consider the following example: Consider the following example:
| .
+- src/complex_main.c |__ src
| +- hal/hardwareif.c | |__ complex_main.c
| +- hal/include/hardwareif.h | |__ hal
+- include/complex.h | |__ hardwareif.c
| |__ include
| |__ hardwareif.h
|__ include
|__ complex.h
To build a single module named complex.ko, we then need the following To build the module complex.ko, we then need the following
kbuild file: kbuild file:
Kbuild: --> filename: Kbuild
obj-m := complex.o obj-m := complex.o
complex-y := src/complex_main.o complex-y := src/complex_main.o
complex-y += src/hal/hardwareif.o complex-y += src/hal/hardwareif.o
EXTRA_CFLAGS := -I$(src)/include ccflags-y := -I$(src)/include
EXTRA_CFLAGS += -I$(src)src/hal/include ccflags-y += -I$(src)/src/hal/include
As you can see, kbuild knows how to handle object files located
in other directories. The trick is to specify the directory
relative to the kbuild file's location. That being said, this
is NOT recommended practice.
For the header files, kbuild must be explicitly told where to
look. When kbuild executes, the current directory is always the
root of the kernel tree (the argument to "-C") and therefore an
absolute path is needed. $(src) provides the absolute path by
pointing to the directory where the currently executing kbuild
file is located.
kbuild knows how to handle .o files located in another directory - === 5. Module Installation
although this is NOT recommended practice. The syntax is to specify
the directory relative to the directory where the Kbuild file is
located.
To find the .h files, we have to explicitly tell kbuild where to look Modules which are included in the kernel are installed in the
for the .h files. When kbuild executes, the current directory is always directory:
the root of the kernel tree (argument to -C) and therefore we have to
tell kbuild how to find the .h files using absolute paths.
$(src) will specify the absolute path to the directory where the
Kbuild file are located when being build as an external module.
Therefore -I$(src)/ is used to point out the directory of the Kbuild
file and any additional path are just appended.
=== 6. Module installation /lib/modules/$(KERNELRELEASE)/kernel/
Modules which are included in the kernel are installed in the directory: And external modules are installed in:
/lib/modules/$(KERNELRELEASE)/kernel /lib/modules/$(KERNELRELEASE)/extra/
External modules are installed in the directory: --- 5.1 INSTALL_MOD_PATH
/lib/modules/$(KERNELRELEASE)/extra Above are the default directories but as always some level of
customization is possible. A prefix can be added to the
--- 6.1 INSTALL_MOD_PATH installation path using the variable INSTALL_MOD_PATH:
Above are the default directories, but as always, some level of
customization is possible. One can prefix the path using the variable
INSTALL_MOD_PATH:
$ make INSTALL_MOD_PATH=/frodo modules_install $ make INSTALL_MOD_PATH=/frodo modules_install
=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/
INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the INSTALL_MOD_PATH may be set as an ordinary shell variable or,
example above, can be specified on the command line when calling make. as shown above, can be specified on the command line when
INSTALL_MOD_PATH has effect both when installing modules included in calling "make." This has effect when installing both in-tree
the kernel as well as when installing external modules. and out-of-tree modules.
--- 6.2 INSTALL_MOD_DIR --- 5.2 INSTALL_MOD_DIR
When installing external modules they are by default installed to a External modules are by default installed to a directory under
directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish /lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
to locate modules for a specific functionality in a separate locate modules for a specific functionality in a separate
directory. For this purpose, one can use INSTALL_MOD_DIR to specify an directory. For this purpose, use INSTALL_MOD_DIR to specify an
alternative name to 'extra'. alternative name to "extra."
$ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \ $ make INSTALL_MOD_DIR=gandalf -C $KDIR \
M=`pwd` modules_install M=$PWD modules_install
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/
=== 7. Module versioning & Module.symvers === 6. Module Versioning
Module versioning is enabled by the CONFIG_MODVERSIONS tag. Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
as a simple ABI consistency check. A CRC value of the full prototype
for an exported symbol is created. When a module is loaded/used, the
CRC values contained in the kernel are compared with similar values in
the module; if they are not equal, the kernel refuses to load the
module.
Module versioning is used as a simple ABI consistency check. The Module Module.symvers contains a list of all exported symbols from a kernel
versioning creates a CRC value of the full prototype for an exported symbol and build.
when a module is loaded/used then the CRC values contained in the kernel are
compared with similar values in the module. If they are not equal, then the
kernel refuses to load the module.
Module.symvers contains a list of all exported symbols from a kernel build. --- 6.1 Symbols From the Kernel (vmlinux + modules)
--- 7.1 Symbols from the kernel (vmlinux + modules) During a kernel build, a file named Module.symvers will be
generated. Module.symvers contains all exported symbols from
During a kernel build, a file named Module.symvers will be generated. the kernel and compiled modules. For each symbol, the
Module.symvers contains all exported symbols from the kernel and corresponding CRC value is also stored.
compiled modules. For each symbols, the corresponding CRC value
is stored too.
The syntax of the Module.symvers file is: The syntax of the Module.symvers file is:
<CRC> <Symbol> <module> <CRC> <Symbol> <module>
Sample:
0x2d036834 scsi_remove_host drivers/scsi/scsi_mod 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
For a kernel build without CONFIG_MODVERSIONS enabled, the crc For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
would read: 0x00000000 would read 0x00000000.
Module.symvers serves two purposes: Module.symvers serves two purposes:
1) It lists all exported symbols both from vmlinux and all modules 1) It lists all exported symbols from vmlinux and all modules.
2) It lists the CRC if CONFIG_MODVERSIONS is enabled 2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
--- 7.2 Symbols and external modules --- 6.2 Symbols and External Modules
When building an external module, the build system needs access to When building an external module, the build system needs access
the symbols from the kernel to check if all external symbols are to the symbols from the kernel to check if all external symbols
defined. This is done in the MODPOST step and to obtain all are defined. This is done in the MODPOST step. modpost obtains
symbols, modpost reads Module.symvers from the kernel. the symbols by reading Module.symvers from the kernel source
If a Module.symvers file is present in the directory where tree. If a Module.symvers file is present in the directory
the external module is being built, this file will be read too. where the external module is being built, this file will be
During the MODPOST step, a new Module.symvers file will be written read too. During the MODPOST step, a new Module.symvers file
containing all exported symbols that were not defined in the kernel. will be written containing all exported symbols that were not
defined in the kernel.
--- 7.3 Symbols from another external module --- 6.3 Symbols From Another External Module
Sometimes, an external module uses exported symbols from another Sometimes, an external module uses exported symbols from
external module. Kbuild needs to have full knowledge on all symbols another external module. kbuild needs to have full knowledge of
to avoid spitting out warnings about undefined symbols. all symbols to avoid spitting out warnings about undefined
Three solutions exist to let kbuild know all symbols of more than symbols. Three solutions exist for this situation.
one external module.
The method with a top-level kbuild file is recommended but may be
impractical in certain situations.
Use a top-level Kbuild file NOTE: The method with a top-level kbuild file is recommended
If you have two modules: 'foo' and 'bar', and 'foo' needs but may be impractical in certain situations.
symbols from 'bar', then one can use a common top-level kbuild
file so both modules are compiled in same build.
Consider following directory layout: Use a top-level kbuild file
./foo/ <= contains the foo module If you have two modules, foo.ko and bar.ko, where
./bar/ <= contains the bar module foo.ko needs symbols from bar.ko, you can use a
The top-level Kbuild file would then look like: common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout:
#./Kbuild: (this file may also be named Makefile) ./foo/ <= contains foo.ko
./bar/ <= contains bar.ko
The top-level kbuild file would then look like:
#./Kbuild (or ./Makefile):
obj-y := foo/ bar/ obj-y := foo/ bar/
Executing: And executing
make -C $KDIR M=`pwd`
will then do the expected and compile both modules with full $ make -C $KDIR M=$PWD
knowledge on symbols from both modules.
will then do the expected and compile both modules with
full knowledge of symbols from either module.
Use an extra Module.symvers file Use an extra Module.symvers file
When an external module is built, a Module.symvers file is When an external module is built, a Module.symvers file
generated containing all exported symbols which are not is generated containing all exported symbols which are
defined in the kernel. not defined in the kernel. To get access to symbols
To get access to symbols from module 'bar', one can copy the from bar.ko, copy the Module.symvers file from the
Module.symvers file from the compilation of the 'bar' module compilation of bar.ko to the directory where foo.ko is
to the directory where the 'foo' module is built. built. During the module build, kbuild will read the
During the module build, kbuild will read the Module.symvers Module.symvers file in the directory of the external
file in the directory of the external module and when the module, and when the build is finished, a new
build is finished, a new Module.symvers file is created Module.symvers file is created containing the sum of
containing the sum of all symbols defined and not part of the all symbols defined and not part of the kernel.
kernel.
Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile Use "make" variable KBUILD_EXTRA_SYMBOLS
If it is impractical to copy Module.symvers from another If it is impractical to copy Module.symvers from
module, you can assign a space separated list of files to another module, you can assign a space separated list
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be of files to KBUILD_EXTRA_SYMBOLS in your build file.
loaded by modpost during the initialisation of its symbol These files will be loaded by modpost during the
tables. initialization of its symbol tables.
=== 8. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR === 7. Tips & Tricks
Modules often need to check for certain CONFIG_ options to decide if --- 7.1 Testing for CONFIG_FOO_BAR
a specific feature shall be included in the module. When kbuild is used
this is done by referencing the CONFIG_ variable directly. Modules often need to check for certain CONFIG_ options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the CONFIG_ variable
directly.
#fs/ext2/Makefile #fs/ext2/Makefile
obj-$(CONFIG_EXT2_FS) += ext2.o obj-$(CONFIG_EXT2_FS) += ext2.o
@@ -544,9 +533,9 @@ Module.symvers contains a list of all exported symbols from a kernel build.
ext2-y := balloc.o bitmap.o dir.o ext2-y := balloc.o bitmap.o dir.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
External modules have traditionally used grep to check for specific External modules have traditionally used "grep" to check for
CONFIG_ settings directly in .config. This usage is broken. specific CONFIG_ settings directly in .config. This usage is
As introduced before, external modules shall use kbuild when building broken. As introduced before, external modules should use
and therefore can use the same methods as in-kernel modules when kbuild for building and can therefore use the same methods as
testing for CONFIG_ definitions. in-tree modules when testing for CONFIG_ definitions.

40
Documentation/kernel-parameters.txt
View File

@@ -43,10 +43,11 @@ parameter is applicable:
AVR32 AVR32 architecture is enabled. AVR32 AVR32 architecture is enabled.
AX25 Appropriate AX.25 support is enabled. AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled. BLACKFIN Blackfin architecture is enabled.
DRM Direct Rendering Management support is enabled.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
EFI EFI Partitioning (GPT) is enabled EFI EFI Partitioning (GPT) is enabled
EIDE EIDE/ATAPI support is enabled. EIDE EIDE/ATAPI support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
FB The frame buffer device is enabled. FB The frame buffer device is enabled.
GCOV GCOV profiling is enabled. GCOV GCOV profiling is enabled.
HW Appropriate hardware is enabled. HW Appropriate hardware is enabled.
@@ -570,6 +571,10 @@ and is between 256 and 4096 characters. It is defined in the file
Format: <port#>,<type> Format: <port#>,<type>
See also Documentation/input/joystick-parport.txt See also Documentation/input/joystick-parport.txt
ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See Documentation/dynamic-debug-howto.txt for
details.
debug [KNL] Enable kernel debugging (events log level). debug [KNL] Enable kernel debugging (events log level).
debug_locks_verbose= debug_locks_verbose=
@@ -701,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file
arch/x86/kernel/cpu/cpufreq/elanfreq.c. arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elevator= [IOSCHED] elevator= [IOSCHED]
Format: {"anticipatory" | "cfq" | "deadline" | "noop"} Format: {"cfq" | "deadline" | "noop"}
See Documentation/block/as-iosched.txt and See Documentation/block/as-iosched.txt and
Documentation/block/deadline-iosched.txt for details. Documentation/block/deadline-iosched.txt for details.
@@ -1126,9 +1131,13 @@ and is between 256 and 4096 characters. It is defined in the file
kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging. kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging.
Default is 1 (enabled) Default is 1 (enabled)
kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit
KVM MMU at runtime.
Default is 0 (off) Default is 0 (off)
kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM.
Default is 1 (enabled)
kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU) kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU)
for all guests. for all guests.
Default is 1 (enabled) if in 64bit or 32bit-PAE mode Default is 1 (enabled) if in 64bit or 32bit-PAE mode
@@ -1532,12 +1541,15 @@ and is between 256 and 4096 characters. It is defined in the file
1 to enable accounting 1 to enable accounting
Default value is 0. Default value is 0.
nfsaddrs= [NFS] nfsaddrs= [NFS] Deprecated. Use ip= instead.
See Documentation/filesystems/nfs/nfsroot.txt. See Documentation/filesystems/nfs/nfsroot.txt.
nfsroot= [NFS] nfs root filesystem for disk-less boxes. nfsroot= [NFS] nfs root filesystem for disk-less boxes.
See Documentation/filesystems/nfs/nfsroot.txt. See Documentation/filesystems/nfs/nfsroot.txt.
nfsrootdebug [NFS] enable nfsroot debugging messages.
See Documentation/filesystems/nfs/nfsroot.txt.
nfs.callback_tcpport= nfs.callback_tcpport=
[NFS] set the TCP port on which the NFSv4 callback [NFS] set the TCP port on which the NFSv4 callback
channel should listen. channel should listen.
@@ -1693,6 +1705,8 @@ and is between 256 and 4096 characters. It is defined in the file
nojitter [IA64] Disables jitter checking for ITC timers. nojitter [IA64] Disables jitter checking for ITC timers.
no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic [X86-32,APIC] Do not enable or use the local APIC.
nolapic_timer [X86-32,APIC] Do not use the local APIC timer. nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
@@ -1713,7 +1727,7 @@ and is between 256 and 4096 characters. It is defined in the file
norandmaps Don't use address space randomization. Equivalent to norandmaps Don't use address space randomization. Equivalent to
echo 0 > /proc/sys/kernel/randomize_va_space echo 0 > /proc/sys/kernel/randomize_va_space
noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops noreplace-paravirt [X86,IA-64,PV_OPS] Don't patch paravirt_ops
noreplace-smp [X86-32,SMP] Don't replace SMP instructions noreplace-smp [X86-32,SMP] Don't replace SMP instructions
with UP alternatives with UP alternatives
@@ -2161,6 +2175,11 @@ and is between 256 and 4096 characters. It is defined in the file
reset_devices [KNL] Force drivers to reset the underlying device reset_devices [KNL] Force drivers to reset the underlying device
during initialization. during initialization.
resource_alloc_from_bottom
Allocate new resources from the beginning of available
space, not the end. If you need to use this, please
report a bug.
resume= [SWSUSP] resume= [SWSUSP]
Specify the partition device for software suspend Specify the partition device for software suspend
@@ -2370,6 +2389,15 @@ and is between 256 and 4096 characters. It is defined in the file
switches= [HW,M68k] switches= [HW,M68k]
sysfs.deprecated=0|1 [KNL]
Enable/disable old style sysfs layout for old udev
on older distributions. When this option is enabled
very new udev will not work anymore. When this option
is disabled (or CONFIG_SYSFS_DEPRECATED not compiled)
in older udev will not work anymore.
Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in
the kernel configuration.
sysrq_always_enabled sysrq_always_enabled
[KNL] [KNL]
Ignore sysrq setting - this boot parameter will Ignore sysrq setting - this boot parameter will
@@ -2418,7 +2446,7 @@ and is between 256 and 4096 characters. It is defined in the file
topology informations if the hardware supports these. topology informations if the hardware supports these.
The scheduler will make use of these informations and The scheduler will make use of these informations and
e.g. base its process migration decisions on it. e.g. base its process migration decisions on it.
Default is off. Default is on.
tp720= [HW,PS2] tp720= [HW,PS2]

61
Documentation/kvm/api.txt
View File

@@ -320,13 +320,13 @@ struct kvm_translation {
4.15 KVM_INTERRUPT 4.15 KVM_INTERRUPT
Capability: basic Capability: basic
Architectures: x86 Architectures: x86, ppc
Type: vcpu ioctl Type: vcpu ioctl
Parameters: struct kvm_interrupt (in) Parameters: struct kvm_interrupt (in)
Returns: 0 on success, -1 on error Returns: 0 on success, -1 on error
Queues a hardware interrupt vector to be injected. This is only Queues a hardware interrupt vector to be injected. This is only
useful if in-kernel local APIC is not used. useful if in-kernel local APIC or equivalent is not used.
/* for KVM_INTERRUPT */ /* for KVM_INTERRUPT */
struct kvm_interrupt { struct kvm_interrupt {
@@ -334,8 +334,37 @@ struct kvm_interrupt {
__u32 irq; __u32 irq;
}; };
X86:
Note 'irq' is an interrupt vector, not an interrupt pin or line. Note 'irq' is an interrupt vector, not an interrupt pin or line.
PPC:
Queues an external interrupt to be injected. This ioctl is overleaded
with 3 different irq values:
a) KVM_INTERRUPT_SET
This injects an edge type external interrupt into the guest once it's ready
to receive interrupts. When injected, the interrupt is done.
b) KVM_INTERRUPT_UNSET
This unsets any pending interrupt.
Only available with KVM_CAP_PPC_UNSET_IRQ.
c) KVM_INTERRUPT_SET_LEVEL
This injects a level type external interrupt into the guest context. The
interrupt stays pending until a specific ioctl with KVM_INTERRUPT_UNSET
is triggered.
Only available with KVM_CAP_PPC_IRQ_LEVEL.
Note that any value for 'irq' other than the ones stated above is invalid
and incurs unexpected behavior.
4.16 KVM_DEBUG_GUEST 4.16 KVM_DEBUG_GUEST
Capability: basic Capability: basic
@@ -1013,8 +1042,9 @@ number is just right, the 'nent' field is adjusted to the number of valid
entries in the 'entries' array, which is then filled. entries in the 'entries' array, which is then filled.
The entries returned are the host cpuid as returned by the cpuid instruction, The entries returned are the host cpuid as returned by the cpuid instruction,
with unknown or unsupported features masked out. The fields in each entry with unknown or unsupported features masked out. Some features (for example,
are defined as follows: x2apic), may not be present in the host cpu, but are exposed by kvm if it can
emulate them efficiently. The fields in each entry are defined as follows:
function: the eax value used to obtain the entry function: the eax value used to obtain the entry
index: the ecx value used to obtain the entry (for entries that are index: the ecx value used to obtain the entry (for entries that are
@@ -1032,6 +1062,29 @@ are defined as follows:
eax, ebx, ecx, edx: the values returned by the cpuid instruction for eax, ebx, ecx, edx: the values returned by the cpuid instruction for
this function/index combination this function/index combination
4.46 KVM_PPC_GET_PVINFO
Capability: KVM_CAP_PPC_GET_PVINFO
Architectures: ppc
Type: vm ioctl
Parameters: struct kvm_ppc_pvinfo (out)
Returns: 0 on success, !0 on error
struct kvm_ppc_pvinfo {
__u32 flags;
__u32 hcall[4];
__u8 pad[108];
};
This ioctl fetches PV specific information that need to be passed to the guest
using the device tree or other means from vm context.
For now the only implemented piece of information distributed here is an array
of 4 instructions that make up a hypercall.
If any additional field gets added to this structure later on, a bit for that
additional piece of information will be set in the flags bitmap.
5. The kvm_run structure 5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by Application code obtains a pointer to the kvm_run structure by

196
Documentation/kvm/ppc-pv.txt Normal file
View File

@@ -0,0 +1,196 @@
The PPC KVM paravirtual interface
=================================
The basic execution principle by which KVM on PowerPC works is to run all kernel
space code in PR=1 which is user space. This way we trap all privileged
instructions and can emulate them accordingly.
Unfortunately that is also the downfall. There are quite some privileged
instructions that needlessly return us to the hypervisor even though they
could be handled differently.
This is what the PPC PV interface helps with. It takes privileged instructions
and transforms them into unprivileged ones with some help from the hypervisor.
This cuts down virtualization costs by about 50% on some of my benchmarks.
The code for that interface can be found in arch/powerpc/kernel/kvm*
Querying for existence
======================
To find out if we're running on KVM or not, we leverage the device tree. When
Linux is running on KVM, a node /hypervisor exists. That node contains a
compatible property with the value "linux,kvm".
Once you determined you're running under a PV capable KVM, you can now use
hypercalls as described below.
KVM hypercalls
==============
Inside the device tree's /hypervisor node there's a property called
'hypercall-instructions'. This property contains at most 4 opcodes that make
up the hypercall. To call a hypercall, just call these instructions.
The parameters are as follows:
Register IN OUT
r0 - volatile
r3 1st parameter Return code
r4 2nd parameter 1st output value
r5 3rd parameter 2nd output value
r6 4th parameter 3rd output value
r7 5th parameter 4th output value
r8 6th parameter 5th output value
r9 7th parameter 6th output value
r10 8th parameter 7th output value
r11 hypercall number 8th output value
r12 - volatile
Hypercall definitions are shared in generic code, so the same hypercall numbers
apply for x86 and powerpc alike with the exception that each KVM hypercall
also needs to be ORed with the KVM vendor code which is (42 << 16).
Return codes can be as follows:
Code Meaning
0 Success
12 Hypercall not implemented
<0 Error
The magic page
==============
To enable communication between the hypervisor and guest there is a new shared
page that contains parts of supervisor visible register state. The guest can
map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE.
With this hypercall issued the guest always gets the magic page mapped at the
desired location in effective and physical address space. For now, we always
map the page to -4096. This way we can access it using absolute load and store
functions. The following instruction reads the first field of the magic page:
ld rX, -4096(0)
The interface is designed to be extensible should there be need later to add
additional registers to the magic page. If you add fields to the magic page,
also define a new hypercall feature to indicate that the host can give you more
registers. Only if the host supports the additional features, make use of them.
The magic page has the following layout as described in
arch/powerpc/include/asm/kvm_para.h:
struct kvm_vcpu_arch_shared {
__u64 scratch1;
__u64 scratch2;
__u64 scratch3;
__u64 critical; /* Guest may not get interrupts if == r1 */
__u64 sprg0;
__u64 sprg1;
__u64 sprg2;
__u64 sprg3;
__u64 srr0;
__u64 srr1;
__u64 dar;
__u64 msr;
__u32 dsisr;
__u32 int_pending; /* Tells the guest if we have an interrupt */
};
Additions to the page must only occur at the end. Struct fields are always 32
or 64 bit aligned, depending on them being 32 or 64 bit wide respectively.
Magic page features
===================
When mapping the magic page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE,
a second return value is passed to the guest. This second return value contains
a bitmap of available features inside the magic page.
The following enhancements to the magic page are currently available:
KVM_MAGIC_FEAT_SR Maps SR registers r/w in the magic page
For enhanced features in the magic page, please check for the existence of the
feature before using them!
MSR bits
========
The MSR contains bits that require hypervisor intervention and bits that do
not require direct hypervisor intervention because they only get interpreted
when entering the guest or don't have any impact on the hypervisor's behavior.
The following bits are safe to be set inside the guest:
MSR_EE
MSR_RI
MSR_CR
MSR_ME
If any other bit changes in the MSR, please still use mtmsr(d).
Patched instructions
====================
The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
respectively on 32 bit systems with an added offset of 4 to accomodate for big
endianness.
The following is a list of mapping the Linux kernel performs when running as
guest. Implementing any of those mappings is optional, as the instruction traps
also act on the shared page. So calling privileged instructions still works as
before.
From To
==== ==
mfmsr rX ld rX, magic_page->msr
mfsprg rX, 0 ld rX, magic_page->sprg0
mfsprg rX, 1 ld rX, magic_page->sprg1
mfsprg rX, 2 ld rX, magic_page->sprg2
mfsprg rX, 3 ld rX, magic_page->sprg3
mfsrr0 rX ld rX, magic_page->srr0
mfsrr1 rX ld rX, magic_page->srr1
mfdar rX ld rX, magic_page->dar
mfdsisr rX lwz rX, magic_page->dsisr
mtmsr rX std rX, magic_page->msr
mtsprg 0, rX std rX, magic_page->sprg0
mtsprg 1, rX std rX, magic_page->sprg1
mtsprg 2, rX std rX, magic_page->sprg2
mtsprg 3, rX std rX, magic_page->sprg3
mtsrr0 rX std rX, magic_page->srr0
mtsrr1 rX std rX, magic_page->srr1
mtdar rX std rX, magic_page->dar
mtdsisr rX stw rX, magic_page->dsisr
tlbsync nop
mtmsrd rX, 0 b <special mtmsr section>
mtmsr rX b <special mtmsr section>
mtmsrd rX, 1 b <special mtmsrd section>
[Book3S only]
mtsrin rX, rY b <special mtsrin section>
[BookE only]
wrteei [0|1] b <special wrteei section>
Some instructions require more logic to determine what's going on than a load
or store instruction can deliver. To enable patching of those, we keep some
RAM around where we can live translate instructions to. What happens is the
following:
1) copy emulation code to memory
2) patch that code to fit the emulated instruction
3) patch that code to return to the original pc + 4
4) patch the original instruction to branch to the new code
That way we can inject an arbitrary amount of code as replacement for a single
instruction. This allows us to check for pending interrupts when setting EE=1
for example.

612
Documentation/kvm/timekeeping.txt Normal file
View File

@@ -0,0 +1,612 @@
Timekeeping Virtualization for X86-Based Architectures
Zachary Amsden <zamsden@redhat.com>
Copyright (c) 2010, Red Hat. All rights reserved.
1) Overview
2) Timing Devices
3) TSC Hardware
4) Virtualization Problems
=========================================================================
1) Overview
One of the most complicated parts of the X86 platform, and specifically,
the virtualization of this platform is the plethora of timing devices available
and the complexity of emulating those devices. In addition, virtualization of
time introduces a new set of challenges because it introduces a multiplexed
division of time beyond the control of the guest CPU.
First, we will describe the various timekeeping hardware available, then
present some of the problems which arise and solutions available, giving
specific recommendations for certain classes of KVM guests.
The purpose of this document is to collect data and information relevant to
timekeeping which may be difficult to find elsewhere, specifically,
information relevant to KVM and hardware-based virtualization.
=========================================================================
2) Timing Devices
First we discuss the basic hardware devices available. TSC and the related
KVM clock are special enough to warrant a full exposition and are described in
the following section.
2.1) i8254 - PIT
One of the first timer devices available is the programmable interrupt timer,
or PIT. The PIT has a fixed frequency 1.193182 MHz base clock and three
channels which can be programmed to deliver periodic or one-shot interrupts.
These three channels can be configured in different modes and have individual
counters. Channel 1 and 2 were not available for general use in the original
IBM PC, and historically were connected to control RAM refresh and the PC
speaker. Now the PIT is typically integrated as part of an emulated chipset
and a separate physical PIT is not used.
The PIT uses I/O ports 0x40 - 0x43. Access to the 16-bit counters is done
using single or multiple byte access to the I/O ports. There are 6 modes
available, but not all modes are available to all timers, as only timer 2
has a connected gate input, required for modes 1 and 5. The gate line is
controlled by port 61h, bit 0, as illustrated in the following diagram.
-------------- ----------------
| | | |
| 1.1932 MHz |---------->| CLOCK OUT | ---------> IRQ 0
| Clock | | | |
-------------- | +->| GATE TIMER 0 |
| ----------------
|
| ----------------
| | |
|------>| CLOCK OUT | ---------> 66.3 KHZ DRAM
| | | (aka /dev/null)
| +->| GATE TIMER 1 |
| ----------------
|
| ----------------
| | |
|------>| CLOCK OUT | ---------> Port 61h, bit 5
| | |
Port 61h, bit 0 ---------->| GATE TIMER 2 | \_.---- ____
---------------- _| )--|LPF|---Speaker
/ *---- \___/
Port 61h, bit 1 -----------------------------------/
The timer modes are now described.
Mode 0: Single Timeout. This is a one-shot software timeout that counts down
when the gate is high (always true for timers 0 and 1). When the count
reaches zero, the output goes high.
Mode 1: Triggered One-shot. The output is intially set high. When the gate
line is set high, a countdown is initiated (which does not stop if the gate is
lowered), during which the output is set low. When the count reaches zero,
the output goes high.
Mode 2: Rate Generator. The output is initially set high. When the countdown
reaches 1, the output goes low for one count and then returns high. The value
is reloaded and the countdown automatically resumes. If the gate line goes
low, the count is halted. If the output is low when the gate is lowered, the
output automatically goes high (this only affects timer 2).
Mode 3: Square Wave. This generates a high / low square wave. The count
determines the length of the pulse, which alternates between high and low
when zero is reached. The count only proceeds when gate is high and is
automatically reloaded on reaching zero. The count is decremented twice at
each clock to generate a full high / low cycle at the full periodic rate.
If the count is even, the clock remains high for N/2 counts and low for N/2
counts; if the clock is odd, the clock is high for (N+1)/2 counts and low
for (N-1)/2 counts. Only even values are latched by the counter, so odd
values are not observed when reading. This is the intended mode for timer 2,
which generates sine-like tones by low-pass filtering the square wave output.
Mode 4: Software Strobe. After programming this mode and loading the counter,
the output remains high until the counter reaches zero. Then the output
goes low for 1 clock cycle and returns high. The counter is not reloaded.
Counting only occurs when gate is high.
Mode 5: Hardware Strobe. After programming and loading the counter, the
output remains high. When the gate is raised, a countdown is initiated
(which does not stop if the gate is lowered). When the counter reaches zero,
the output goes low for 1 clock cycle and then returns high. The counter is
not reloaded.
In addition to normal binary counting, the PIT supports BCD counting. The
command port, 0x43 is used to set the counter and mode for each of the three
timers.
PIT commands, issued to port 0x43, using the following bit encoding:
Bit 7-4: Command (See table below)
Bit 3-1: Mode (000 = Mode 0, 101 = Mode 5, 11X = undefined)
Bit 0 : Binary (0) / BCD (1)
Command table:
0000 - Latch Timer 0 count for port 0x40
sample and hold the count to be read in port 0x40;
additional commands ignored until counter is read;
mode bits ignored.
0001 - Set Timer 0 LSB mode for port 0x40
set timer to read LSB only and force MSB to zero;
mode bits set timer mode
0010 - Set Timer 0 MSB mode for port 0x40
set timer to read MSB only and force LSB to zero;
mode bits set timer mode
0011 - Set Timer 0 16-bit mode for port 0x40
set timer to read / write LSB first, then MSB;
mode bits set timer mode
0100 - Latch Timer 1 count for port 0x41 - as described above
0101 - Set Timer 1 LSB mode for port 0x41 - as described above
0110 - Set Timer 1 MSB mode for port 0x41 - as described above
0111 - Set Timer 1 16-bit mode for port 0x41 - as described above
1000 - Latch Timer 2 count for port 0x42 - as described above
1001 - Set Timer 2 LSB mode for port 0x42 - as described above
1010 - Set Timer 2 MSB mode for port 0x42 - as described above
1011 - Set Timer 2 16-bit mode for port 0x42 as described above
1101 - General counter latch
Latch combination of counters into corresponding ports
Bit 3 = Counter 2
Bit 2 = Counter 1
Bit 1 = Counter 0
Bit 0 = Unused
1110 - Latch timer status
Latch combination of counter mode into corresponding ports
Bit 3 = Counter 2
Bit 2 = Counter 1
Bit 1 = Counter 0
The output of ports 0x40-0x42 following this command will be:
Bit 7 = Output pin
Bit 6 = Count loaded (0 if timer has expired)
Bit 5-4 = Read / Write mode
01 = MSB only
10 = LSB only
11 = LSB / MSB (16-bit)
Bit 3-1 = Mode
Bit 0 = Binary (0) / BCD mode (1)
2.2) RTC
The second device which was available in the original PC was the MC146818 real
time clock. The original device is now obsolete, and usually emulated by the
system chipset, sometimes by an HPET and some frankenstein IRQ routing.
The RTC is accessed through CMOS variables, which uses an index register to
control which bytes are read. Since there is only one index register, read
of the CMOS and read of the RTC require lock protection (in addition, it is
dangerous to allow userspace utilities such as hwclock to have direct RTC
access, as they could corrupt kernel reads and writes of CMOS memory).
The RTC generates an interrupt which is usually routed to IRQ 8. The interrupt
can function as a periodic timer, an additional once a day alarm, and can issue
interrupts after an update of the CMOS registers by the MC146818 is complete.
The type of interrupt is signalled in the RTC status registers.
The RTC will update the current time fields by battery power even while the
system is off. The current time fields should not be read while an update is
in progress, as indicated in the status register.
The clock uses a 32.768kHz crystal, so bits 6-4 of register A should be
programmed to a 32kHz divider if the RTC is to count seconds.
This is the RAM map originally used for the RTC/CMOS:
Location Size Description
------------------------------------------
00h byte Current second (BCD)
01h byte Seconds alarm (BCD)
02h byte Current minute (BCD)
03h byte Minutes alarm (BCD)
04h byte Current hour (BCD)
05h byte Hours alarm (BCD)
06h byte Current day of week (BCD)
07h byte Current day of month (BCD)
08h byte Current month (BCD)
09h byte Current year (BCD)
0Ah byte Register A
bit 7 = Update in progress
bit 6-4 = Divider for clock
000 = 4.194 MHz
001 = 1.049 MHz
010 = 32 kHz
10X = test modes
110 = reset / disable
111 = reset / disable
bit 3-0 = Rate selection for periodic interrupt
000 = periodic timer disabled
001 = 3.90625 uS
010 = 7.8125 uS
011 = .122070 mS
100 = .244141 mS
...
1101 = 125 mS
1110 = 250 mS
1111 = 500 mS
0Bh byte Register B
bit 7 = Run (0) / Halt (1)
bit 6 = Periodic interrupt enable
bit 5 = Alarm interrupt enable
bit 4 = Update-ended interrupt enable
bit 3 = Square wave interrupt enable
bit 2 = BCD calendar (0) / Binary (1)
bit 1 = 12-hour mode (0) / 24-hour mode (1)
bit 0 = 0 (DST off) / 1 (DST enabled)
OCh byte Register C (read only)
bit 7 = interrupt request flag (IRQF)
bit 6 = periodic interrupt flag (PF)
bit 5 = alarm interrupt flag (AF)
bit 4 = update interrupt flag (UF)
bit 3-0 = reserved
ODh byte Register D (read only)
bit 7 = RTC has power
bit 6-0 = reserved
32h byte Current century BCD (*)
(*) location vendor specific and now determined from ACPI global tables
2.3) APIC
On Pentium and later processors, an on-board timer is available to each CPU
as part of the Advanced Programmable Interrupt Controller. The APIC is
accessed through memory-mapped registers and provides interrupt service to each
CPU, used for IPIs and local timer interrupts.
Although in theory the APIC is a safe and stable source for local interrupts,
in practice, many bugs and glitches have occurred due to the special nature of
the APIC CPU-local memory-mapped hardware. Beware that CPU errata may affect
the use of the APIC and that workarounds may be required. In addition, some of
these workarounds pose unique constraints for virtualization - requiring either
extra overhead incurred from extra reads of memory-mapped I/O or additional
functionality that may be more computationally expensive to implement.
Since the APIC is documented quite well in the Intel and AMD manuals, we will
avoid repetition of the detail here. It should be pointed out that the APIC
timer is programmed through the LVT (local vector timer) register, is capable
of one-shot or periodic operation, and is based on the bus clock divided down
by the programmable divider register.
2.4) HPET
HPET is quite complex, and was originally intended to replace the PIT / RTC
support of the X86 PC. It remains to be seen whether that will be the case, as
the de facto standard of PC hardware is to emulate these older devices. Some
systems designated as legacy free may support only the HPET as a hardware timer
device.
The HPET spec is rather loose and vague, requiring at least 3 hardware timers,
but allowing implementation freedom to support many more. It also imposes no
fixed rate on the timer frequency, but does impose some extremal values on
frequency, error and slew.
In general, the HPET is recommended as a high precision (compared to PIT /RTC)
time source which is independent of local variation (as there is only one HPET
in any given system). The HPET is also memory-mapped, and its presence is
indicated through ACPI tables by the BIOS.
Detailed specification of the HPET is beyond the current scope of this
document, as it is also very well documented elsewhere.
2.5) Offboard Timers
Several cards, both proprietary (watchdog boards) and commonplace (e1000) have
timing chips built into the cards which may have registers which are accessible
to kernel or user drivers. To the author's knowledge, using these to generate
a clocksource for a Linux or other kernel has not yet been attempted and is in
general frowned upon as not playing by the agreed rules of the game. Such a
timer device would require additional support to be virtualized properly and is
not considered important at this time as no known operating system does this.
=========================================================================
3) TSC Hardware
The TSC or time stamp counter is relatively simple in theory; it counts
instruction cycles issued by the processor, which can be used as a measure of
time. In practice, due to a number of problems, it is the most complicated
timekeeping device to use.
The TSC is represented internally as a 64-bit MSR which can be read with the
RDMSR, RDTSC, or RDTSCP (when available) instructions. In the past, hardware
limitations made it possible to write the TSC, but generally on old hardware it
was only possible to write the low 32-bits of the 64-bit counter, and the upper
32-bits of the counter were cleared. Now, however, on Intel processors family
0Fh, for models 3, 4 and 6, and family 06h, models e and f, this restriction
has been lifted and all 64-bits are writable. On AMD systems, the ability to
write the TSC MSR is not an architectural guarantee.
The TSC is accessible from CPL-0 and conditionally, for CPL > 0 software by
means of the CR4.TSD bit, which when enabled, disables CPL > 0 TSC access.
Some vendors have implemented an additional instruction, RDTSCP, which returns
atomically not just the TSC, but an indicator which corresponds to the
processor number. This can be used to index into an array of TSC variables to
determine offset information in SMP systems where TSCs are not synchronized.
The presence of this instruction must be determined by consulting CPUID feature
bits.
Both VMX and SVM provide extension fields in the virtualization hardware which
allows the guest visible TSC to be offset by a constant. Newer implementations
promise to allow the TSC to additionally be scaled, but this hardware is not
yet widely available.
3.1) TSC synchronization
The TSC is a CPU-local clock in most implementations. This means, on SMP
platforms, the TSCs of different CPUs may start at different times depending
on when the CPUs are powered on. Generally, CPUs on the same die will share
the same clock, however, this is not always the case.
The BIOS may attempt to resynchronize the TSCs during the poweron process and
the operating system or other system software may attempt to do this as well.
Several hardware limitations make the problem worse - if it is not possible to
write the full 64-bits of the TSC, it may be impossible to match the TSC in
newly arriving CPUs to that of the rest of the system, resulting in
unsynchronized TSCs. This may be done by BIOS or system software, but in
practice, getting a perfectly synchronized TSC will not be possible unless all
values are read from the same clock, which generally only is possible on single
socket systems or those with special hardware support.
3.2) TSC and CPU hotplug
As touched on already, CPUs which arrive later than the boot time of the system
may not have a TSC value that is synchronized with the rest of the system.
Either system software, BIOS, or SMM code may actually try to establish the TSC
to a value matching the rest of the system, but a perfect match is usually not
a guarantee. This can have the effect of bringing a system from a state where
TSC is synchronized back to a state where TSC synchronization flaws, however
small, may be exposed to the OS and any virtualization environment.
3.3) TSC and multi-socket / NUMA
Multi-socket systems, especially large multi-socket systems are likely to have
individual clocksources rather than a single, universally distributed clock.
Since these clocks are driven by different crystals, they will not have
perfectly matched frequency, and temperature and electrical variations will
cause the CPU clocks, and thus the TSCs to drift over time. Depending on the
exact clock and bus design, the drift may or may not be fixed in absolute
error, and may accumulate over time.
In addition, very large systems may deliberately slew the clocks of individual
cores. This technique, known as spread-spectrum clocking, reduces EMI at the
clock frequency and harmonics of it, which may be required to pass FCC
standards for telecommunications and computer equipment.
It is recommended not to trust the TSCs to remain synchronized on NUMA or
multiple socket systems for these reasons.
3.4) TSC and C-states
C-states, or idling states of the processor, especially C1E and deeper sleep
states may be problematic for TSC as well. The TSC may stop advancing in such
a state, resulting in a TSC which is behind that of other CPUs when execution
is resumed. Such CPUs must be detected and flagged by the operating system
based on CPU and chipset identifications.
The TSC in such a case may be corrected by catching it up to a known external
clocksource.
3.5) TSC frequency change / P-states
To make things slightly more interesting, some CPUs may change frequency. They
may or may not run the TSC at the same rate, and because the frequency change
may be staggered or slewed, at some points in time, the TSC rate may not be
known other than falling within a range of values. In this case, the TSC will
not be a stable time source, and must be calibrated against a known, stable,
external clock to be a usable source of time.
Whether the TSC runs at a constant rate or scales with the P-state is model
dependent and must be determined by inspecting CPUID, chipset or vendor
specific MSR fields.
In addition, some vendors have known bugs where the P-state is actually
compensated for properly during normal operation, but when the processor is
inactive, the P-state may be raised temporarily to service cache misses from
other processors. In such cases, the TSC on halted CPUs could advance faster
than that of non-halted processors. AMD Turion processors are known to have
this problem.
3.6) TSC and STPCLK / T-states
External signals given to the processor may also have the effect of stopping
the TSC. This is typically done for thermal emergency power control to prevent
an overheating condition, and typically, there is no way to detect that this
condition has happened.
3.7) TSC virtualization - VMX
VMX provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP
instructions, which is enough for full virtualization of TSC in any manner. In
addition, VMX allows passing through the host TSC plus an additional TSC_OFFSET
field specified in the VMCS. Special instructions must be used to read and
write the VMCS field.
3.8) TSC virtualization - SVM
SVM provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP
instructions, which is enough for full virtualization of TSC in any manner. In
addition, SVM allows passing through the host TSC plus an additional offset
field specified in the SVM control block.
3.9) TSC feature bits in Linux
In summary, there is no way to guarantee the TSC remains in perfect
synchronization unless it is explicitly guaranteed by the architecture. Even
if so, the TSCs in multi-sockets or NUMA systems may still run independently
despite being locally consistent.
The following feature bits are used by Linux to signal various TSC attributes,
but they can only be taken to be meaningful for UP or single node systems.
X86_FEATURE_TSC : The TSC is available in hardware
X86_FEATURE_RDTSCP : The RDTSCP instruction is available
X86_FEATURE_CONSTANT_TSC : The TSC rate is unchanged with P-states
X86_FEATURE_NONSTOP_TSC : The TSC does not stop in C-states
X86_FEATURE_TSC_RELIABLE : TSC sync checks are skipped (VMware)
4) Virtualization Problems
Timekeeping is especially problematic for virtualization because a number of
challenges arise. The most obvious problem is that time is now shared between
the host and, potentially, a number of virtual machines. Thus the virtual
operating system does not run with 100% usage of the CPU, despite the fact that
it may very well make that assumption. It may expect it to remain true to very
exacting bounds when interrupt sources are disabled, but in reality only its
virtual interrupt sources are disabled, and the machine may still be preempted
at any time. This causes problems as the passage of real time, the injection
of machine interrupts and the associated clock sources are no longer completely
synchronized with real time.
This same problem can occur on native harware to a degree, as SMM mode may
steal cycles from the naturally on X86 systems when SMM mode is used by the
BIOS, but not in such an extreme fashion. However, the fact that SMM mode may
cause similar problems to virtualization makes it a good justification for
solving many of these problems on bare metal.
4.1) Interrupt clocking
One of the most immediate problems that occurs with legacy operating systems
is that the system timekeeping routines are often designed to keep track of
time by counting periodic interrupts. These interrupts may come from the PIT
or the RTC, but the problem is the same: the host virtualization engine may not
be able to deliver the proper number of interrupts per second, and so guest
time may fall behind. This is especially problematic if a high interrupt rate
is selected, such as 1000 HZ, which is unfortunately the default for many Linux
guests.
There are three approaches to solving this problem; first, it may be possible
to simply ignore it. Guests which have a separate time source for tracking
'wall clock' or 'real time' may not need any adjustment of their interrupts to
maintain proper time. If this is not sufficient, it may be necessary to inject
additional interrupts into the guest in order to increase the effective
interrupt rate. This approach leads to complications in extreme conditions,
where host load or guest lag is too much to compensate for, and thus another
solution to the problem has risen: the guest may need to become aware of lost
ticks and compensate for them internally. Although promising in theory, the
implementation of this policy in Linux has been extremely error prone, and a
number of buggy variants of lost tick compensation are distributed across
commonly used Linux systems.
Windows uses periodic RTC clocking as a means of keeping time internally, and
thus requires interrupt slewing to keep proper time. It does use a low enough
rate (ed: is it 18.2 Hz?) however that it has not yet been a problem in
practice.
4.2) TSC sampling and serialization
As the highest precision time source available, the cycle counter of the CPU
has aroused much interest from developers. As explained above, this timer has
many problems unique to its nature as a local, potentially unstable and
potentially unsynchronized source. One issue which is not unique to the TSC,
but is highlighted because of its very precise nature is sampling delay. By
definition, the counter, once read is already old. However, it is also
possible for the counter to be read ahead of the actual use of the result.
This is a consequence of the superscalar execution of the instruction stream,
which may execute instructions out of order. Such execution is called
non-serialized. Forcing serialized execution is necessary for precise
measurement with the TSC, and requires a serializing instruction, such as CPUID
or an MSR read.
Since CPUID may actually be virtualized by a trap and emulate mechanism, this
serialization can pose a performance issue for hardware virtualization. An
accurate time stamp counter reading may therefore not always be available, and
it may be necessary for an implementation to guard against "backwards" reads of
the TSC as seen from other CPUs, even in an otherwise perfectly synchronized
system.
4.3) Timespec aliasing
Additionally, this lack of serialization from the TSC poses another challenge
when using results of the TSC when measured against another time source. As
the TSC is much higher precision, many possible values of the TSC may be read
while another clock is still expressing the same value.
That is, you may read (T,T+10) while external clock C maintains the same value.
Due to non-serialized reads, you may actually end up with a range which
fluctuates - from (T-1.. T+10). Thus, any time calculated from a TSC, but
calibrated against an external value may have a range of valid values.
Re-calibrating this computation may actually cause time, as computed after the
calibration, to go backwards, compared with time computed before the
calibration.
This problem is particularly pronounced with an internal time source in Linux,
the kernel time, which is expressed in the theoretically high resolution
timespec - but which advances in much larger granularity intervals, sometimes
at the rate of jiffies, and possibly in catchup modes, at a much larger step.
This aliasing requires care in the computation and recalibration of kvmclock
and any other values derived from TSC computation (such as TSC virtualization
itself).
4.4) Migration
Migration of a virtual machine raises problems for timekeeping in two ways.
First, the migration itself may take time, during which interrupts cannot be
delivered, and after which, the guest time may need to be caught up. NTP may
be able to help to some degree here, as the clock correction required is
typically small enough to fall in the NTP-correctable window.
An additional concern is that timers based off the TSC (or HPET, if the raw bus
clock is exposed) may now be running at different rates, requiring compensation
in some way in the hypervisor by virtualizing these timers. In addition,
migrating to a faster machine may preclude the use of a passthrough TSC, as a
faster clock cannot be made visible to a guest without the potential of time
advancing faster than usual. A slower clock is less of a problem, as it can
always be caught up to the original rate. KVM clock avoids these problems by
simply storing multipliers and offsets against the TSC for the guest to convert
back into nanosecond resolution values.
4.5) Scheduling
Since scheduling may be based on precise timing and firing of interrupts, the
scheduling algorithms of an operating system may be adversely affected by
virtualization. In theory, the effect is random and should be universally
distributed, but in contrived as well as real scenarios (guest device access,
causes of virtualization exits, possible context switch), this may not always
be the case. The effect of this has not been well studied.
In an attempt to work around this, several implementations have provided a
paravirtualized scheduler clock, which reveals the true amount of CPU time for
which a virtual machine has been running.
4.6) Watchdogs
Watchdog timers, such as the lock detector in Linux may fire accidentally when
running under hardware virtualization due to timer interrupts being delayed or
misinterpretation of the passage of real time. Usually, these warnings are
spurious and can be ignored, but in some circumstances it may be necessary to
disable such detection.
4.7) Delays and precision timing
Precise timing and delays may not be possible in a virtualized system. This
can happen if the system is controlling physical hardware, or issues delays to
compensate for slower I/O to and from devices. The first issue is not solvable
in general for a virtualized system; hardware control software can't be
adequately virtualized without a full real-time operating system, which would
require an RT aware virtualization platform.
The second issue may cause performance problems, but this is unlikely to be a
significant issue. In many cases these delays may be eliminated through
configuration or paravirtualization.
4.8) Covert channels and leaks
In addition to the above problems, time information will inevitably leak to the
guest about the host in anything but a perfect implementation of virtualized
time. This may allow the guest to infer the presence of a hypervisor (as in a
red-pill type detection), and it may allow information to leak between guests
by using CPU utilization itself as a signalling channel. Preventing such
problems would require completely isolated virtual time which may not track
real time any longer. This may be useful in certain security or QA contexts,
but in general isn't recommended for real-world deployment scenarios.

19
Documentation/leds-class.txt
View File

@@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs
Some LEDs can be programmed to blink without any CPU interaction. To Some LEDs can be programmed to blink without any CPU interaction. To
support this feature, a LED driver can optionally implement the support this feature, a LED driver can optionally implement the
blink_set() function (see <linux/leds.h>). If implemented, triggers can blink_set() function (see <linux/leds.h>). To set an LED to blinking,
attempt to use it before falling back to software timers. The blink_set() however, it is better to use use the API function led_blink_set(),
function should return 0 if the blink setting is supported, or -EINVAL as it will check and implement software fallback if necessary.
otherwise, which means that LED blinking will be handled by software.
The blink_set() function should choose a user friendly blinking To turn off blinking again, use the API function led_brightness_set()
value if it is called with *delay_on==0 && *delay_off==0 parameters. In as that will not just set the LED brightness but also stop any software
this case the driver should give back the chosen value through delay_on timers that may have been required for blinking.
and delay_off parameters to the leds subsystem.
The blink_set() function should choose a user friendly blinking value
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
case the driver should give back the chosen value through delay_on and
delay_off parameters to the leds subsystem.
Setting the brightness to zero with brightness_set() callback function Setting the brightness to zero with brightness_set() callback function
should completely turn off the LED and cancel the previously programmed should completely turn off the LED and cancel the previously programmed

88
Documentation/leds/leds-lp5521.txt Normal file
View File

@@ -0,0 +1,88 @@
Kernel driver for lp5521
========================
* National Semiconductor LP5521 led driver chip
* Datasheet: http://www.national.com/pf/LP/LP5521.html
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
Description
-----------
LP5521 can drive up to 3 channels. Leds can be controlled directly via
the led class control interface. Channels have generic names:
lp5521:channelx, where x is 0 .. 2
All three channels can be also controlled using the engine micro programs.
More details of the instructions can be found from the public data sheet.
Control interface for the engines:
x is 1 .. 3
enginex_mode : disabled, load, run
enginex_load : store program (visible only in engine load mode)
Example (start to blink the channel 2 led):
cd /sys/class/leds/lp5521:channel2/device
echo "load" > engine3_mode
echo "037f4d0003ff6000" > engine3_load
echo "run" > engine3_mode
stop the engine:
echo "disabled" > engine3_mode
sysfs contains a selftest entry.
The test communicates with the chip and checks that
the clock mode is automatically set to the requested one.
Each channel has its own led current settings.
/sys/class/leds/lp5521:channel0/led_current - RW
/sys/class/leds/lp5521:channel0/max_current - RO
Format: 10x mA i.e 10 means 1.0 mA
example platform data:
Note: chan_nr can have values between 0 and 2.
static struct lp5521_led_config lp5521_led_config[] = {
{
.chan_nr = 0,
.led_current = 50,
.max_current = 130,
}, {
.chan_nr = 1,
.led_current = 0,
.max_current = 130,
}, {
.chan_nr = 2,
.led_current = 0,
.max_current = 130,
}
};
static int lp5521_setup(void)
{
/* setup HW resources */
}
static void lp5521_release(void)
{
/* Release HW resources */
}
static void lp5521_enable(bool state)
{
/* Control of chip enable signal */
}
static struct lp5521_platform_data lp5521_platform_data = {
.led_config = lp5521_led_config,
.num_channels = ARRAY_SIZE(lp5521_led_config),
.clock_mode = LP5521_CLOCK_EXT,
.setup_resources = lp5521_setup,
.release_resources = lp5521_release,
.enable = lp5521_enable,
};
If the current is set to 0 in the platform data, that channel is
disabled and it is not visible in the sysfs.

83
Documentation/leds/leds-lp5523.txt Normal file
View File

@@ -0,0 +1,83 @@
Kernel driver for lp5523
========================
* National Semiconductor LP5523 led driver chip
* Datasheet: http://www.national.com/pf/LP/LP5523.html
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
Description
-----------
LP5523 can drive up to 9 channels. Leds can be controlled directly via
the led class control interface. Channels have generic names:
lp5523:channelx where x is 0...8
The chip provides 3 engines. Each engine can control channels without
interaction from the main CPU. Details of the micro engine code can be found
from the public data sheet. Leds can be muxed to different channels.
Control interface for the engines:
x is 1 .. 3
enginex_mode : disabled, load, run
enginex_load : microcode load (visible only in load mode)
enginex_leds : led mux control (visible only in load mode)
cd /sys/class/leds/lp5523:channel2/device
echo "load" > engine3_mode
echo "9d80400004ff05ff437f0000" > engine3_load
echo "111111111" > engine3_leds
echo "run" > engine3_mode
sysfs contains a selftest entry. It measures each channel
voltage level and checks if it looks reasonable. If the level is too high,
the led is missing; if the level is too low, there is a short circuit.
Selftest uses always the current from the platform data.
Each channel contains led current settings.
/sys/class/leds/lp5523:channel2/led_current - RW
/sys/class/leds/lp5523:channel2/max_current - RO
Format: 10x mA i.e 10 means 1.0 mA
Example platform data:
Note - chan_nr can have values between 0 and 8.
static struct lp5523_led_config lp5523_led_config[] = {
{
.chan_nr = 0,
.led_current = 50,
.max_current = 130,
},
...
}, {
.chan_nr = 8,
.led_current = 50,
.max_current = 130,
}
};
static int lp5523_setup(void)
{
/* Setup HW resources */
}
static void lp5523_release(void)
{
/* Release HW resources */
}
static void lp5523_enable(bool state)
{
/* Control chip enable signal */
}
static struct lp5523_platform_data lp5523_platform_data = {
.led_config = lp5523_led_config,
.num_channels = ARRAY_SIZE(lp5523_led_config),
.clock_mode = LP5523_CLOCK_EXT,
.setup_resources = lp5523_setup,
.release_resources = lp5523_release,
.enable = lp5523_enable,
};

29
Documentation/lguest/lguest.c
View File

@@ -1639,15 +1639,6 @@ static void blk_request(struct virtqueue *vq)
*/ */
off = out->sector * 512; off = out->sector * 512;
/*
* The block device implements "barriers", where the Guest indicates
* that it wants all previous writes to occur before this write. We
* don't have a way of asking our kernel to do a barrier, so we just
* synchronize all the data in the file. Pretty poor, no?
*/
if (out->type & VIRTIO_BLK_T_BARRIER)
fdatasync(vblk->fd);
/* /*
* In general the virtio block driver is allowed to try SCSI commands. * In general the virtio block driver is allowed to try SCSI commands.
* It'd be nice if we supported eject, for example, but we don't. * It'd be nice if we supported eject, for example, but we don't.
@@ -1680,6 +1671,13 @@ static void blk_request(struct virtqueue *vq)
/* Die, bad Guest, die. */ /* Die, bad Guest, die. */
errx(1, "Write past end %llu+%u", off, ret); errx(1, "Write past end %llu+%u", off, ret);
} }
wlen = sizeof(*in);
*in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
} else if (out->type & VIRTIO_BLK_T_FLUSH) {
/* Flush */
ret = fdatasync(vblk->fd);
verbose("FLUSH fdatasync: %i\n", ret);
wlen = sizeof(*in); wlen = sizeof(*in);
*in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR); *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
} else { } else {
@@ -1703,15 +1701,6 @@ static void blk_request(struct virtqueue *vq)
} }
} }
/*
* OK, so we noted that it was pretty poor to use an fdatasync as a
* barrier. But Christoph Hellwig points out that we need a sync
* *afterwards* as well: "Barriers specify no reordering to the front
* or the back." And Jens Axboe confirmed it, so here we are:
*/
if (out->type & VIRTIO_BLK_T_BARRIER)
fdatasync(vblk->fd);
/* Finished that request. */ /* Finished that request. */
add_used(vq, head, wlen); add_used(vq, head, wlen);
} }
@@ -1736,8 +1725,8 @@ static void setup_block_file(const char *filename)
vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE); vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE);
vblk->len = lseek64(vblk->fd, 0, SEEK_END); vblk->len = lseek64(vblk->fd, 0, SEEK_END);
/* We support barriers. */ /* We support FLUSH. */
add_feature(dev, VIRTIO_BLK_F_BARRIER); add_feature(dev, VIRTIO_BLK_F_FLUSH);
/* Tell Guest how many sectors this device has. */ /* Tell Guest how many sectors this device has. */
conf.capacity = cpu_to_le64(vblk->len / 512); conf.capacity = cpu_to_le64(vblk->len / 512);

111
Documentation/misc-devices/apds990x.txt Normal file
View File

@@ -0,0 +1,111 @@
Kernel driver apds990x
======================
Supported chips:
Avago APDS990X
Data sheet:
Not freely available
Author:
Samu Onkalo <samu.p.onkalo@nokia.com>
Description
-----------
APDS990x is a combined ambient light and proximity sensor. ALS and proximity
functionality are highly connected. ALS measurement path must be running
while the proximity functionality is enabled.
ALS produces raw measurement values for two channels: Clear channel
(infrared + visible light) and IR only. However, threshold comparisons happen
using clear channel only. Lux value and the threshold level on the HW
might vary quite much depending the spectrum of the light source.
Driver makes necessary conversions to both directions so that user handles
only lux values. Lux value is calculated using information from the both
channels. HW threshold level is calculated from the given lux value to match
with current type of the lightning. Sometimes inaccuracy of the estimations
lead to false interrupt, but that doesn't harm.
ALS contains 4 different gain steps. Driver automatically
selects suitable gain step. After each measurement, reliability of the results
is estimated and new measurement is trigged if necessary.
Platform data can provide tuned values to the conversion formulas if
values are known. Otherwise plain sensor default values are used.
Proximity side is little bit simpler. There is no need for complex conversions.
It produces directly usable values.
Driver controls chip operational state using pm_runtime framework.
Voltage regulators are controlled based on chip operational state.
SYSFS
-----
chip_id
RO - shows detected chip type and version
power_state
RW - enable / disable chip. Uses counting logic
1 enables the chip
0 disables the chip
lux0_input
RO - measured lux value
sysfs_notify called when threshold interrupt occurs
lux0_sensor_range
RO - lux0_input max value. Actually never reaches since sensor tends
to saturate much before that. Real max value varies depending
on the light spectrum etc.
lux0_rate
RW - measurement rate in Hz
lux0_rate_avail
RO - supported measurement rates
lux0_calibscale
RW - calibration value. Set to neutral value by default.
Output results are multiplied with calibscale / calibscale_default
value.
lux0_calibscale_default
RO - neutral calibration value
lux0_thresh_above_value
RW - HI level threshold value. All results above the value
trigs an interrupt. 65535 (i.e. sensor_range) disables the above
interrupt.
lux0_thresh_below_value
RW - LO level threshold value. All results below the value
trigs an interrupt. 0 disables the below interrupt.
prox0_raw
RO - measured proximity value
sysfs_notify called when threshold interrupt occurs
prox0_sensor_range
RO - prox0_raw max value (1023)
prox0_raw_en
RW - enable / disable proximity - uses counting logic
1 enables the proximity
0 disables the proximity
prox0_reporting_mode
RW - trigger / periodic. In "trigger" mode the driver tells two possible
values: 0 or prox0_sensor_range value. 0 means no proximity,
1023 means proximity. This causes minimal number of interrupts.
In "periodic" mode the driver reports all values above
prox0_thresh_above. This causes more interrupts, but it can give
_rough_ estimate about the distance.
prox0_reporting_mode_avail
RO - accepted values to prox0_reporting_mode (trigger, periodic)
prox0_thresh_above_value
RW - threshold level which trigs proximity events.

116
Documentation/misc-devices/bh1770glc.txt Normal file
View File

@@ -0,0 +1,116 @@
Kernel driver bh1770glc
=======================
Supported chips:
ROHM BH1770GLC
OSRAM SFH7770
Data sheet:
Not freely available
Author:
Samu Onkalo <samu.p.onkalo@nokia.com>
Description
-----------
BH1770GLC and SFH7770 are combined ambient light and proximity sensors.
ALS and proximity parts operates on their own, but they shares common I2C
interface and interrupt logic. In principle they can run on their own,
but ALS side results are used to estimate reliability of the proximity sensor.
ALS produces 16 bit lux values. The chip contains interrupt logic to produce
low and high threshold interrupts.
Proximity part contains IR-led driver up to 3 IR leds. The chip measures
amount of reflected IR light and produces proximity result. Resolution is
8 bit. Driver supports only one channel. Driver uses ALS results to estimate
reliability of the proximity results. Thus ALS is always running while
proximity detection is needed.
Driver uses threshold interrupts to avoid need for polling the values.
Proximity low interrupt doesn't exists in the chip. This is simulated
by using a delayed work. As long as there is proximity threshold above
interrupts the delayed work is pushed forward. So, when proximity level goes
below the threshold value, there is no interrupt and the delayed work will
finally run. This is handled as no proximity indication.
Chip state is controlled via runtime pm framework when enabled in config.
Calibscale factor is used to hide differences between the chips. By default
value set to neutral state meaning factor of 1.00. To get proper values,
calibrated source of light is needed as a reference. Calibscale factor is set
so that measurement produces about the expected lux value.
SYSFS
-----
chip_id
RO - shows detected chip type and version
power_state
RW - enable / disable chip. Uses counting logic
1 enables the chip
0 disables the chip
lux0_input
RO - measured lux value
sysfs_notify called when threshold interrupt occurs
lux0_sensor_range
RO - lux0_input max value
lux0_rate
RW - measurement rate in Hz
lux0_rate_avail
RO - supported measurement rates
lux0_thresh_above_value
RW - HI level threshold value. All results above the value
trigs an interrupt. 65535 (i.e. sensor_range) disables the above
interrupt.
lux0_thresh_below_value
RW - LO level threshold value. All results below the value
trigs an interrupt. 0 disables the below interrupt.
lux0_calibscale
RW - calibration value. Set to neutral value by default.
Output results are multiplied with calibscale / calibscale_default
value.
lux0_calibscale_default
RO - neutral calibration value
prox0_raw
RO - measured proximity value
sysfs_notify called when threshold interrupt occurs
prox0_sensor_range
RO - prox0_raw max value
prox0_raw_en
RW - enable / disable proximity - uses counting logic
1 enables the proximity
0 disables the proximity
prox0_thresh_above_count
RW - number of proximity interrupts needed before triggering the event
prox0_rate_above
RW - Measurement rate (in Hz) when the level is above threshold
i.e. when proximity on has been reported.
prox0_rate_below
RW - Measurement rate (in Hz) when the level is below threshold
i.e. when proximity off has been reported.
prox0_rate_avail
RO - Supported proximity measurement rates in Hz
prox0_thresh_above0_value
RW - threshold level which trigs proximity events.
Filtered by persistence filter (prox0_thresh_above_count)
prox0_thresh_above1_value
RW - threshold level which trigs event immediately

8
Documentation/networking/bonding.txt
View File

@@ -765,6 +765,14 @@ xmit_hash_policy
does not exist, and the layer2 policy is the only policy. The does not exist, and the layer2 policy is the only policy. The
layer2+3 value was added for bonding version 3.2.2. layer2+3 value was added for bonding version 3.2.2.
resend_igmp
Specifies the number of IGMP membership reports to be issued after
a failover event. One membership report is issued immediately after
the failover, subsequent packets are sent in each 200ms interval.
The valid range is 0 - 255; the default value is 1. This option
was added for bonding version 3.7.0.
3. Configuring Bonding Devices 3. Configuring Bonding Devices
============================== ==============================

12
Documentation/networking/can.txt
View File

@@ -22,6 +22,7 @@ This file contains
4.1.2 RAW socket option CAN_RAW_ERR_FILTER 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
4.1.3 RAW socket option CAN_RAW_LOOPBACK 4.1.3 RAW socket option CAN_RAW_LOOPBACK
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
4.1.5 RAW socket returned message flags
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET) 4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM) 4.4 unconnected transport protocols (SOCK_DGRAM)
@@ -471,6 +472,17 @@ solution for a couple of reasons:
setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
&recv_own_msgs, sizeof(recv_own_msgs)); &recv_own_msgs, sizeof(recv_own_msgs));
4.1.5 RAW socket returned message flags
When using recvmsg() call, the msg->msg_flags may contain following flags:
MSG_DONTROUTE: set when the received frame was created on the local host.
MSG_CONFIRM: set when the frame was sent via the socket it is received on.
This flag can be interpreted as a 'transmission confirmation' when the
CAN driver supports the echo of frames on driver level, see 3.2 and 6.2.
In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET) 4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM) 4.4 unconnected transport protocols (SOCK_DGRAM)

29
Documentation/networking/dccp.txt
View File

@@ -1,18 +1,20 @@
DCCP protocol DCCP protocol
============ =============
Contents Contents
======== ========
- Introduction - Introduction
- Missing features - Missing features
- Socket options - Socket options
- Sysctl variables
- IOCTLs
- Other tunables
- Notes - Notes
Introduction Introduction
============ ============
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
oriented protocol designed to solve issues present in UDP and TCP, particularly oriented protocol designed to solve issues present in UDP and TCP, particularly
for real-time and multimedia (streaming) traffic. for real-time and multimedia (streaming) traffic.
@@ -29,9 +31,9 @@ It has a base protocol and pluggable congestion control IDs (CCIDs).
DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
is at http://www.ietf.org/html.charters/dccp-charter.html is at http://www.ietf.org/html.charters/dccp-charter.html
Missing features Missing features
================ ================
The Linux DCCP implementation does not currently support all the features that are The Linux DCCP implementation does not currently support all the features that are
specified in RFCs 4340...42. specified in RFCs 4340...42.
@@ -45,7 +47,6 @@ http://linux-net.osdl.org/index.php/DCCP_Testing#Experimental_DCCP_source_tree
Socket options Socket options
============== ==============
DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
the socket will fall back to 0 (which means that no meaningful service code the socket will fall back to 0 (which means that no meaningful service code
@@ -112,6 +113,7 @@ DCCP_SOCKOPT_CCID_TX_INFO
On unidirectional connections it is useful to close the unused half-connection On unidirectional connections it is useful to close the unused half-connection
via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs. via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs.
Sysctl variables Sysctl variables
================ ================
Several DCCP default parameters can be managed by the following sysctls Several DCCP default parameters can be managed by the following sysctls
@@ -155,15 +157,30 @@ sync_ratelimit = 125 ms
sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit
of this parameter is milliseconds; a value of 0 disables rate-limiting. of this parameter is milliseconds; a value of 0 disables rate-limiting.
IOCTLS IOCTLS
====== ======
FIONREAD FIONREAD
Works as in udp(7): returns in the `int' argument pointer the size of Works as in udp(7): returns in the `int' argument pointer the size of
the next pending datagram in bytes, or 0 when no datagram is pending. the next pending datagram in bytes, or 0 when no datagram is pending.
Other tunables
==============
Per-route rto_min support
CCID-2 supports the RTAX_RTO_MIN per-route setting for the minimum value
of the RTO timer. This setting can be modified via the 'rto_min' option
of iproute2; for example:
> ip route change 10.0.0.0/24 rto_min 250j dev wlan0
> ip route add 10.0.0.254/32 rto_min 800j dev wlan0
> ip route show dev wlan0
CCID-3 also supports the rto_min setting: it is used to define the lower
bound for the expiry of the nofeedback timer. This can be useful on LANs
with very low RTTs (e.g., loopback, Gbit ethernet).
Notes Notes
===== =====
DCCP does not travel through NAT successfully at present on many boxes. This is DCCP does not travel through NAT successfully at present on many boxes. This is
because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT
support for DCCP has been added. support for DCCP has been added.

36
Documentation/networking/ip-sysctl.txt
View File

@@ -20,6 +20,15 @@ ip_no_pmtu_disc - BOOLEAN
min_pmtu - INTEGER min_pmtu - INTEGER
default 562 - minimum discovered Path MTU default 562 - minimum discovered Path MTU
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
neigh/default/gc_thresh3 - INTEGER
Maximum number of neighbor entries allowed. Increase this
when using large numbers of interfaces and when communicating
with large numbers of directly-connected peers.
mtu_expires - INTEGER mtu_expires - INTEGER
Time, in seconds, that cached PMTU information is kept. Time, in seconds, that cached PMTU information is kept.
@@ -1014,6 +1023,12 @@ conf/interface/*:
accept_ra - BOOLEAN accept_ra - BOOLEAN
Accept Router Advertisements; autoconfigure using them. Accept Router Advertisements; autoconfigure using them.
Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.
Functional default: enabled if local forwarding is disabled. Functional default: enabled if local forwarding is disabled.
disabled if local forwarding is enabled. disabled if local forwarding is enabled.
@@ -1075,7 +1090,12 @@ forwarding - BOOLEAN
Note: It is recommended to have the same setting on all Note: It is recommended to have the same setting on all
interfaces; mixed router/host scenarios are rather uncommon. interfaces; mixed router/host scenarios are rather uncommon.
FALSE: Possible values are:
0 Forwarding disabled
1 Forwarding enabled
2 Forwarding enabled (Hybrid Mode)
FALSE (0):
By default, Host behaviour is assumed. This means: By default, Host behaviour is assumed. This means:
@@ -1085,18 +1105,24 @@ forwarding - BOOLEAN
Advertisements (and do autoconfiguration). Advertisements (and do autoconfiguration).
4. If accept_redirects is TRUE (default), accept Redirects. 4. If accept_redirects is TRUE (default), accept Redirects.
TRUE: TRUE (1):
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: This means exactly the reverse from the above:
1. IsRouter flag is set in Neighbour Advertisements. 1. IsRouter flag is set in Neighbour Advertisements.
2. Router Solicitations are not sent. 2. Router Solicitations are not sent.
3. Router Advertisements are ignored. 3. Router Advertisements are ignored unless accept_ra is 2.
4. Redirects are ignored. 4. Redirects are ignored.
Default: FALSE if global forwarding is disabled (default), TRUE (2):
otherwise TRUE.
Hybrid mode. Same behaviour as TRUE, except for:
2. Router Solicitations are being sent when necessary.
Default: 0 (disabled) if global forwarding is disabled (default),
otherwise 1 (enabled).
hop_limit - INTEGER hop_limit - INTEGER
Default Hop Limit to set. Default Hop Limit to set.

56
Documentation/networking/phonet.txt
View File

@@ -112,6 +112,22 @@ However, connect() and getpeername() are not supported, as they did
not seem useful with Phonet usages (could be added easily). not seem useful with Phonet usages (could be added easily).
Resource subscription
---------------------
A Phonet datagram socket can be subscribed to any number of 8-bits
Phonet resources, as follow:
uint32_t res = 0xXX;
ioctl(fd, SIOCPNADDRESOURCE, &res);
Subscription is similarly cancelled using the SIOCPNDELRESOURCE I/O
control request, or when the socket is closed.
Note that no more than one socket can be subcribed to any given
resource at a time. If not, ioctl() will return EBUSY.
Phonet Pipe protocol Phonet Pipe protocol
-------------------- --------------------
@@ -166,6 +182,46 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level:
or zero if encapsulation is off. or zero if encapsulation is off.
Phonet Pipe-controller Implementation
-------------------------------------
Phonet Pipe-controller is enabled by selecting the CONFIG_PHONET_PIPECTRLR Kconfig
option. It is useful when communicating with those Nokia Modems which do not
implement Pipe controller in them e.g. Nokia Slim Modem used in ST-Ericsson
U8500 platform.
The implementation is based on the Data Connection Establishment Sequence
depicted in 'Nokia Wireless Modem API - Wireless_modem_user_guide.pdf'
document.
It allows a phonet sequenced socket (host-pep) to initiate a Pipe connection
between itself and a remote pipe-end point (e.g. modem).
The implementation adds socket options at SOL_PNPIPE level:
PNPIPE_PIPE_HANDLE
It accepts an integer argument for setting value of pipe handle.
PNPIPE_ENABLE accepts one integer value (int). If set to zero, the pipe
is disabled. If the value is non-zero, the pipe is enabled. If the pipe
is not (yet) connected, ENOTCONN is error is returned.
The implementation also adds socket 'connect'. On calling the 'connect', pipe
will be created between the source socket and the destination, and the pipe
state will be set to PIPE_DISABLED.
After a pipe has been created and enabled successfully, the Pipe data can be
exchanged between the host-pep and remote-pep (modem).
User-space would typically follow below sequence with Pipe controller:-
-socket
-bind
-setsockopt for PNPIPE_PIPE_HANDLE
-connect
-setsockopt for PNPIPE_ENCAP_IP
-setsockopt for PNPIPE_ENABLE
Authors Authors
------- -------

18
Documentation/networking/phy.txt
View File

@@ -177,18 +177,6 @@ Doing it all yourself
A convenience function to print out the PHY status neatly. A convenience function to print out the PHY status neatly.
int phy_clear_interrupt(struct phy_device *phydev);
int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
Clear the PHY's interrupt, and configure which ones are allowed,
respectively. Currently only supports all on, or all off.
int phy_enable_interrupts(struct phy_device *phydev);
int phy_disable_interrupts(struct phy_device *phydev);
Functions which enable/disable PHY interrupts, clearing them
before and after, respectively.
int phy_start_interrupts(struct phy_device *phydev); int phy_start_interrupts(struct phy_device *phydev);
int phy_stop_interrupts(struct phy_device *phydev); int phy_stop_interrupts(struct phy_device *phydev);
@@ -213,12 +201,6 @@ Doing it all yourself
Fills the phydev structure with up-to-date information about the current Fills the phydev structure with up-to-date information about the current
settings in the PHY. settings in the PHY.
void phy_sanitize_settings(struct phy_device *phydev)
Resolves differences between currently desired settings, and
supported settings for the given PHY device. Does not make
the changes in the hardware, though.
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd); int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd); int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);

22
Documentation/networking/timestamping.txt
View File

@@ -172,15 +172,19 @@ struct skb_shared_hwtstamps {
}; };
Time stamps for outgoing packets are to be generated as follows: Time stamps for outgoing packets are to be generated as follows:
- In hard_start_xmit(), check if skb_tx(skb)->hardware is set no-zero. - In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
If yes, then the driver is expected to do hardware time stamping. is set no-zero. If yes, then the driver is expected to do hardware time
stamping.
- If this is possible for the skb and requested, then declare - If this is possible for the skb and requested, then declare
that the driver is doing the time stamping by setting the field that the driver is doing the time stamping by setting the flag
skb_tx(skb)->in_progress non-zero. You might want to keep a pointer SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with
to the associated skb for the next step and not free the skb. A driver
not supporting hardware time stamping doesn't do that. A driver must skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
never touch sk_buff::tstamp! It is used to store software generated
time stamps by the network subsystem. You might want to keep a pointer to the associated skb for the next step
and not free the skb. A driver not supporting hardware time stamping doesn't
do that. A driver must never touch sk_buff::tstamp! It is used to store
software generated time stamps by the network subsystem.
- As soon as the driver has sent the packet and/or obtained a - 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 hardware time stamp for it, it passes the time stamp back by
calling skb_hwtstamp_tx() with the original skb, the raw calling skb_hwtstamp_tx() with the original skb, the raw
@@ -191,6 +195,6 @@ Time stamps for outgoing packets are to be generated as follows:
this would occur at a later time in the processing pipeline than other this would occur at a later time in the processing pipeline than other
software time stamping and therefore could lead to unexpected deltas software time stamping and therefore could lead to unexpected deltas
between time stamps. between time stamps.
- If the driver did not call set skb_tx(skb)->in_progress, then - If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then
dev_hard_start_xmit() checks whether software time stamping dev_hard_start_xmit() checks whether software time stamping
is wanted as fallback and potentially generates the time stamp. is wanted as fallback and potentially generates the time stamp.

22
Documentation/powerpc/dts-bindings/fsl/usb.txt
View File

@@ -8,6 +8,7 @@ and additions :
Required properties : Required properties :
- compatible : Should be "fsl-usb2-mph" for multi port host USB - compatible : Should be "fsl-usb2-mph" for multi port host USB
controllers, or "fsl-usb2-dr" for dual role USB controllers controllers, or "fsl-usb2-dr" for dual role USB controllers
or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121
- phy_type : For multi port host USB controllers, should be one of - phy_type : For multi port host USB controllers, should be one of
"ulpi", or "serial". For dual role USB controllers, should be "ulpi", or "serial". For dual role USB controllers, should be
one of "ulpi", "utmi", "utmi_wide", or "serial". one of "ulpi", "utmi", "utmi_wide", or "serial".
@@ -33,6 +34,12 @@ Recommended properties :
- interrupt-parent : the phandle for the interrupt controller that - interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device. services interrupts for this device.
Optional properties :
- fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the
port power polarity of internal PHY signal DRVVBUS is inverted.
- fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates
the PWR_FAULT signal polarity is inverted.
Example multi port host USB controller device node : Example multi port host USB controller device node :
usb@22000 { usb@22000 {
compatible = "fsl-usb2-mph"; compatible = "fsl-usb2-mph";
@@ -57,3 +64,18 @@ Example dual role USB controller device node :
dr_mode = "otg"; dr_mode = "otg";
phy = "ulpi"; phy = "ulpi";
}; };
Example dual role USB controller device node for MPC5121ADS:
usb@4000 {
compatible = "fsl,mpc5121-usb2-dr";
reg = <0x4000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <44 0x8>;
dr_mode = "otg";
phy_type = "utmi_wide";
fsl,invert-drvvbus;
fsl,invert-pwr-fault;
};

4
Documentation/rbtree.txt
View File

@@ -21,8 +21,8 @@ three rotations, respectively, to balance the tree), with slightly slower
To quote Linux Weekly News: To quote Linux Weekly News:
There are a number of red-black trees in use in the kernel. There are a number of red-black trees in use in the kernel.
The anticipatory, deadline, and CFQ I/O schedulers all employ The deadline and CFQ I/O schedulers employ rbtrees to
rbtrees to track requests; the packet CD/DVD driver does the same. track requests; the packet CD/DVD driver does the same.
The high-resolution timer code uses an rbtree to organize outstanding The high-resolution timer code uses an rbtree to organize outstanding
timer requests. The ext3 filesystem tracks directory entries in a timer requests. The ext3 filesystem tracks directory entries in a
red-black tree. Virtual memory areas (VMAs) are tracked with red-black red-black tree. Virtual memory areas (VMAs) are tracked with red-black

47
Documentation/scsi/ChangeLog.megaraid_sas
View File

@@ -1,3 +1,50 @@
1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com)
Bo Yang
2 Current Version : 00.00.04.31-rc1
3 Older Version : 00.00.04.17.1-rc1
1. Add the Online Controller Reset (OCR) to the Driver.
OCR is the new feature for megaraid_sas driver which
will allow the fw to do the chip reset which will not
affact the OS behavious.
To add the OCR support, driver need to do:
a). reset the controller chips -- Xscale and Gen2 which
will change the function calls and add the reset function
related to this two chips.
b). during the reset, driver will store the pending cmds
which not returned by FW to driver's pending queue. Driver
will re-issue those pending cmds again to FW after the OCR
finished.
c). In driver's timeout routine, driver will report to
OS as reset. Also driver's queue routine will block the
cmds until the OCR finished.
d). in Driver's ISR routine, if driver get the FW state as
state change, FW in Failure status and FW support online controller
reset (OCR), driver will start to do the controller reset.
e). In driver's IOCTL routine, the application cmds will wait for the
OCR to finish, then issue the cmds to FW.
f). Before driver kill adapter, driver will do last chance of
OCR to see if driver can bring back the FW.
2. Add the support update flag to the driver to tell LSI megaraid_sas
application which driver will support the device update. So application
will not need to do the device update after application add/del the device
from the system.
3. In driver's timeout routine, driver will do three time reset if fw is in
failed state. Driver will kill adapter if can't bring back FW after the
this three times reset.
4. Add the input parameter max_sectors to 1MB support to our GEN2 controller.
customer can use the input paramenter max_sectors to add 1MB support to GEN2
controller.
1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 - 1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 -
(emaild-id:megaraidlinux@lsi.com) (emaild-id:megaraidlinux@lsi.com)
Bo Yang Bo Yang

15
Documentation/scsi/st.txt
View File

@@ -2,7 +2,7 @@ This file contains brief information about the SCSI tape driver.
The driver is currently maintained by Kai Mäkisara (email The driver is currently maintained by Kai Mäkisara (email
Kai.Makisara@kolumbus.fi) Kai.Makisara@kolumbus.fi)
Last modified: Sun Feb 24 21:59:07 2008 by kai.makisara Last modified: Sun Aug 29 18:25:47 2010 by kai.makisara
BASICS BASICS
@@ -85,6 +85,17 @@ writing and the last operation has been a write. Two filemarks can be
optionally written. In both cases end of data is signified by optionally written. In both cases end of data is signified by
returning zero bytes for two consecutive reads. returning zero bytes for two consecutive reads.
Writing filemarks without the immediate bit set in the SCSI command block acts
as a synchronization point, i.e., all remaining data form the drive buffers is
written to tape before the command returns. This makes sure that write errors
are caught at that point, but this takes time. In some applications, several
consecutive files must be written fast. The MTWEOFI operation can be used to
write the filemarks without flushing the drive buffer. Writing filemark at
close() is always flushing the drive buffers. However, if the previous
operation is MTWEOFI, close() does not write a filemark. This can be used if
the program wants to close/open the tape device between files and wants to
skip waiting.
If rewind, offline, bsf, or seek is done and previous tape operation was If rewind, offline, bsf, or seek is done and previous tape operation was
write, a filemark is written before moving tape. write, a filemark is written before moving tape.
@@ -301,6 +312,8 @@ MTBSR Space backward over count records.
MTFSS Space forward over count setmarks. MTFSS Space forward over count setmarks.
MTBSS Space backward over count setmarks. MTBSS Space backward over count setmarks.
MTWEOF Write count filemarks. MTWEOF Write count filemarks.
MTWEOFI Write count filemarks with immediate bit set (i.e., does not
wait until data is on tape)
MTWSM Write count setmarks. MTWSM Write count setmarks.
MTREW Rewind tape. MTREW Rewind tape.
MTOFFL Set device off line (often rewind plus eject). MTOFFL Set device off line (often rewind plus eject).

82
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@@ -300,6 +300,74 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
control correctly. If you have problems regarding this, try control correctly. If you have problems regarding this, try
another ALSA compliant mixer (alsamixer works). another ALSA compliant mixer (alsamixer works).
Module snd-azt1605
------------------
Module for Aztech Sound Galaxy soundcards based on the Aztech AZT1605
chipset.
port - port # for BASE (0x220,0x240,0x260,0x280)
wss_port - port # for WSS (0x530,0x604,0xe80,0xf40)
irq - IRQ # for WSS (7,9,10,11)
dma1 - DMA # for WSS playback (0,1,3)
dma2 - DMA # for WSS capture (0,1), -1 = disabled (default)
mpu_port - port # for MPU-401 UART (0x300,0x330), -1 = disabled (default)
mpu_irq - IRQ # for MPU-401 UART (3,5,7,9), -1 = disabled (default)
fm_port - port # for OPL3 (0x388), -1 = disabled (default)
This module supports multiple cards. It does not support autoprobe: port,
wss_port, irq and dma1 have to be specified. The other values are
optional.
"port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
or the value stored in the card's EEPROM for cards that have an EEPROM and
their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
be choosen freely from the options enumerated above.
If dma2 is specified and different from dma1, the card will operate in
full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
enable capture since only channels 0 and 1 are available for capture.
Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0
mpu_port=0x330 mpu_irq=9 fm_port=0x388".
Whatever IRQ and DMA channels you pick, be sure to reserve them for
legacy ISA in your BIOS.
Module snd-azt2316
------------------
Module for Aztech Sound Galaxy soundcards based on the Aztech AZT2316
chipset.
port - port # for BASE (0x220,0x240,0x260,0x280)
wss_port - port # for WSS (0x530,0x604,0xe80,0xf40)
irq - IRQ # for WSS (7,9,10,11)
dma1 - DMA # for WSS playback (0,1,3)
dma2 - DMA # for WSS capture (0,1), -1 = disabled (default)
mpu_port - port # for MPU-401 UART (0x300,0x330), -1 = disabled (default)
mpu_irq - IRQ # for MPU-401 UART (5,7,9,10), -1 = disabled (default)
fm_port - port # for OPL3 (0x388), -1 = disabled (default)
This module supports multiple cards. It does not support autoprobe: port,
wss_port, irq and dma1 have to be specified. The other values are
optional.
"port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
or the value stored in the card's EEPROM for cards that have an EEPROM and
their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
be choosen freely from the options enumerated above.
If dma2 is specified and different from dma1, the card will operate in
full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
enable capture since only channels 0 and 1 are available for capture.
Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0
mpu_port=0x330 mpu_irq=9 fm_port=0x388".
Whatever IRQ and DMA channels you pick, be sure to reserve them for
legacy ISA in your BIOS.
Module snd-aw2 Module snd-aw2
-------------- --------------
@@ -1641,20 +1709,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
This card is also known as Audio Excel DSP 16 or Zoltrix AV302. This card is also known as Audio Excel DSP 16 or Zoltrix AV302.
Module snd-sgalaxy
------------------
Module for Aztech Sound Galaxy sound card.
sbport - Port # for SB16 interface (0x220,0x240)
wssport - Port # for WSS interface (0x530,0xe80,0xf40,0x604)
irq - IRQ # (7,9,10,11)
dma1 - DMA #
This module supports multiple cards.
The power-management is supported.
Module snd-sscape Module snd-sscape
----------------- -----------------

8
Documentation/sound/alsa/HD-Audio.txt
View File

@@ -57,9 +57,11 @@ dead. However, this detection isn't perfect on some devices. In such
a case, you can change the default method via `position_fix` option. a case, you can change the default method via `position_fix` option.
`position_fix=1` means to use LPIB method explicitly. `position_fix=1` means to use LPIB method explicitly.
`position_fix=2` means to use the position-buffer. 0 is the default `position_fix=2` means to use the position-buffer.
value, the automatic check and fallback to LPIB as described in the `position_fix=3` means to use a combination of both methods, needed
above. If you get a problem of repeated sounds, this option might for some VIA and ATI controllers. 0 is the default value for all other
controllers, the automatic check and fallback to LPIB as described in
the above. If you get a problem of repeated sounds, this option might
help. help.
In addition to that, every controller is known to be broken regarding In addition to that, every controller is known to be broken regarding

14
Documentation/sysctl/kernel.txt
View File

@@ -28,6 +28,7 @@ show up in /proc/sys/kernel:
- core_uses_pid - core_uses_pid
- ctrl-alt-del - ctrl-alt-del
- dentry-state - dentry-state
- dmesg_restrict
- domainname - domainname
- hostname - hostname
- hotplug - hotplug
@@ -213,6 +214,19 @@ to decide what to do with it.
============================================================== ==============================================================
dmesg_restrict:
This toggle indicates whether unprivileged users are prevented from using
dmesg(8) to view messages from the kernel's log buffer. When
dmesg_restrict is set to (0) there are no restrictions. When
dmesg_restrict is set set to (1), users must have CAP_SYS_ADMIN to use
dmesg(8).
The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the default
value of dmesg_restrict.
==============================================================
domainname & hostname: domainname & hostname:
These files can be used to set the NIS/YP domainname and the These files can be used to set the NIS/YP domainname and the

12
Documentation/sysctl/vm.txt
View File

@@ -80,8 +80,10 @@ dirty_background_bytes
Contains the amount of dirty memory at which the pdflush background writeback Contains the amount of dirty memory at which the pdflush background writeback
daemon will start writeback. daemon will start writeback.
If dirty_background_bytes is written, dirty_background_ratio becomes a function Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
of its value (dirty_background_bytes / the amount of dirtyable system memory). one of them may be specified at a time. When one sysctl is written it is
immediately taken into account to evaluate the dirty memory limits and the
other appears as 0 when read.
============================================================== ==============================================================
@@ -97,8 +99,10 @@ dirty_bytes
Contains the amount of dirty memory at which a process generating disk writes Contains the amount of dirty memory at which a process generating disk writes
will itself start writeback. will itself start writeback.
If dirty_bytes is written, dirty_ratio becomes a function of its value Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be
(dirty_bytes / the amount of dirtyable system memory). specified at a time. When one sysctl is written it is immediately taken into
account to evaluate the dirty memory limits and the other appears as 0 when
read.
Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
value lower than this limit will be ignored and the old configuration will be value lower than this limit will be ignored and the old configuration will be

7
Documentation/sysrq.txt
View File

@@ -75,7 +75,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
'f' - Will call oom_kill to kill a memory hog process. 'f' - Will call oom_kill to kill a memory hog process.
'g' - Used by kgdb on ppc and sh platforms. 'g' - Used by kgdb (kernel debugger)
'h' - Will display help (actually any other key than those listed 'h' - Will display help (actually any other key than those listed
here will display help. but 'h' is easy to remember :-) here will display help. but 'h' is easy to remember :-)
@@ -110,12 +110,15 @@ On all - write a character to /proc/sysrq-trigger. e.g.:
'u' - Will attempt to remount all mounted filesystems read-only. 'u' - Will attempt to remount all mounted filesystems read-only.
'v' - Dumps Voyager SMP processor info to your console. 'v' - Forcefully restores framebuffer console
'v' - Causes ETM buffer dump [ARM-specific]
'w' - Dumps tasks that are in uninterruptable (blocked) state. 'w' - Dumps tasks that are in uninterruptable (blocked) state.
'x' - Used by xmon interface on ppc/powerpc platforms. 'x' - Used by xmon interface on ppc/powerpc platforms.
'y' - Show global CPU Registers [SPARC-64 specific]
'z' - Dump the ftrace buffer 'z' - Dump the ftrace buffer
'0'-'9' - Sets the console log level, controlling which kernel messages '0'-'9' - Sets the console log level, controlling which kernel messages

Some files were not shown because too many files have changed in this diff Show More