FEX-Emu/linux
1
0
Fork 0
mirror of https://github.com/FEX-Emu/linux.git synced 2025-01-05 08:48:53 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into wireless-next

Browse Source
This commit is contained in:
Wey-Yi Guy 2012-01-28 08:07:03 -08:00
commit 03e369d932
6892 changed files with 261115 additions and 155525 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
Documentation/ABI/stable/sysfs-bus-xen-backend Normal file
View File

@ -0,0 +1,75 @@
What: /sys/bus/xen-backend/devices/*/devtype
Date: Feb 2009
KernelVersion: 2.6.38
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The type of the device. e.g., one of: 'vbd' (block),
'vif' (network), or 'vfb' (framebuffer).
What: /sys/bus/xen-backend/devices/*/nodename
Date: Feb 2009
KernelVersion: 2.6.38
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
XenStore node (under /local/domain/NNN/) for this
backend device.
What: /sys/bus/xen-backend/devices/vbd-*/physical_device
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The major:minor number (in hexidecimal) of the
physical device providing the storage for this backend
block device.
What: /sys/bus/xen-backend/devices/vbd-*/mode
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Whether the block device is read-only ('r') or
read-write ('w').
What: /sys/bus/xen-backend/devices/vbd-*/statistics/f_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of flush requests from the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/oo_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of requests delayed because the backend was too
busy processing previous requests.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of read requests from the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/rd_sect
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of sectors read by the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_req
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of write requests from the frontend.
What: /sys/bus/xen-backend/devices/vbd-*/statistics/wr_sect
Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of sectors written by the frontend.

77
Documentation/ABI/stable/sysfs-devices-system-xen_memory Normal file
View File

@ -0,0 +1,77 @@
What: /sys/devices/system/xen_memory/xen_memory0/max_retry_count
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The maximum number of times the balloon driver will
attempt to increase the balloon before giving up. See
also 'retry_count' below.
A value of zero means retry forever and is the default one.
What: /sys/devices/system/xen_memory/xen_memory0/max_schedule_delay
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The limit that 'schedule_delay' (see below) will be
increased to. The default value is 32 seconds.
What: /sys/devices/system/xen_memory/xen_memory0/retry_count
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The current number of times that the balloon driver
has attempted to increase the size of the balloon.
The default value is one. With max_retry_count being
zero (unlimited), this means that the driver will attempt
to retry with a 'schedule_delay' delay.
What: /sys/devices/system/xen_memory/xen_memory0/schedule_delay
Date: May 2011
KernelVersion: 2.6.39
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The time (in seconds) to wait between attempts to
increase the balloon. Each time the balloon cannot be
increased, 'schedule_delay' is increased (until
'max_schedule_delay' is reached at which point it
will use the max value).
What: /sys/devices/system/xen_memory/xen_memory0/target
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The target number of pages to adjust this domain's
memory reservation to.
What: /sys/devices/system/xen_memory/xen_memory0/target_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
As target above, except the value is in KiB.
What: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Current size (in KiB) of this domain's memory
reservation.
What: /sys/devices/system/xen_memory/xen_memory0/info/high_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Amount (in KiB) of high memory in the balloon.
What: /sys/devices/system/xen_memory/xen_memory0/info/low_kb
Date: April 2008
KernelVersion: 2.6.26
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Amount (in KiB) of low (or normal) memory in the
balloon.

18
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -66,6 +66,24 @@ Description:
re-discover previously removed devices.
Depends on CONFIG_HOTPLUG.
What: /sys/bus/pci/devices/.../msi_irqs/
Date: September, 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
The /sys/devices/.../msi_irqs directory contains a variable set
of sub-directories, with each sub-directory being named after a
corresponding msi irq vector allocated to that device. Each
numbered sub-directory N contains attributes of that irq.
Note that this directory is not created for device drivers which
do not support msi irqs
What: /sys/bus/pci/devices/.../msi_irqs/<N>/mode
Date: September 2011
Contact: Neil Horman <nhorman@tuxdriver.com>
Description:
This attribute indicates the mode that the irq vector named by
the parent directory is in (msi vs. msix)
What: /sys/bus/pci/devices/.../remove
Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org>

25
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -119,6 +119,31 @@ Description:
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).
What: /sys/bus/usb/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
Description:
Writing a device ID to this file will attempt to
dynamically add a new device ID to a USB device driver.
This may allow the driver to support more hardware than
was included in the driver's static device ID support
table at compile time. The format for the device ID is:
idVendor idProduct bInterfaceClass.
The vendor ID and device ID fields are required, the
interface class is optional.
Upon successfully adding an ID, the driver will probe
for the device and attempt to bind to it. For example:
# echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
What: /sys/bus/usb-serial/drivers/.../new_id
Date: October 2011
Contact: linux-usb@vger.kernel.org
Description:
For serial USB drivers, this attribute appears under the
extra bus folder "usb-serial" in sysfs; apart from that
difference, all descriptions from the entry
"/sys/bus/usb/drivers/.../new_id" apply.
What: /sys/bus/usb/drivers/.../remove_id
Date: November 2009
Contact: CHENG Renquan <rqcheng@smu.edu.sg>

12
Documentation/ABI/testing/sysfs-class-rtc-rtc0-device-rtc_calibration Normal file
View File

@ -0,0 +1,12 @@
What: Attribute for calibrating ST-Ericsson AB8500 Real Time Clock
Date: Oct 2011
KernelVersion: 3.0
Contact: Mark Godfrey <mark.godfrey@stericsson.com>
Description: The rtc_calibration attribute allows the userspace to
calibrate the AB8500.s 32KHz Real Time Clock.
Every 60 seconds the AB8500 will correct the RTC's value
by adding to it the value of this attribute.
The range of the attribute is -127 to +127 in units of
30.5 micro-seconds (half-parts-per-million of the 32KHz clock)
Users: The /vendor/st-ericsson/base_utilities/core/rtc_calibration
daemon uses this interface.

34
Documentation/ABI/testing/sysfs-devices-platform-docg3 Normal file
View File

@ -0,0 +1,34 @@
What: /sys/devices/platform/docg3/f[0-3]_dps[01]_is_keylocked
Date: November 2011
KernelVersion: 3.3
Contact: Robert Jarzmik <robert.jarzmik@free.fr>
Description:
Show whether the floor (0 to 4), protection area (0 or 1) is
keylocked. Each docg3 chip (or floor) has 2 protection areas,
which can cover any part of it, block aligned, called DPS.
The protection has information embedded whether it blocks reads,
writes or both.
The result is:
0 -> the DPS is not keylocked
1 -> the DPS is keylocked
Users: None identified so far.
What: /sys/devices/platform/docg3/f[0-3]_dps[01]_protection_key
Date: November 2011
KernelVersion: 3.3
Contact: Robert Jarzmik <robert.jarzmik@free.fr>
Description:
Enter the protection key for the floor (0 to 4), protection area
(0 or 1). Each docg3 chip (or floor) has 2 protection areas,
which can cover any part of it, block aligned, called DPS.
The protection has information embedded whether it blocks reads,
writes or both.
The protection key is a string of 8 bytes (value 0-255).
Entering the correct value toggle the lock, and can be observed
through f[0-3]_dps[01]_is_keylocked.
Possible values are:
- 8 bytes
Typical values are:
- "00000000"
- "12345678"
Users: None identified so far.

2
Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff
View File

@ -1,7 +1,7 @@
What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
Date: July 2011
KernelVersion: 3.2
Contact: Michal Malý <madcatxster@gmail.com>
Contact: Michal Malý <madcatxster@gmail.com>
Description: Display minimum, maximum and current range of the steering
wheel. Writing a value within min and max boundaries sets the
range of the wheel.

9
Documentation/ABI/testing/sysfs-driver-hid-multitouch Normal file
View File

@ -0,0 +1,9 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/quirks
Date: November 2011
Contact: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Description: The integer value of this attribute corresponds to the
quirks actually in place to handle the device's protocol.
When read, this attribute returns the current settings (see
MT_QUIRKS_* in hid-multitouch.c).
When written this attribute change on the fly the quirks, then
the protocol to handle the device.

135
Documentation/ABI/testing/sysfs-driver-hid-roccat-isku Normal file
View File

@ -0,0 +1,135 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/actual_profile
Date: June 2011
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 actual
profile. This value is persistent, so its equivalent to the
profile that's active when the device is powered on next time.
When written, this file sets the number of the startup profile
and the device activates this profile immediately.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/info
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
The data is 6 bytes long.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/key_mask
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one deactivate certain keys like
windows and application keys, to prevent accidental presses.
Profile number for which this settings occur is included in
written data. The data has to be 6 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_capslock
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
capslock key for a specific profile. Profile number is included
in written data. The data has to be 6 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_easyzone
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
easyzone keys for a specific profile. Profile number is included
in written data. The data has to be 65 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_function
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
function keys for a specific profile. Profile number is included
in written data. The data has to be 41 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_macro
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the macro
keys for a specific profile. Profile number is included in
written data. The data has to be 35 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_media
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the media
keys for a specific profile. Profile number is included in
written data. The data has to be 29 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_thumbster
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
thumbster keys for a specific profile. Profile number is included
in written data. The data has to be 23 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/last_set
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the time in secs since
epoch in which the last configuration took place.
The data has to be 20 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/light
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the backlight intensity for
a specific profile. Profile number is included in written data.
The data has to be 10 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/macro
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one store macros with max 500
keystrokes for a specific button for a specific profile.
Button and profile numbers are included in written data.
The data has to be 2083 bytes long.
Before reading this file, control has to be written to select
which profile and key to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one select which data from which
profile will be read next. The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talk
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one trigger easyshift functionality
from the host.
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net

12
Documentation/ABI/testing/sysfs-driver-hid-wiimote
View File

@ -8,3 +8,15 @@ Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: Make it possible to set/get current led state. Reading from it
returns 0 if led is off and 1 if it is on. Writing 0 to it
disables the led, writing 1 enables it.
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
Date: August 2011
KernelVersion: 3.2
Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: This file contains the currently connected and initialized
extensions. It can be one of: none, motionp, nunchuck, classic,
motionp+nunchuck, motionp+classic
motionp is the official Nintendo Motion+ extension, nunchuck is
the official Nintendo Nunchuck extension and classic is the
Nintendo Classic Controller extension. The motionp extension can
be combined with the other two.

17
Documentation/ABI/testing/sysfs-driver-wacom
View File

@ -15,9 +15,9 @@ Contact: linux-input@vger.kernel.org
Description:
Attribute group for control of the status LEDs and the OLEDs.
This attribute group is only available for Intuos 4 M, L,
and XL (with LEDs and OLEDs) and Cintiq 21UX2 (LEDs only).
Therefore its presence implicitly signifies the presence of
said LEDs and OLEDs on the tablet device.
and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD
(LEDs only). Therefore its presence implicitly signifies the
presence of said LEDs and OLEDs on the tablet device.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
Date: August 2011
@ -41,16 +41,17 @@ Date: August 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the four (for Intuos 4)
or of the right four (for Cintiq 21UX2) status LEDs is active (0..3).
The other three LEDs on the same side are always inactive.
or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status
LEDs is active (0..3). The other three LEDs on the same side are
always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
Date: September 2011
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the left four (for Cintiq 21UX2)
status LEDs is active (0..3). The other three LEDs on the left are always
inactive.
Writing to this file sets which one of the left four (for Cintiq 21UX2
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
the left are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
Date: August 2011

4
Documentation/ABI/testing/sysfs-kernel-slab
View File

@ -346,6 +346,10 @@ Description:
number of objects per slab. If a slab cannot be allocated
because of fragmentation, SLUB will retry with the minimum order
possible depending on its characteristics.
When debug_guardpage_minorder=N (N > 0) parameter is specified
(see Documentation/kernel-parameters.txt), the minimum possible
order is used and this sysfs entry can not be used to change
the order at run time.
What: /sys/kernel/slab/cache/order_fallback
Date: April 2008

50
Documentation/DocBook/debugobjects.tmpl
View File

@ -96,6 +96,7 @@
<listitem><para>debug_object_deactivate</para></listitem>
<listitem><para>debug_object_destroy</para></listitem>
<listitem><para>debug_object_free</para></listitem>
<listitem><para>debug_object_assert_init</para></listitem>
</itemizedlist>
Each of these functions takes the address of the real object and
a pointer to the object type specific debug description
@ -273,6 +274,26 @@
debug checks.
</para>
</sect1>
<sect1 id="debug_object_assert_init">
<title>debug_object_assert_init</title>
<para>
This function is called to assert that an object has been
initialized.
</para>
<para>
When the real object is not tracked by debugobjects, it calls
fixup_assert_init of the object type description structure
provided by the caller, with the hardcoded object state
ODEBUG_NOT_AVAILABLE. The fixup function can correct the problem
by calling debug_object_init and other specific initializing
functions.
</para>
<para>
When the real object is already tracked by debugobjects it is
ignored.
</para>
</sect1>
</chapter>
<chapter id="fixupfunctions">
<title>Fixup functions</title>
@ -381,6 +402,35 @@
statistics.
</para>
</sect1>
<sect1 id="fixup_assert_init">
<title>fixup_assert_init</title>
<para>
This function is called from the debug code whenever a problem
in debug_object_assert_init is detected.
</para>
<para>
Called from debug_object_assert_init() with a hardcoded state
ODEBUG_STATE_NOTAVAILABLE when the object is not found in the
debug bucket.
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
statistics.
</para>
<para>
Note, this function should make sure debug_object_init() is
called before returning.
</para>
<para>
The handling of statically initialized objects is a special
case. The fixup function should check if this is a legitimate
case of a statically initialized object or not. In this case only
debug_object_init() should be called to make the object known to
the tracker. Then the function should return 0 because this is not
a real fixup.
</para>
</sect1>
</chapter>
<chapter id="bugs">
<title>Known Bugs And Assumptions</title>

2
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -404,7 +404,7 @@
/* SNDRV_CARDS: maximum number of cards supported by this module */
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;
static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;
/* definition of the chip-specific record */
struct mychip {

4
Documentation/HOWTO
View File

@ -275,8 +275,8 @@ versions.
If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
kernel is the current stable kernel.
2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
released as needs dictate. The normal release period is approximately
2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
are released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
instantly.

6
Documentation/RCU/checklist.txt
View File

@ -328,6 +328,12 @@ over a rather long period of time, but improvements are always welcome!
RCU rather than SRCU, because RCU is almost always faster and
easier to use than is SRCU.
If you need to enter your read-side critical section in a
hardirq or exception handler, and then exit that same read-side
critical section in the task that was interrupted, then you need
to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid
the lockdep checking that would otherwise this practice illegal.
Also unlike other forms of RCU, explicit initialization
and cleanup is required via init_srcu_struct() and
cleanup_srcu_struct(). These are passed a "struct srcu_struct"

10
Documentation/RCU/rcu.txt
View File

@ -38,11 +38,11 @@ o How can the updater tell when a grace period has completed
Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
same effect, but require that the readers manipulate CPU-local
counters. These counters allow limited types of blocking
within RCU read-side critical sections. SRCU also uses
CPU-local counters, and permits general blocking within
RCU read-side critical sections. These two variants of
RCU detect grace periods by sampling these counters.
counters. These counters allow limited types of blocking within
RCU read-side critical sections. SRCU also uses CPU-local
counters, and permits general blocking within RCU read-side
critical sections. These variants of RCU detect grace periods
by sampling these counters.
o If I am running on a uniprocessor kernel, which can only do one
thing at a time, why should I wait for a grace period?

16
Documentation/RCU/stallwarn.txt
View File

@ -101,6 +101,11 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
messages.
o A hardware or software issue shuts off the scheduler-clock
interrupt on a CPU that is not in dyntick-idle mode. This
problem really has happened, and seems to be most likely to
result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.
o A bug in the RCU implementation.
o A hardware failure. This is quite unlikely, but has occurred
@ -109,12 +114,11 @@ o A hardware failure. This is quite unlikely, but has occurred
This resulted in a series of RCU CPU stall warnings, eventually
leading the realization that the CPU had failed.
The RCU, RCU-sched, and RCU-bh implementations have CPU stall
warning. SRCU does not have its own CPU stall warnings, but its
calls to synchronize_sched() will result in RCU-sched detecting
RCU-sched-related CPU stalls. Please note that RCU only detects
CPU stalls when there is a grace period in progress. No grace period,
no CPU stall warnings.
The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
SRCU does not have its own CPU stall warnings, but its calls to
synchronize_sched() will result in RCU-sched detecting RCU-sched-related
CPU stalls. Please note that RCU only detects CPU stalls when there is
a grace period in progress. No grace period, no CPU stall warnings.
To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.

13
Documentation/RCU/torture.txt
View File

@ -61,11 +61,24 @@ nreaders This is the number of RCU reading threads supported.
To properly exercise RCU implementations with preemptible
read-side critical sections.
onoff_interval
The number of seconds between each attempt to execute a
randomly selected CPU-hotplug operation. Defaults to
zero, which disables CPU hotplugging. In HOTPLUG_CPU=n
kernels, rcutorture will silently refuse to do any
CPU-hotplug operations regardless of what value is
specified for onoff_interval.
shuffle_interval
The number of seconds to keep the test threads affinitied
to a particular subset of the CPUs, defaults to 3 seconds.
Used in conjunction with test_no_idle_hz.
shutdown_secs The number of seconds to run the test before terminating
the test and powering off the system. The default is
zero, which disables test termination and system shutdown.
This capability is useful for automated testing.
stat_interval The number of seconds between output of torture
statistics (via printk()). Regardless of the interval,
statistics are printed when the module is unloaded.

4
Documentation/RCU/trace.txt
View File

@ -105,14 +105,10 @@ o "dt" is the current value of the dyntick counter that is incremented
or one greater than the interrupt-nesting depth otherwise.
The number after the second "/" is the NMI nesting depth.
This field is displayed only for CONFIG_NO_HZ kernels.
o "df" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being in
dynticks-idle state.
This field is displayed only for CONFIG_NO_HZ kernels.
o "of" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being
offline. In a perfect world, this might never happen, but it

19
Documentation/RCU/whatisRCU.txt
View File

@ -4,6 +4,7 @@ to start learning about RCU:
1. What is RCU, Fundamentally? http://lwn.net/Articles/262464/
2. What is RCU? Part 2: Usage http://lwn.net/Articles/263130/
3. RCU part 3: the RCU API http://lwn.net/Articles/264090/
4. The RCU API, 2010 Edition http://lwn.net/Articles/418853/
What is RCU?
@ -834,6 +835,8 @@ SRCU: Critical sections Grace period Barrier
srcu_read_lock synchronize_srcu N/A
srcu_read_unlock synchronize_srcu_expedited
srcu_read_lock_raw
srcu_read_unlock_raw
srcu_dereference
SRCU: Initialization/cleanup
@ -855,27 +858,33 @@ list can be helpful:
a. Will readers need to block? If so, you need SRCU.
b. What about the -rt patchset? If readers would need to block
b. Is it necessary to start a read-side critical section in a
hardirq handler or exception handler, and then to complete
this read-side critical section in the task that was
interrupted? If so, you need SRCU's srcu_read_lock_raw() and
srcu_read_unlock_raw() primitives.
c. What about the -rt patchset? If readers would need to block
in an non-rt kernel, you need SRCU. If readers would block
in a -rt kernel, but not in a non-rt kernel, SRCU is not
necessary.
c. Do you need to treat NMI handlers, hardirq handlers,
d. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
If so, you need RCU-sched.
d. Do you need RCU grace periods to complete even in the face
e. Do you need RCU grace periods to complete even in the face
of softirq monopolization of one or more of the CPUs? For
example, is your code subject to network-based denial-of-service
attacks? If so, you need RCU-bh.
e. Is your workload too update-intensive for normal use of
f. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
f. Otherwise, use RCU.
g. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.

11
Documentation/arm/memory.txt
View File

@ -51,15 +51,14 @@ ffc00000 ffefffff DMA memory mapping region. Memory returned
ff000000 ffbfffff Reserved for future expansion of DMA
mapping region.
VMALLOC_END feffffff Free for platform use, recommended.
VMALLOC_END must be aligned to a 2MB
boundary.
VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
Memory returned by vmalloc/ioremap will
be dynamically placed in this region.
VMALLOC_START may be based upon the value
of the high_memory variable.
Machine specific static mappings are also
located here through iotable_init().
VMALLOC_START is based upon the value
of the high_memory variable, and VMALLOC_END
is equal to 0xff000000.
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically

87
Documentation/atomic_ops.txt
View File

@ -84,6 +84,93 @@ compiler optimizes the section accessing atomic_t variables.
*** YOU HAVE BEEN WARNED! ***
Properly aligned pointers, longs, ints, and chars (and unsigned
equivalents) may be atomically loaded from and stored to in the same
sense as described for atomic_read() and atomic_set(). The ACCESS_ONCE()
macro should be used to prevent the compiler from using optimizations
that might otherwise optimize accesses out of existence on the one hand,
or that might create unsolicited accesses on the other.
For example consider the following code:
while (a > 0)
do_something();
If the compiler can prove that do_something() does not store to the
variable a, then the compiler is within its rights transforming this to
the following:
tmp = a;
if (a > 0)
for (;;)
do_something();
If you don't want the compiler to do this (and you probably don't), then
you should use something like the following:
while (ACCESS_ONCE(a) < 0)
do_something();
Alternatively, you could place a barrier() call in the loop.
For another example, consider the following code:
tmp_a = a;
do_something_with(tmp_a);
do_something_else_with(tmp_a);
If the compiler can prove that do_something_with() does not store to the
variable a, then the compiler is within its rights to manufacture an
additional load as follows:
tmp_a = a;
do_something_with(tmp_a);
tmp_a = a;
do_something_else_with(tmp_a);
This could fatally confuse your code if it expected the same value
to be passed to do_something_with() and do_something_else_with().
The compiler would be likely to manufacture this additional load if
do_something_with() was an inline function that made very heavy use
of registers: reloading from variable a could save a flush to the
stack and later reload. To prevent the compiler from attacking your
code in this manner, write the following:
tmp_a = ACCESS_ONCE(a);
do_something_with(tmp_a);
do_something_else_with(tmp_a);
For a final example, consider the following code, assuming that the
variable a is set at boot time before the second CPU is brought online
and never changed later, so that memory barriers are not needed:
if (a)
b = 9;
else
b = 42;
The compiler is within its rights to manufacture an additional store
by transforming the above code into the following:
b = 42;
if (a)
b = 9;
This could come as a fatal surprise to other code running concurrently
that expected b to never have the value 42 if a was zero. To prevent
the compiler from doing this, write something like:
if (a)
ACCESS_ONCE(b) = 9;
else
ACCESS_ONCE(b) = 42;
Don't even -think- about doing this without proper use of memory barriers,
locks, or atomic operations if variable a can change at runtime!
*** WARNING: ACCESS_ONCE() DOES NOT IMPLY A BARRIER! ***
Now, we move onto the atomic operation interfaces typically implemented with
the help of assembly code.

51
Documentation/cgroups/cgroups.txt
View File

@ -594,53 +594,44 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
called multiple times against a cgroup.
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task)
struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
Called prior to moving a task into a cgroup; if the subsystem
returns an error, this will abort the attach operation. If a NULL
task is passed, then a successful result indicates that *any*
unspecified task can be moved into the cgroup. Note that this isn't
called on a fork. If this method returns 0 (success) then this should
remain valid while the caller holds cgroup_mutex and it is ensured that either
Called prior to moving one or more tasks into a cgroup; if the
subsystem returns an error, this will abort the attach operation.
@tset contains the tasks to be attached and is guaranteed to have at
least one task in it.
If there are multiple tasks in the taskset, then:
- it's guaranteed that all are from the same thread group
- @tset contains all tasks from the thread group whether or not
they're switching cgroups
- the first task is the leader
Each @tset entry also contains the task's old cgroup and tasks which
aren't switching cgroup can be skipped easily using the
cgroup_taskset_for_each() iterator. Note that this isn't called on a
fork. If this method returns 0 (success) then this should remain valid
while the caller holds cgroup_mutex and it is ensured that either
attach() or cancel_attach() will be called in future.
int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As can_attach, but for operations that must be run once per task to be
attached (possibly many when using cgroup_attach_proc). Called after
can_attach.
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task, bool threadgroup)
struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
Called when a task attach operation has failed after can_attach() has succeeded.
A subsystem whose can_attach() has some side-effects should provide this
function, so that the subsystem can implement a rollback. If not, not necessary.
This will be called only about subsystems whose can_attach() operation have
succeeded.
void pre_attach(struct cgroup *cgrp);
(cgroup_mutex held by caller)
For any non-per-thread attachment work that needs to happen before
attach_task. Needed by cpuset.
succeeded. The parameters are identical to can_attach().
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct cgroup *old_cgrp, struct task_struct *task)
struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
Called after the task has been attached to the cgroup, to allow any
post-attachment activity that requires memory allocations or blocking.
void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As attach, but for operations that must be run once per task to be attached,
like can_attach_task. Called before attach. Currently does not support any
subsystem that might need the old_cgrp for every thread in the group.
The parameters are identical to can_attach().
void fork(struct cgroup_subsy *ss, struct task_struct *task)

9
Documentation/cgroups/memory.txt
View File

@ -61,7 +61,7 @@ Brief summary of control files.
memory.failcnt # show the number of memory usage hits limits
memory.memsw.failcnt # show the number of memory+Swap hits limits
memory.max_usage_in_bytes # show max memory usage recorded
memory.memsw.usage_in_bytes # show max memory+Swap usage recorded
memory.memsw.max_usage_in_bytes # show max memory+Swap usage recorded
memory.soft_limit_in_bytes # set/show soft limit of memory usage
memory.stat # show various statistics
memory.use_hierarchy # set/show hierarchical account enabled
@ -410,8 +410,11 @@ memory.stat file includes following statistics
cache - # of bytes of page cache memory.
rss - # of bytes of anonymous and swap cache memory.
mapped_file - # of bytes of mapped file (includes tmpfs/shmem)
pgpgin - # of pages paged in (equivalent to # of charging events).
pgpgout - # of pages paged out (equivalent to # of uncharging events).
pgpgin - # of charging events to the memory cgroup. The charging
event happens each time a page is accounted as either mapped
anon page(RSS) or cache page(Page Cache) to the cgroup.
pgpgout - # of uncharging events to the memory cgroup. The uncharging
event happens each time a page is unaccounted from the cgroup.
swap - # of bytes of swap usage
inactive_anon - # of bytes of anonymous memory and swap cache memory on
LRU list.

4
Documentation/cpu-freq/governors.txt
View File

@ -127,7 +127,7 @@ in the bash (as said, 1000 is default), do:
echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \
>ondemand/sampling_rate
show_sampling_rate_min:
sampling_rate_min:
The sampling rate is limited by the HW transition latency:
transition_latency * 100
Or by kernel restrictions:
@ -140,8 +140,6 @@ HZ=100: min=200000us (200ms)
The highest value of kernel and HW latency restrictions is shown and
used as the minimum sampling rate.
show_sampling_rate_max: THIS INTERFACE IS DEPRECATED, DON'T USE IT.
up_threshold: defines what the average CPU usage between the samplings
of 'sampling_rate' needs to be for the kernel to make a decision on
whether it should increase the frequency. For example when it is set

8
Documentation/development-process/5.Posting
View File

@ -271,10 +271,10 @@ copies should go to:
the linux-kernel list.
- If you are fixing a bug, think about whether the fix should go into the
next stable update. If so, stable@kernel.org should get a copy of the
patch. Also add a "Cc: stable@kernel.org" to the tags within the patch
itself; that will cause the stable team to get a notification when your
fix goes into the mainline.
next stable update. If so, stable@vger.kernel.org should get a copy of
the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
the patch itself; that will cause the stable team to get a notification
when your fix goes into the mainline.
When selecting recipients for a patch, it is good to have an idea of who
you think will eventually accept the patch and get it merged. While it

5
Documentation/devices.txt
View File

@ -379,7 +379,7 @@ Your cooperation is appreciated.
162 = /dev/smbus System Management Bus
163 = /dev/lik Logitech Internet Keyboard
164 = /dev/ipmo Intel Intelligent Platform Management
165 = /dev/vmmon VMWare virtual machine monitor
165 = /dev/vmmon VMware virtual machine monitor
166 = /dev/i2o/ctl I2O configuration manager
167 = /dev/specialix_sxctl Specialix serial control
168 = /dev/tcldrv Technology Concepts serial control
@ -447,6 +447,9 @@ Your cooperation is appreciated.
234 = /dev/btrfs-control Btrfs control device
235 = /dev/autofs Autofs control device
236 = /dev/mapper/control Device-Mapper control device
237 = /dev/loop-control Loopback control device
238 = /dev/vhost-net Host kernel accelerator for virtio net
240-254 Reserved for local use
255 Reserved for MISC_DYNAMIC_MINOR

8
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -21,6 +21,10 @@ i.MX53 Smart Mobile Reference Design Board
Required root node properties:
- compatible = "fsl,imx53-smd", "fsl,imx53";
i.MX6 Quad SABRE Automotive Board
i.MX6 Quad Armadillo2 Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
- compatible = "fsl,imx6q-arm2", "fsl,imx6q";
i.MX6 Quad SABRE Lite Board
Required root node properties:
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";

4
Documentation/devicetree/bindings/arm/gic.txt
View File

@ -42,6 +42,10 @@ Optional
- interrupts : Interrupt source of the parent interrupt controller. Only
present on secondary GICs.
- cpu-offset : per-cpu offset within the distributor and cpu interface
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
Example:
intc: interrupt-controller@fff11000 {

8
Documentation/devicetree/bindings/arm/insignal-boards.txt Normal file
View File

@ -0,0 +1,8 @@
* Insignal's Exynos4210 based Origen evaluation board
Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.

8
Documentation/devicetree/bindings/arm/samsung-boards.txt Normal file
View File

@ -0,0 +1,8 @@
* Samsung's Exynos4210 based SMDKV310 evaluation board
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.

14
Documentation/devicetree/bindings/arm/tegra.txt Normal file
View File

@ -0,0 +1,14 @@
NVIDIA Tegra device tree bindings
-------------------------------------------
Boards with the tegra20 SoC shall have the following properties:
Required root node property:
compatible = "nvidia,tegra20";
Boards with the tegra30 SoC shall have the following properties:
Required root node property:
compatible = "nvidia,tegra30";

29
Documentation/devicetree/bindings/arm/vic.txt Normal file
View File

@ -0,0 +1,29 @@
* ARM Vectored Interrupt Controller
One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM
system for interrupt routing. For multiple controllers they can either be
nested or have the outputs wire-OR'd together.
Required properties:
- compatible : should be one of
"arm,pl190-vic"
"arm,pl192-vic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as
the VIC has no configuration options for interrupt sources. The cell is a u32
and defines the interrupt number.
- reg : The register bank for the VIC.
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
Example:
vic0: interrupt-controller@60000 {
compatible = "arm,pl192-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x60000 0x1000>;
};

40
Documentation/devicetree/bindings/c6x/clocks.txt Normal file
View File

@ -0,0 +1,40 @@
C6X PLL Clock Controllers
-------------------------
This is a first-cut support for the SoC clock controllers. This is still
under development and will probably change as the common device tree
clock support is added to the kernel.
Required properties:
- compatible: "ti,c64x+pll"
May also have SoC-specific value to support SoC-specific initialization
in the driver. One of:
"ti,c6455-pll"
"ti,c6457-pll"
"ti,c6472-pll"
"ti,c6474-pll"
- reg: base address and size of register area
- clock-frequency: input clock frequency in hz
Optional properties:
- ti,c64x+pll-bypass-delay: CPU cycles to delay when entering bypass mode
- ti,c64x+pll-reset-delay: CPU cycles to delay after PLL reset
- ti,c64x+pll-lock-delay: CPU cycles to delay after PLL frequency change
Example:
clock-controller@29a0000 {
compatible = "ti,c6472-pll", "ti,c64x+pll";
reg = <0x029a0000 0x200>;
clock-frequency = <25000000>;
ti,c64x+pll-bypass-delay = <200>;
ti,c64x+pll-reset-delay = <12000>;
ti,c64x+pll-lock-delay = <80000>;
};

127
Documentation/devicetree/bindings/c6x/dscr.txt Normal file
View File

@ -0,0 +1,127 @@
Device State Configuration Registers
------------------------------------
TI C6X SoCs contain a region of miscellaneous registers which provide various
function for SoC control or status. Details vary considerably among from SoC
to SoC with no two being alike.
In general, the Device State Configuraion Registers (DSCR) will provide one or
more configuration registers often protected by a lock register where one or
more key values must be written to a lock register in order to unlock the
configuration register for writes. These configuration register may be used to
enable (and disable in some cases) SoC pin drivers, select peripheral clock
sources (internal or pin), etc. In some cases, a configuration register is
write once or the individual bits are write once. In addition to device config,
the DSCR block may provide registers which which are used to reset peripherals,
provide device ID information, provide ethernet MAC addresses, as well as other
miscellaneous functions.
For device state control (enable/disable), each device control is assigned an
id which is used by individual device drivers to control the state as needed.
Required properties:
- compatible: must be "ti,c64x+dscr"
- reg: register area base and size
Optional properties:
NOTE: These are optional in that not all SoCs will have all properties. For
SoCs which do support a given property, leaving the property out of the
device tree will result in reduced functionality or possibly driver
failure.
- ti,dscr-devstat
offset of the devstat register
- ti,dscr-silicon-rev
offset, start bit, and bitsize of silicon revision field
- ti,dscr-rmii-resets
offset and bitmask of RMII reset field. May have multiple tuples if more
than one ethernet port is available.
- ti,dscr-locked-regs
possibly multiple tuples describing registers which are write protected by
a lock register. Each tuple consists of the register offset, lock register
offsset, and the key value used to unlock the register.
- ti,dscr-kick-regs
offset and key values of two "kick" registers used to write protect other
registers in DSCR. On SoCs using kick registers, the first key must be
written to the first kick register and the second key must be written to
the second register before other registers in the area are write-enabled.
- ti,dscr-mac-fuse-regs
MAC addresses are contained in two registers. Each element of a MAC address
is contained in a single byte. This property has two tuples. Each tuple has
a register offset and four cells representing bytes in the register from
most significant to least. The value of these four cells is the MAC byte
index (1-6) of the byte within the register. A value of 0 means the byte
is unused in the MAC address.
- ti,dscr-devstate-ctl-regs
This property describes the bitfields used to control the state of devices.
Each tuple describes a range of identical bitfields used to control one or
more devices (one bitfield per device). The layout of each tuple is:
start_id num_ids reg enable disable start_bit nbits
Where:
start_id is device id for the first device control in the range
num_ids is the number of device controls in the range
reg is the offset of the register holding the control bits
enable is the value to enable a device
disable is the value to disable a device (0xffffffff if cannot disable)
start_bit is the bit number of the first bit in the range
nbits is the number of bits per device control
- ti,dscr-devstate-stat-regs
This property describes the bitfields used to provide device state status
for device states controlled by the DSCR. Each tuple describes a range of
identical bitfields used to provide status for one or more devices (one
bitfield per device). The layout of each tuple is:
start_id num_ids reg enable disable start_bit nbits
Where:
start_id is device id for the first device status in the range
num_ids is the number of devices covered by the range
reg is the offset of the register holding the status bits
enable is the value indicating device is enabled
disable is the value indicating device is disabled
start_bit is the bit number of the first bit in the range
nbits is the number of bits per device status
- ti,dscr-privperm
Offset and default value for register used to set access privilege for
some SoC devices.
Example:
device-state-config-regs@2a80000 {
compatible = "ti,c64x+dscr";
reg = <0x02a80000 0x41000>;
ti,dscr-devstat = <0>;
ti,dscr-silicon-rev = <8 28 0xf>;
ti,dscr-rmii-resets = <0x40020 0x00040000>;
ti,dscr-locked-regs = <0x40008 0x40004 0x0f0a0b00>;
ti,dscr-devstate-ctl-regs =
<0 12 0x40008 1 0 0 2
12 1 0x40008 3 0 30 2
13 2 0x4002c 1 0xffffffff 0 1>;
ti,dscr-devstate-stat-regs =
<0 10 0x40014 1 0 0 3
10 2 0x40018 1 0 0 3>;
ti,dscr-mac-fuse-regs = <0x700 1 2 3 4
0x704 5 6 0 0>;
ti,dscr-privperm = <0x41c 0xaaaaaaaa>;
ti,dscr-kick-regs = <0x38 0x83E70B13
0x3c 0x95A4F1E0>;
};

62
Documentation/devicetree/bindings/c6x/emifa.txt Normal file
View File

@ -0,0 +1,62 @@
External Memory Interface
-------------------------
The emifa node describes a simple external bus controller found on some C6X
SoCs. This interface provides external busses with a number of chip selects.
Required properties:
- compatible: must be "ti,c64x+emifa", "simple-bus"
- reg: register area base and size
- #address-cells: must be 2 (chip-select + offset)
- #size-cells: must be 1
- ranges: mapping from EMIFA space to parent space
Optional properties:
- ti,dscr-dev-enable: Device ID if EMIF is enabled/disabled from DSCR
- ti,emifa-burst-priority:
Number of memory transfers after which the EMIF will elevate the priority
of the oldest command in the command FIFO. Setting this field to 255
disables this feature, thereby allowing old commands to stay in the FIFO
indefinitely.
- ti,emifa-ce-config:
Configuration values for each of the supported chip selects.
Example:
emifa@70000000 {
compatible = "ti,c64x+emifa", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x70000000 0x100>;
ranges = <0x2 0x0 0xa0000000 0x00000008
0x3 0x0 0xb0000000 0x00400000
0x4 0x0 0xc0000000 0x10000000
0x5 0x0 0xD0000000 0x10000000>;
ti,dscr-dev-enable = <13>;
ti,emifa-burst-priority = <255>;
ti,emifa-ce-config = <0x00240120
0x00240120
0x00240122
0x00240122>;
flash@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x3 0x0 0x400000>;
bank-width = <1>;
device-width = <1>;
partition@0 {
reg = <0x0 0x400000>;
label = "NOR";
};
};
};
This shows a flash chip attached to chip select 3.

104
Documentation/devicetree/bindings/c6x/interrupt.txt Normal file
View File

@ -0,0 +1,104 @@
C6X Interrupt Chips
-------------------
* C64X+ Core Interrupt Controller
The core interrupt controller provides 16 prioritized interrupts to the
C64X+ core. Priority 0 and 1 are used for reset and NMI respectively.
Priority 2 and 3 are reserved. Priority 4-15 are used for interrupt
sources coming from outside the core.
Required properties:
--------------------
- compatible: Should be "ti,c64x+core-pic";
- #interrupt-cells: <1>
Interrupt Specifier Definition
------------------------------
Single cell specifying the core interrupt priority level (4-15) where
4 is highest priority and 15 is lowest priority.
Example
-------
core_pic: interrupt-controller@0 {
interrupt-controller;
#interrupt-cells = <1>;
compatible = "ti,c64x+core-pic";
};
* C64x+ Megamodule Interrupt Controller
The megamodule PIC consists of four interrupt mupliplexers each of which
combine up to 32 interrupt inputs into a single interrupt output which
may be cascaded into the core interrupt controller. The megamodule PIC
has a total of 12 outputs cascading into the core interrupt controller.
One for each core interrupt priority level. In addition to the combined
interrupt sources, individual megamodule interrupts may be cascaded to
the core interrupt controller. When an individual interrupt is cascaded,
it is no longer handled through a megamodule interrupt combiner and is
considered to have the core interrupt controller as the parent.
Required properties:
--------------------
- compatible: "ti,c64x+megamod-pic"
- interrupt-controller
- #interrupt-cells: <1>
- reg: base address and size of register area
- interrupt-parent: must be core interrupt controller
- interrupts: This should have four cells; one for each interrupt combiner.
The cells contain the core priority interrupt to which the
corresponding combiner output is wired.
Optional properties:
--------------------
- ti,c64x+megamod-pic-mux: Array of 12 cells correspnding to the 12 core
priority interrupts. The first cell corresponds to
core priority 4 and the last cell corresponds to
core priority 15. The value of each cell is the
megamodule interrupt source which is MUXed to
the core interrupt corresponding to the cell
position. Allowed values are 4 - 127. Mapping for
interrupts 0 - 3 (combined interrupt sources) are
ignored.
Interrupt Specifier Definition
------------------------------
Single cell specifying the megamodule interrupt source (4-127). Note that
interrupts mapped directly to the core with "ti,c64x+megamod-pic-mux" will
use the core interrupt controller as their parent and the specifier will
be the core priority level, not the megamodule interrupt number.
Examples
--------
megamod_pic: interrupt-controller@1800000 {
compatible = "ti,c64x+megamod-pic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x1800000 0x1000>;
interrupt-parent = <&core_pic>;
interrupts = < 12 13 14 15 >;
};
This is a minimal example where all individual interrupts go through a
combiner. Combiner-0 is mapped to core interrupt 12, combiner-1 is mapped
to interrupt 13, etc.
megamod_pic: interrupt-controller@1800000 {
compatible = "ti,c64x+megamod-pic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x1800000 0x1000>;
interrupt-parent = <&core_pic>;
interrupts = < 12 13 14 15 >;
ti,c64x+megamod-pic-mux = < 0 0 0 0
32 0 0 0
0 0 0 0 >;
};
This the same as the first example except that megamodule interrupt 32 is
mapped directly to core priority interrupt 8. The node using this interrupt
must set the core controller as its interrupt parent and use 8 in the
interrupt specifier value.

28
Documentation/devicetree/bindings/c6x/soc.txt Normal file
View File

@ -0,0 +1,28 @@
C6X System-on-Chip
------------------
Required properties:
- compatible: "simple-bus"
- #address-cells: must be 1
- #size-cells: must be 1
- ranges
Optional properties:
- model: specific SoC model
- nodes for IP blocks within SoC
Example:
soc {
compatible = "simple-bus";
model = "tms320c6455";
#address-cells = <1>;
#size-cells = <1>;
ranges;
...
};

26
Documentation/devicetree/bindings/c6x/timer64.txt Normal file
View File

@ -0,0 +1,26 @@
Timer64
-------
The timer64 node describes C6X event timers.
Required properties:
- compatible: must be "ti,c64x+timer64"
- reg: base address and size of register region
- interrupt-parent: interrupt controller
- interrupts: interrupt id
Optional properties:
- ti,dscr-dev-enable: Device ID used to enable timer IP through DSCR interface.
- ti,core-mask: on multi-core SoCs, bitmask of cores allowed to use this timer.
Example:
timer0: timer@25e0000 {
compatible = "ti,c64x+timer64";
ti,core-mask = < 0x01 >;
reg = <0x25e0000 0x40>;
interrupt-parent = <&megamod_pic>;
interrupts = < 16 >;
};

30
Documentation/devicetree/bindings/dma/arm-pl330.txt Normal file
View File

@ -0,0 +1,30 @@
* ARM PrimeCell PL330 DMA Controller
The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
between memory and peripherals or memory to memory.
Required properties:
- compatible: should include both "arm,pl330" and "arm,primecell".
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
Example:
pdma0: pdma@12680000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
mem-to-dev) should specify the DMA channel numbers using a two-value pair
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
where 'dma request id' is the dma request number which is connected
to the client controller. The 'property name' is recommended to be
of the form <name>-dma-channel.
Example: tx-dma-channel = <&pdma0 12>;

40
Documentation/devicetree/bindings/gpio/gpio-samsung.txt Normal file
View File

@ -0,0 +1,40 @@
Samsung Exynos4 GPIO Controller
Required properties:
- compatible: Compatible property value should be "samsung,exynos4-gpio>".
- reg: Physical base address of the controller and length of memory mapped
region.
- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
should be the following with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[pull up/down]
[drive strength]>
Values for gpio specifier:
- Pin number: is a value between 0 to 7.
- Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
- Drive Strength: 0 - 1x,
1 - 3x,
2 - 2x,
3 - 4x
- gpio-controller: Specifies that the node is a gpio controller.
- #address-cells: should be 1.
- #size-cells: should be 1.
Example:
gpa0: gpio-controller@11400000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,exynos4-gpio";
reg = <0x11400000 0x20>;
#gpio-cells = <4>;
gpio-controller;
};

22
Documentation/devicetree/bindings/i2c/i2c-designware.txt Normal file
View File

@ -0,0 +1,22 @@
* Synopsys DesignWare I2C
Required properties :
- compatible : should be "snps,designware-i2c"
- reg : Offset and length of the register set for the device
- interrupts : <IRQ> where IRQ is the interrupt number.
Recommended properties :
- clock-frequency : desired I2C bus clock frequency in Hz.
Example :
i2c@f0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,designware-i2c";
reg = <0xf0000 0x1000>;
interrupts = <11>;
clock-frequency = <400000>;
};

58
Documentation/devicetree/bindings/i2c/trivial-devices.txt Normal file
View File

@ -0,0 +1,58 @@
This is a list of trivial i2c devices that have simple device tree
bindings, consisting only of a compatible field, an address and
possibly an interrupt line.
If a device needs more specific bindings, such as properties to
describe some aspect of it, there needs to be a specific binding
document for it just like any other devices.
Compatible Vendor / Chip
========== =============
ad,ad7414 SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin
ad,adm9240 ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems
adi,adt7461 +/-1C TDM Extended Temp Range I.C
adt7461 +/-1C TDM Extended Temp Range I.C
at,24c08 i2c serial eeprom (24cxx)
atmel,24c02 i2c serial eeprom (24cxx)
catalyst,24c32 i2c serial eeprom
dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock
dallas,ds1338 I2C RTC with 56-Byte NV RAM
dallas,ds1339 I2C Serial Real-Time Clock
dallas,ds1340 I2C RTC with Trickle Charger
dallas,ds1374 I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output
dallas,ds1631 High-Precision Digital Thermometer
dallas,ds1682 Total-Elapsed-Time Recorder with Alarm
dallas,ds1775 Tiny Digital Thermometer and Thermostat
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
dallas,ds75 Digital Thermometer and Thermostat
dialog,da9053 DA9053: flexible system level PMIC with multicore support
epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
mc,rv3029c2 Real Time Clock Module with I2C-Bus
national,lm75 I2C TEMP SENSOR
national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
national,lm92 ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface
nxp,pca9556 Octal SMBus and I2C registered interface
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
nxp,pcf8563 Real-time clock/calendar
ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus
pericom,pt7c4338 Real-time Clock Module
plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
ramtron,24c64 i2c serial eeprom (24cxx)
ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
st-micro,24c256 i2c serial eeprom (24cxx)
stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
ti,tsc2003 I2C Touch-Screen Controller

88
Documentation/devicetree/bindings/input/samsung-keypad.txt Normal file
View File

@ -0,0 +1,88 @@
* Samsung's Keypad Controller device tree bindings
Samsung's Keypad controller is used to interface a SoC with a matrix-type
keypad device. The keypad controller supports multiple row and column lines.
A key can be placed at each intersection of a unique row and a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
Required SoC Specific Properties:
- compatible: should be one of the following
- "samsung,s3c6410-keypad": For controllers compatible with s3c6410 keypad
controller.
- "samsung,s5pv210-keypad": For controllers compatible with s5pv210 keypad
controller.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
Required Board Specific Properties:
- samsung,keypad-num-rows: Number of row lines connected to the keypad
controller.
- samsung,keypad-num-columns: Number of column lines connected to the
keypad controller.
- row-gpios: List of gpios used as row lines. The gpio specifier for
this property depends on the gpio controller to which these row lines
are connected.
- col-gpios: List of gpios used as column lines. The gpio specifier for
this property depends on the gpio controller to which these column
lines are connected.
- Keys represented as child nodes: Each key connected to the keypad
controller is represented as a child node to the keypad controller
device node and should include the following properties.
- keypad,row: the row number to which the key is connected.
- keypad,column: the column number to which the key is connected.
- linux,code: the key-code to be reported when the key is pressed
and released.
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
- linux,keypad-wakeup: use any event on keypad as wakeup event.
Example:
keypad@100A0000 {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A0000 0x100>;
interrupts = <173>;
samsung,keypad-num-rows = <2>;
samsung,keypad-num-columns = <8>;
linux,input-no-autorepeat;
linux,input-wakeup;
row-gpios = <&gpx2 0 3 3 0
&gpx2 1 3 3 0>;
col-gpios = <&gpx1 0 3 0 0
&gpx1 1 3 0 0
&gpx1 2 3 0 0
&gpx1 3 3 0 0
&gpx1 4 3 0 0
&gpx1 5 3 0 0
&gpx1 6 3 0 0
&gpx1 7 3 0 0>;
key_1 {
keypad,row = <0>;
keypad,column = <3>;
linux,code = <2>;
};
key_2 {
keypad,row = <0>;
keypad,column = <4>;
linux,code = <3>;
};
key_3 {
keypad,row = <0>;
keypad,column = <5>;
linux,code = <4>;
};
};

18
Documentation/devicetree/bindings/input/tegra-kbc.txt Normal file
View File

@ -0,0 +1,18 @@
* Tegra keyboard controller
Required properties:
- compatible: "nvidia,tegra20-kbc"
Optional properties:
- debounce-delay: delay in milliseconds per row scan for debouncing
- repeat-delay: delay in milliseconds before repeat starts
- ghost-filter: enable ghost filtering for this device
- wakeup-source: configure keyboard as a wakeup source for suspend/resume
Example:
keyboard: keyboard {
compatible = "nvidia,tegra20-kbc";
reg = <0x7000e200 0x100>;
ghost-filter;
};

44
Documentation/devicetree/bindings/mtd/gpio-control-nand.txt Normal file
View File

@ -0,0 +1,44 @@
GPIO assisted NAND flash
The GPIO assisted NAND flash uses a memory mapped interface to
read/write the NAND commands and data and GPIO pins for the control
signals.
Required properties:
- compatible : "gpio-control-nand"
- reg : should specify localbus chip select and size used for the chip. The
resource describes the data bus connected to the NAND flash and all accesses
are made in native endianness.
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
- gpios : specifies the gpio pins to control the NAND device. nwp is an
optional gpio and may be set to 0 if not present.
Optional properties:
- bank-width : Width (in bytes) of the device. If not present, the width
defaults to 1 byte.
- chip-delay : chip dependent delay for transferring data from array to
read registers (tR). If not present then a default of 20us is used.
- gpio-control-nand,io-sync-reg : A 64-bit physical address for a read
location used to guard against bus reordering with regards to accesses to
the GPIO's and the NAND flash data bus. If present, then after changing
GPIO state and before and after command byte writes, this register will be
read to ensure that the GPIO accesses have completed.
Examples:
gpio-nand@1,0 {
compatible = "gpio-control-nand";
reg = <1 0x0000 0x2>;
#address-cells = <1>;
#size-cells = <1>;
gpios = <&banka 1 0 /* rdy */
&banka 2 0 /* nce */
&banka 3 0 /* ale */
&banka 4 0 /* cle */
0 /* nwp */>;
partition@0 {
...
};
};

25
Documentation/devicetree/bindings/net/macb.txt Normal file
View File

@ -0,0 +1,25 @@
* Cadence MACB/GEM Ethernet controller
Required properties:
- compatible: Should be "cdns,[<chip>-]{macb|gem}"
Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
Optional properties:
- local-mac-address: 6 bytes, mac address
Examples:
macb0: ethernet@fffc4000 {
compatible = "cdns,at32ap7000-macb";
reg = <0xfffc4000 0x4000>;
interrupts = <21>;
phy-mode = "rmii";
local-mac-address = [3a 0e 03 04 05 06];
};

9
Documentation/devicetree/bindings/nvec/nvec_nvidia.txt Normal file
View File

@ -0,0 +1,9 @@
NVIDIA compliant embedded controller
Required properties:
- compatible : should be "nvidia,nvec".
- reg : the iomem of the i2c slave controller
- interrupts : the interrupt line of the i2c slave controller
- clock-frequency : the frequency of the i2c bus
- gpios : the gpio used for ec request
- slave-addr: the i2c address of the slave controller

5
Documentation/devicetree/bindings/power_supply/olpc_battery.txt Normal file
View File

@ -0,0 +1,5 @@
OLPC battery
~~~~~~~~~~~~
Required properties:
- compatible : "olpc,xo1-battery"

23
Documentation/devicetree/bindings/power_supply/sbs_sbs-battery.txt Normal file
View File

@ -0,0 +1,23 @@
SBS sbs-battery
~~~~~~~~~~
Required properties :
- compatible : "sbs,sbs-battery"
Optional properties :
- sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
IO failure.
- sbs,poll-retry-count : The number of times to try looking for new status
after an external change notification.
- sbs,battery-detect-gpios : The gpio which signals battery detection and
a flag specifying its polarity.
Example:
bq20z75@b {
compatible = "sbs,sbs-battery";
reg = < 0xb >;
sbs,i2c-retry-count = <2>;
sbs,poll-retry-count = <10>;
sbs,battery-detect-gpios = <&gpio-controller 122 1>;
}

163
Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt Normal file
View File

@ -0,0 +1,163 @@
Message unit node:
For SRIO controllers that implement the message unit as part of the controller
this node is required. For devices with RMAN this node should NOT exist. The
node is composed of three types of sub-nodes ("fsl-srio-msg-unit",
"fsl-srio-dbell-unit" and "fsl-srio-port-write-unit").
See srio.txt for more details about generic SRIO controller details.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio-rmu-vX.Y", "fsl,srio-rmu".
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- fsl,liodn
Usage: optional-but-recommended (for devices with PAMU)
Value type: <prop-encoded-array>
Definition: The logical I/O device number for the PAMU (IOMMU) to be
correctly configured for SRIO accesses. The property should
not exist on devices that do not support PAMU.
The LIODN value is associated with all RMU transactions
(msg-unit, doorbell, port-write).
Sub-Nodes for RMU: The RMU node is composed of multiple sub-nodes that
correspond to the actual sub-controllers in the RMU. The manual for a given
SoC will detail which and how many of these sub-controllers are implemented.
Message Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio-msg-unit-vX.Y", "fsl,srio-msg-unit".
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A pair of IRQs are specified in this property. The first
element is associated with the transmit (TX) interrupt and the
second element is associated with the receive (RX) interrupt.
Doorbell Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include:
"fsl,srio-dbell-unit-vX.Y", "fsl,srio-dbell-unit"
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A pair of IRQs are specified in this property. The first
element is associated with the transmit (TX) interrupt and the
second element is associated with the receive (RX) interrupt.
Port-Write Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include:
"fsl,srio-port-write-unit-vX.Y", "fsl,srio-port-write-unit"
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A single IRQ that handles port-write conditions is
specified by this property. (Typically shared with error).
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
Example:
rmu: rmu@d3000 {
compatible = "fsl,srio-rmu";
reg = <0xd3000 0x400>;
ranges = <0x0 0xd3000 0x400>;
fsl,liodn = <0xc8>;
message-unit@0 {
compatible = "fsl,srio-msg-unit";
reg = <0x0 0x100>;
interrupts = <
60 2 0 0 /* msg1_tx_irq */
61 2 0 0>;/* msg1_rx_irq */
};
message-unit@100 {
compatible = "fsl,srio-msg-unit";
reg = <0x100 0x100>;
interrupts = <
62 2 0 0 /* msg2_tx_irq */
63 2 0 0>;/* msg2_rx_irq */
};
doorbell-unit@400 {
compatible = "fsl,srio-dbell-unit";
reg = <0x400 0x80>;
interrupts = <
56 2 0 0 /* bell_outb_irq */
57 2 0 0>;/* bell_inb_irq */
};
port-write-unit@4e0 {
compatible = "fsl,srio-port-write-unit";
reg = <0x4e0 0x20>;
interrupts = <16 2 1 11>;
};
};

103
Documentation/devicetree/bindings/powerpc/fsl/srio.txt Normal file
View File

@ -0,0 +1,103 @@
* Freescale Serial RapidIO (SRIO) Controller
RapidIO port node:
Properties:
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio" for IP blocks with IP Block
Revision Register (SRIO IPBRR1) Major ID equal to 0x01c0.
Optionally, a compatiable string of "fsl,srio-vX.Y" where X is Major
version in IP Block Revision Register and Y is Minor version. If this
compatiable is provided it should be ordered before "fsl,srio".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers. The size should
be set to 0x11000.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A single IRQ that handles error conditions is specified by this
property. (Typically shared with port-write).
- fsl,srio-rmu-handle:
Usage: required if rmu node is defined
Value type: <phandle>
Definition: A single <phandle> value that points to the RMU.
(See srio-rmu.txt for more details on RMU node binding)
Port Child Nodes: There should a port child node for each port that exists in
the controller. The ports are numbered starting at one (1) and should have
the following properties:
- cell-index
Usage: required
Value type: <u32>
Definition: A standard property. Matches the port id.
- ranges
Usage: required if local access windows preset
Value type: <prop-encoded-array>
Definition: A standard property. Utilized to describe the memory mapped
IO space utilized by the controller. This corresponds to the
setting of the local access windows that are targeted to this
SRIO port.
- fsl,liodn
Usage: optional-but-recommended (for devices with PAMU)
Value type: <prop-encoded-array>
Definition: The logical I/O device number for the PAMU (IOMMU) to be
correctly configured for SRIO accesses. The property should
not exist on devices that do not support PAMU.
For HW (ie, the P4080) that only supports a LIODN for both
memory and maintenance transactions then a single LIODN is
represented in the property for both transactions.
For HW (ie, the P304x/P5020, etc) that supports an LIODN for
memory transactions and a unique LIODN for maintenance
transactions then a pair of LIODNs are represented in the
property. Within the pair, the first element represents the
LIODN associated with memory transactions and the second element
represents the LIODN associated with maintenance transactions
for the port.
Note: All other standard properties (see ePAPR) are allowed but are optional.
Example:
rapidio: rapidio@ffe0c0000 {
#address-cells = <2>;
#size-cells = <2>;
reg = <0xf 0xfe0c0000 0 0x11000>;
compatible = "fsl,srio";
interrupts = <16 2 1 11>; /* err_irq */
fsl,srio-rmu-handle = <&rmu>;
ranges;
port1 {
cell-index = <1>;
#address-cells = <2>;
#size-cells = <2>;
fsl,liodn = <34>;
ranges = <0 0 0xc 0x20000000 0 0x10000000>;
};
port2 {
cell-index = <2>;
#address-cells = <2>;
#size-cells = <2>;
fsl,liodn = <48>;
ranges = <0 0 0xc 0x30000000 0 0x10000000>;
};
};

29
Documentation/devicetree/bindings/regulator/fixed-regulator.txt Normal file
View File

@ -0,0 +1,29 @@
Fixed Voltage regulators
Required properties:
- compatible: Must be "regulator-fixed";
Optional properties:
- gpio: gpio to use for enable control
- startup-delay-us: startup time in microseconds
- enable-active-high: Polarity of GPIO is Active high
If this property is missing, the default assumed is Active low.
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
However a fixed voltage regulator is expected to have the
regulator-min-microvolt and regulator-max-microvolt
to be the same.
Example:
abc: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "fixed-supply";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
gpio = <&gpio1 16 0>;
startup-delay-us = <70000>;
enable-active-high;
regulator-boot-on
};

54
Documentation/devicetree/bindings/regulator/regulator.txt Normal file
View File

@ -0,0 +1,54 @@
Voltage/Current Regulators
Optional properties:
- regulator-name: A string used as a descriptive name for regulator outputs
- regulator-min-microvolt: smallest voltage consumers may set
- regulator-max-microvolt: largest voltage consumers may set
- regulator-microvolt-offset: Offset applied to voltages to compensate for voltage drops
- regulator-min-microamp: smallest current consumers may set
- regulator-max-microamp: largest current consumers may set
- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator
- <name>-supply: phandle to the parent supply/regulator node
Example:
xyzreg: regulator@0 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <2500000>;
regulator-always-on;
vin-supply = <&vin>;
};
Regulator Consumers:
Consumer nodes can reference one or more of its supplies/
regulators using the below bindings.
- <name>-supply: phandle to the regulator node
These are the same bindings that a regulator in the above
example used to reference its own supply, in which case
its just seen as a special case of a regulator being a
consumer itself.
Example of a consumer device node (mmc) referencing two
regulators (twl_reg1 and twl_reg2),
twl_reg1: regulator@0 {
...
...
...
};
twl_reg2: regulator@1 {
...
...
...
};
mmc: mmc@0x0 {
...
...
vmmc-supply = <&twl_reg1>;
vmmcaux-supply = <&twl_reg2>;
};

20
Documentation/devicetree/bindings/rtc/s3c-rtc.txt Normal file
View File

@ -0,0 +1,20 @@
* Samsung's S3C Real Time Clock controller
Required properties:
- compatible: should be one of the following.
* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
interrupt number is the rtc alarm interupt and second interrupt number
is the rtc tick interrupt. The number of cells representing a interrupt
depends on the parent interrupt controller.
Example:
rtc@10070000 {
compatible = "samsung,s3c6410-rtc";
reg = <0x10070000 0x100>;
interrupts = <44 0 45 0>;
};

12
Documentation/devicetree/bindings/rtc/twl-rtc.txt Normal file
View File

@ -0,0 +1,12 @@
* TI twl RTC
The TWL family (twl4030/6030) contains a RTC.
Required properties:
- compatible : Should be twl4030-rtc
Examples:
rtc@0 {
compatible = "ti,twl4030-rtc";
};

10
Documentation/devicetree/bindings/serial/omap_serial.txt Normal file
View File

@ -0,0 +1,10 @@
OMAP UART controller
Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
- ti,hwmods : Must be "uart<n>", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART

14
Documentation/devicetree/bindings/serial/samsung_uart.txt Normal file
View File

@ -0,0 +1,14 @@
* Samsung's UART Controller
The Samsung's UART controller is used for interfacing SoC with serial communicaion
devices.
Required properties:
- compatible: should be
- "samsung,exynos4210-uart", for UART's compatible with Exynos4210 uart ports.
- reg: base physical address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu. The interrupt specifier format depends
on the interrupt controller parent.

71
Documentation/devicetree/bindings/sound/tegra-audio-wm8903.txt Normal file
View File

@ -0,0 +1,71 @@
NVIDIA Tegra audio complex
Required properties:
- compatible : "nvidia,tegra-audio-wm8903"
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the WM8903's pins, and the jacks on the board:
WM8903 pins:
* IN1L
* IN1R
* IN2L
* IN2R
* IN3L
* IN3R
* DMICDAT
* HPOUTL
* HPOUTR
* LINEOUTL
* LINEOUTR
* LOP
* LON
* ROP
* RON
* MICBIAS
Board connectors:
* Headphone Jack
* Int Spk
* Mic Jack
- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller
- nvidia,audio-codec : The phandle of the WM8903 audio codec
Optional properties:
- nvidia,spkr-en-gpios : The GPIO that enables the speakers
- nvidia,hp-mute-gpios : The GPIO that mutes the headphones
- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in
- nvidia,int-mic-en-gpios : The GPIO that enables the internal microphone
- nvidia,ext-mic-en-gpios : The GPIO that enables the external microphone
Example:
sound {
compatible = "nvidia,tegra-audio-wm8903-harmony",
"nvidia,tegra-audio-wm8903"
nvidia,model = "tegra-wm8903-harmony";
nvidia,audio-routing =
"Headphone Jack", "HPOUTR",
"Headphone Jack", "HPOUTL",
"Int Spk", "ROP",
"Int Spk", "RON",
"Int Spk", "LOP",
"Int Spk", "LON",
"Mic Jack", "MICBIAS",
"IN1L", "Mic Jack";
nvidia,i2s-controller = <&i2s1>;
nvidia,audio-codec = <&wm8903>;
nvidia,spkr-en-gpios = <&codec 2 0>;
nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */
nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */
nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */
};

12
Documentation/devicetree/bindings/sound/tegra20-das.txt Normal file
View File

@ -0,0 +1,12 @@
NVIDIA Tegra 20 DAS (Digital Audio Switch) controller
Required properties:
- compatible : "nvidia,tegra20-das"
- reg : Should contain DAS registers location and length
Example:
das@70000c00 {
compatible = "nvidia,tegra20-das";
reg = <0x70000c00 0x80>;
};

17
Documentation/devicetree/bindings/sound/tegra20-i2s.txt Normal file
View File

@ -0,0 +1,17 @@
NVIDIA Tegra 20 I2S controller
Required properties:
- compatible : "nvidia,tegra20-i2s"
- reg : Should contain I2S registers location and length
- interrupts : Should contain I2S interrupt
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
request selector for this I2S controller
Example:
i2s@70002800 {
compatible = "nvidia,tegra20-i2s";
reg = <0x70002800 0x200>;
interrupts = < 45 >;
nvidia,dma-request-selector = < &apbdma 2 >;
};

50
Documentation/devicetree/bindings/sound/wm8903.txt Normal file
View File

@ -0,0 +1,50 @@
WM8903 audio CODEC
This device supports I2C only.
Required properties:
- compatible : "wlf,wm8903"
- reg : the I2C address of the device.
- gpio-controller : Indicates this device is a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
Optional properties:
- interrupts : The interrupt line the codec is connected to.
- micdet-cfg : Default register value for R6 (Mic Bias). If absent, the
default is 0.
- micdet-delay : The debounce delay for microphone detection in mS. If
absent, the default is 100.
- gpio-cfg : A list of GPIO configuration register values. The list must
be 5 entries long. If absent, no configuration of these registers is
performed. If any entry has the value 0xffffffff, that GPIO's
configuration will not be modified.
Example:
codec: wm8903@1a {
compatible = "wlf,wm8903";
reg = <0x1a>;
interrupts = < 347 >;
gpio-controller;
#gpio-cells = <2>;
micdet-cfg = <0>;
micdet-delay = <100>;
gpio-cfg = <
0x0600 /* DMIC_LR, output */
0x0680 /* DMIC_DAT, input */
0x0000 /* GPIO, output, low */
0x0200 /* Interrupt, output */
0x01a0 /* BCLK, input, active high */
>;
};

18
Documentation/devicetree/bindings/sound/wm8994.txt Normal file
View File

@ -0,0 +1,18 @@
WM1811/WM8994/WM8958 audio CODEC
These devices support both I2C and SPI (configured with pin strapping
on the board).
Required properties:
- compatible : "wlf,wm1811", "wlf,wm8994", "wlf,wm8958"
- reg : the I2C address of the device for I2C, the chip select
number for SPI.
Example:
codec: wm8994@1a {
compatible = "wlf,wm8994";
reg = <0x1a>;
};

13
Documentation/devicetree/bindings/usb/tegra-usb.txt Normal file
View File

@ -0,0 +1,13 @@
Tegra SOC USB controllers
The device node for a USB controller that is part of a Tegra
SOC is as described in the document "Open Firmware Recommended
Practice : Universal Serial Bus" with the following modifications
and additions :
Required properties :
- compatible : Should be "nvidia,tegra20-ehci" for USB controllers
used in host mode.
- phy_type : Should be one of "ulpi" or "utmi".
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
activated for the bus to be powered.

5
Documentation/devicetree/bindings/vendor-prefixes.txt
View File

@ -8,7 +8,9 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
arm ARM Ltd.
atmel Atmel Corporation
cavium Cavium, Inc.
chrp Common Hardware Reference Platform
cortina Cortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
denx Denx Software Engineering
epson Seiko Epson Corp.
@ -32,10 +34,13 @@ powervr Imagination Technologies
qcom Qualcomm, Inc.
ramtron Ramtron International
samsung Samsung Semiconductor
sbs Smart Battery System
schindler Schindler
sil Silicon Image
simtek
sirf SiRF Technology, Inc.
st STMicroelectronics
stericsson ST-Ericsson
ti Texas Instruments
wlf Wolfson Microelectronics
xlnx Xilinx

96
Documentation/digsig.txt Normal file
View File

@ -0,0 +1,96 @@
Digital Signature Verification API
CONTENTS
1. Introduction
2. API
3. User-space utilities
1. Introduction
Digital signature verification API provides a method to verify digital signature.
Currently digital signatures are used by the IMA/EVM integrity protection subsystem.
Digital signature verification is implemented using cut-down kernel port of
GnuPG multi-precision integers (MPI) library. The kernel port provides
memory allocation errors handling, has been refactored according to kernel
coding style, and checkpatch.pl reported errors and warnings have been fixed.
Public key and signature consist of header and MPIs.
struct pubkey_hdr {
uint8_t version; /* key format version */
time_t timestamp; /* key made, always 0 for now */
uint8_t algo;
uint8_t nmpi;
char mpi[0];
} __packed;
struct signature_hdr {
uint8_t version; /* signature format version */
time_t timestamp; /* signature made */
uint8_t algo;
uint8_t hash;
uint8_t keyid[8];
uint8_t nmpi;
char mpi[0];
} __packed;
keyid equals to SHA1[12-19] over the total key content.
Signature header is used as an input to generate a signature.
Such approach insures that key or signature header could not be changed.
It protects timestamp from been changed and can be used for rollback
protection.
2. API
API currently includes only 1 function:
digsig_verify() - digital signature verification with public key
/**
* digsig_verify() - digital signature verification with public key
* @keyring: keyring to search key in
* @sig: digital signature
* @sigen: length of the signature
* @data: data
* @datalen: length of the data
* @return: 0 on success, -EINVAL otherwise
*
* Verifies data integrity against digital signature.
* Currently only RSA is supported.
* Normally hash of the content is used as a data for this function.
*
*/
int digsig_verify(struct key *keyring, const char *sig, int siglen,
const char *data, int datalen);
3. User-space utilities
The signing and key management utilities evm-utils provide functionality
to generate signatures, to load keys into the kernel keyring.
Keys can be in PEM or converted to the kernel format.
When the key is added to the kernel keyring, the keyid defines the name
of the key: 5D2B05FC633EE3E8 in the example bellow.
Here is example output of the keyctl utility.
$ keyctl show
Session Keyring
-3 --alswrv 0 0 keyring: _ses
603976250 --alswrv 0 -1 \_ keyring: _uid.0
817777377 --alswrv 0 0 \_ user: kmk
891974900 --alswrv 0 0 \_ encrypted: evm-key
170323636 --alswrv 0 0 \_ keyring: _module
548221616 --alswrv 0 0 \_ keyring: _ima
128198054 --alswrv 0 0 \_ keyring: _evm
$ keyctl list 128198054
1 key in keyring:
620789745: --alswrv 0 0 user: 5D2B05FC633EE3E8
Dmitry Kasatkin
06.10.2011

224
Documentation/dma-buf-sharing.txt Normal file
View File

@ -0,0 +1,224 @@
DMA Buffer Sharing API Guide
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sumit Semwal
<sumit dot semwal at linaro dot org>
<sumit dot semwal at ti dot com>
This document serves as a guide to device-driver writers on what is the dma-buf
buffer sharing API, how to use it for exporting and using shared buffers.
Any device driver which wishes to be a part of DMA buffer sharing, can do so as
either the 'exporter' of buffers, or the 'user' of buffers.
Say a driver A wants to use buffers created by driver B, then we call B as the
exporter, and A as buffer-user.
The exporter
- implements and manages operations[1] for the buffer
- allows other users to share the buffer by using dma_buf sharing APIs,
- manages the details of buffer allocation,
- decides about the actual backing storage where this allocation happens,
- takes care of any migration of scatterlist - for all (shared) users of this
buffer,
The buffer-user
- is one of (many) sharing users of the buffer.
- doesn't need to worry about how the buffer is allocated, or where.
- needs a mechanism to get access to the scatterlist that makes up this buffer
in memory, mapped into its own address space, so it can access the same area
of memory.
*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
For this first version, A buffer shared using the dma_buf sharing API:
- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
this framework.
- may be used *ONLY* by importers that do not need CPU access to the buffer.
The dma_buf buffer sharing API usage contains the following steps:
1. Exporter announces that it wishes to export a buffer
2. Userspace gets the file descriptor associated with the exported buffer, and
passes it around to potential buffer-users based on use case
3. Each buffer-user 'connects' itself to the buffer
4. When needed, buffer-user requests access to the buffer from exporter
5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
6. when buffer-user is done using this buffer completely, it 'disconnects'
itself from the buffer.
1. Exporter's announcement of buffer export
The buffer exporter announces its wish to export a buffer. In this, it
connects its own private buffer data, provides implementation for operations
that can be performed on the exported dma_buf, and flags for the file
associated with this buffer.
Interface:
struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
size_t size, int flags)
If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a
pointer to the same. It also associates an anonymous file with this buffer,
so it can be exported. On failure to allocate the dma_buf object, it returns
NULL.
2. Userspace gets a handle to pass around to potential buffer-users
Userspace entity requests for a file-descriptor (fd) which is a handle to the
anonymous file associated with the buffer. It can then share the fd with other
drivers and/or processes.
Interface:
int dma_buf_fd(struct dma_buf *dmabuf)
This API installs an fd for the anonymous file associated with this buffer;
returns either 'fd', or error.
3. Each buffer-user 'connects' itself to the buffer
Each buffer-user now gets a reference to the buffer, using the fd passed to
it.
Interface:
struct dma_buf *dma_buf_get(int fd)
This API will return a reference to the dma_buf, and increment refcount for
it.
After this, the buffer-user needs to attach its device with the buffer, which
helps the exporter to know of device buffer constraints.
Interface:
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev)
This API returns reference to an attachment structure, which is then used
for scatterlist operations. It will optionally call the 'attach' dma_buf
operation, if provided by the exporter.
The dma-buf sharing framework does the bookkeeping bits related to managing
the list of all attachments to a buffer.
Until this stage, the buffer-exporter has the option to choose not to actually
allocate the backing storage for this buffer, but wait for the first buffer-user
to request use of buffer for allocation.
4. When needed, buffer-user requests access to the buffer
Whenever a buffer-user wants to use the buffer for any DMA, it asks for
access to the buffer using dma_buf_map_attachment API. At least one attach to
the buffer must have happened before map_dma_buf can be called.
Interface:
struct sg_table * dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
This is a wrapper to dma_buf->ops->map_dma_buf operation, which hides the
"dma_buf->ops->" indirection from the users of this interface.
In struct dma_buf_ops, map_dma_buf is defined as
struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *,
enum dma_data_direction);
It is one of the buffer operations that must be implemented by the exporter.
It should return the sg_table containing scatterlist for this buffer, mapped
into caller's address space.
If this is being called for the first time, the exporter can now choose to
scan through the list of attachments for this buffer, collate the requirements
of the attached devices, and choose an appropriate backing storage for the
buffer.
Based on enum dma_data_direction, it might be possible to have multiple users
accessing at the same time (for reading, maybe), or any other kind of sharing
that the exporter might wish to make available to buffer-users.
map_dma_buf() operation can return -EINTR if it is interrupted by a signal.
5. When finished, the buffer-user notifies end-of-DMA to exporter
Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to
the exporter using the dma_buf_unmap_attachment API.
Interface:
void dma_buf_unmap_attachment(struct dma_buf_attachment *,
struct sg_table *);
This is a wrapper to dma_buf->ops->unmap_dma_buf() operation, which hides the
"dma_buf->ops->" indirection from the users of this interface.
In struct dma_buf_ops, unmap_dma_buf is defined as
void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *);
unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like
map_dma_buf, this API also must be implemented by the exporter.
6. when buffer-user is done using this buffer, it 'disconnects' itself from the
buffer.
After the buffer-user has no more interest in using this buffer, it should
disconnect itself from the buffer:
- it first detaches itself from the buffer.
Interface:
void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);
This API removes the attachment from the list in dmabuf, and optionally calls
dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits.
- Then, the buffer-user returns the buffer reference to exporter.
Interface:
void dma_buf_put(struct dma_buf *dmabuf);
This API then reduces the refcount for this buffer.
If, as a result of this call, the refcount becomes 0, the 'release' file
operation related to this fd is called. It calls the dmabuf->ops->release()
operation in turn, and frees the memory allocated for dmabuf when exported.
NOTES:
- Importance of attach-detach and {map,unmap}_dma_buf operation pairs
The attach-detach calls allow the exporter to figure out backing-storage
constraints for the currently-interested devices. This allows preferential
allocation, and/or migration of pages across different types of storage
available, if possible.
Bracketing of DMA access with {map,unmap}_dma_buf operations is essential
to allow just-in-time backing of storage, and migration mid-way through a
use-case.
- Migration of backing storage if needed
If after
- at least one map_dma_buf has happened,
- and the backing storage has been allocated for this buffer,
another new buffer-user intends to attach itself to this buffer, it might
be allowed, if possible for the exporter.
In case it is allowed by the exporter:
if the new buffer-user has stricter 'backing-storage constraints', and the
exporter can handle these constraints, the exporter can just stall on the
map_dma_buf until all outstanding access is completed (as signalled by
unmap_dma_buf).
Once all users have finished accessing and have unmapped this buffer, the
exporter could potentially move the buffer to the stricter backing-storage,
and then allow further {map,unmap}_dma_buf operations from any buffer-user
from the migrated backing-storage.
If the exporter cannot fulfil the backing-storage constraints of the new
buffer-user device as requested, dma_buf_attach() would return an error to
denote non-compatibility of the new buffer-sharing request with the current
buffer.
If the exporter chooses not to allow an attach() operation once a
map_dma_buf() API has been called, it simply returns an error.
References:
[1] struct dma_buf_ops in include/linux/dma-buf.h
[2] All interfaces mentioned above defined in include/linux/dma-buf.h

1
Documentation/dontdiff
View File

@ -66,7 +66,6 @@ GRTAGS
GSYMS
GTAGS
Image
Kerntypes
Module.markers
Module.symvers
PENDING

1
Documentation/driver-model/devres.txt
View File

@ -262,6 +262,7 @@ IOMAP
devm_ioremap()
devm_ioremap_nocache()
devm_iounmap()
devm_request_and_ioremap() : checks resource, requests region, ioremaps
pcim_iomap()
pcim_iounmap()
pcim_iomap_table() : array of mapped addresses indexed by BAR

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

@ -85,17 +85,6 @@ Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
---------------------------
What: Deprecated snapshot ioctls
When: 2.6.36
Why: The ioctls in kernel/power/user.c were marked as deprecated long time
ago. Now they notify users about that so that they need to replace
their userspace. After some more time, remove them completely.
Who: Jiri Slaby <jirislaby@gmail.com>
---------------------------
What: The ieee80211_regdom module parameter
When: March 2010 / desktop catchup
@ -361,15 +350,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
----------------------------
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
on newer and older hardware. It is already not exposed to the guest,
and kept only for live migration purposes.
Who: Avi Kivity <avi@redhat.com>
----------------------------
What: iwlwifi 50XX module parameters
When: 3.0
Why: The "..50" modules parameters were used to configure 5000 series and
@ -534,6 +514,20 @@ Why: In 3.0, we can now autodetect internal 3G device and already have
information log when acer-wmi initial.
Who: Lee, Chun-Yi <jlee@novell.com>
---------------------------
What: /sys/devices/platform/_UDC_/udc/_UDC_/is_dualspeed file and
is_dualspeed line in /sys/devices/platform/ci13xxx_*/udc/device file.
When: 3.8
Why: The is_dualspeed file is superseded by maximum_speed in the same
directory and is_dualspeed line in device file is superseded by
max_speed line in the same file.
The maximum_speed/max_speed specifies maximum speed supported by UDC.
To check if dualspeeed is supported, check if the value is >= 3.
Various possible speeds are defined in <linux/usb/ch9.h>.
Who: Michal Nazarewicz <mina86@mina86.com>
----------------------------
What: The XFS nodelaylog mount option
@ -550,3 +544,15 @@ When: 3.5
Why: The iwlagn module has been renamed iwlwifi. The alias will be around
for backward compatibility for several cycles and then dropped.
Who: Don Fry <donald.h.fry@intel.com>
----------------------------
What: pci_scan_bus_parented()
When: 3.5
Why: The pci_scan_bus_parented() interface creates a new root bus. The
bus is created with default resources (ioport_resource and
iomem_resource) that are always wrong, so we rely on arch code to
correct them later. Callers of pci_scan_bus_parented() should
convert to using pci_scan_root_bus() so they can supply a list of
bus resources when the bus is created.
Who: Bjorn Helgaas <bhelgaas@google.com>

8
Documentation/filesystems/Locking
View File

@ -37,15 +37,15 @@ d_manage: no no yes (ref-walk) maybe
--------------------------- inode_operations ---------------------------
prototypes:
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
int (*create) (struct inode *,struct dentry *,umode_t, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameid
ata *);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
int (*mkdir) (struct inode *,struct dentry *,int);
int (*mkdir) (struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
int (*rename) (struct inode *, struct dentry *,
struct inode *, struct dentry *);
int (*readlink) (struct dentry *, char __user *,int);
@ -117,7 +117,7 @@ prototypes:
int (*statfs) (struct dentry *, struct kstatfs *);
int (*remount_fs) (struct super_block *, int *, char *);
void (*umount_begin) (struct super_block *);
int (*show_options)(struct seq_file *, struct vfsmount *);
int (*show_options)(struct seq_file *, struct dentry *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);

2
Documentation/filesystems/configfs/configfs.txt
View File

@ -192,7 +192,7 @@ attribute value uses the store_attribute() method.
struct configfs_attribute {
char *ca_name;
struct module *ca_owner;
mode_t ca_mode;
umode_t ca_mode;
};
When a config_item wants an attribute to appear as a file in the item's

56
Documentation/filesystems/debugfs.txt
View File

@ -35,7 +35,7 @@ described below will work.
The most general way to create a file within a debugfs directory is with:
struct dentry *debugfs_create_file(const char *name, mode_t mode,
struct dentry *debugfs_create_file(const char *name, umode_t mode,
struct dentry *parent, void *data,
const struct file_operations *fops);
@ -53,13 +53,13 @@ actually necessary; the debugfs code provides a number of helper functions
for simple situations. Files containing a single integer value can be
created with any of:
struct dentry *debugfs_create_u8(const char *name, mode_t mode,
struct dentry *debugfs_create_u8(const char *name, umode_t mode,
struct dentry *parent, u8 *value);
struct dentry *debugfs_create_u16(const char *name, mode_t mode,
struct dentry *debugfs_create_u16(const char *name, umode_t mode,
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
struct dentry *debugfs_create_u32(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
struct dentry *debugfs_create_u64(const char *name, mode_t mode,
struct dentry *debugfs_create_u64(const char *name, umode_t mode,
struct dentry *parent, u64 *value);
These files support both reading and writing the given value; if a specific
@ -67,13 +67,13 @@ file should not be written to, simply set the mode bits accordingly. The
values in these files are in decimal; if hexadecimal is more appropriate,
the following functions can be used instead:
struct dentry *debugfs_create_x8(const char *name, mode_t mode,
struct dentry *debugfs_create_x8(const char *name, umode_t mode,
struct dentry *parent, u8 *value);
struct dentry *debugfs_create_x16(const char *name, mode_t mode,
struct dentry *debugfs_create_x16(const char *name, umode_t mode,
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_x32(const char *name, mode_t mode,
struct dentry *debugfs_create_x32(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
struct dentry *debugfs_create_x64(const char *name, mode_t mode,
struct dentry *debugfs_create_x64(const char *name, umode_t mode,
struct dentry *parent, u64 *value);
These functions are useful as long as the developer knows the size of the
@ -81,7 +81,7 @@ value to be exported. Some types can have different widths on different
architectures, though, complicating the situation somewhat. There is a
function meant to help out in one special case:
struct dentry *debugfs_create_size_t(const char *name, mode_t mode,
struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *parent,
size_t *value);
@ -90,21 +90,22 @@ a variable of type size_t.
Boolean values can be placed in debugfs with:
struct dentry *debugfs_create_bool(const char *name, mode_t mode,
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent, u32 *value);
A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
lower-case values, or 1 or 0. Any other input will be silently ignored.
Finally, a block of arbitrary binary data can be exported with:
Another option is exporting a block of arbitrary binary data, with
this structure and function:
struct debugfs_blob_wrapper {
void *data;
unsigned long size;
};
struct dentry *debugfs_create_blob(const char *name, mode_t mode,
struct dentry *debugfs_create_blob(const char *name, umode_t mode,
struct dentry *parent,
struct debugfs_blob_wrapper *blob);
@ -115,6 +116,35 @@ can be used to export binary information, but there does not appear to be
any code which does so in the mainline. Note that all files created with
debugfs_create_blob() are read-only.
If you want to dump a block of registers (something that happens quite
often during development, even if little such code reaches mainline.
Debugfs offers two functions: one to make a registers-only file, and
another to insert a register block in the middle of another sequential
file.
struct debugfs_reg32 {
char *name;
unsigned long offset;
};
struct debugfs_regset32 {
struct debugfs_reg32 *regs;
int nregs;
void __iomem *base;
};
struct dentry *debugfs_create_regset32(const char *name, mode_t mode,
struct dentry *parent,
struct debugfs_regset32 *regset);
int debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,
int nregs, void __iomem *base, char *prefix);
The "base" argument may be 0, but you may want to build the reg32 array
using __stringify, and a number of register names (macros) are actually
byte offsets over a base for the register block.
There are a couple of other directory-oriented helper functions:
struct dentry *debugfs_rename(struct dentry *old_dir,

7
Documentation/filesystems/ext4.txt
View File

@ -581,6 +581,13 @@ Table of Ext4 specific ioctls
behaviour may change in the future as it is
not necessary and has been done this way only
for sake of simplicity.
EXT4_IOC_RESIZE_FS Resize the filesystem to a new size. The number
of blocks of resized filesystem is passed in via
64 bit integer argument. The kernel allocates
bitmaps and inode table, the userspace tool thus
just passes the new number of blocks.
..............................................................................
References

42
Documentation/filesystems/proc.txt
View File

@ -41,6 +41,8 @@ Table of Contents
3.5 /proc/<pid>/mountinfo - Information about mounts
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
4 Configuring procfs
4.1 Mount options
------------------------------------------------------------------------------
Preface
@ -305,6 +307,9 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
blkio_ticks time spent waiting for block IO
gtime guest time of the task in jiffies
cgtime guest time of the task children in jiffies
start_data address above which program data+bss is placed
end_data address below which program data+bss is placed
start_brk address above which program heap can be expanded with brk()
..............................................................................
The /proc/PID/maps file containing the currently mapped memory regions and
@ -1542,3 +1547,40 @@ a task to set its own or one of its thread siblings comm value. The comm value
is limited in size compared to the cmdline value, so writing anything longer
then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
comm value.
------------------------------------------------------------------------------
Configuring procfs
------------------------------------------------------------------------------
4.1 Mount options
---------------------
The following mount options are supported:
hidepid= Set /proc/<pid>/ access mode.
gid= Set the group authorized to learn processes information.
hidepid=0 means classic mode - everybody may access all /proc/<pid>/ directories
(default).
hidepid=1 means users may not access any /proc/<pid>/ directories but their
own. Sensitive files like cmdline, sched*, status are now protected against
other users. This makes it impossible to learn whether any user runs
specific program (given the program doesn't reveal itself by its behaviour).
As an additional bonus, as /proc/<pid>/cmdline is unaccessible for other users,
poorly written programs passing sensitive information via program arguments are
now protected against local eavesdroppers.
hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible to other
users. It doesn't mean that it hides a fact whether a process with a specific
pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"),
but it hides process' uid and gid, which may be learned by stat()'ing
/proc/<pid>/ otherwise. It greatly complicates an intruder's task of gathering
information about running processes, whether some daemon runs with elevated
privileges, whether other user runs some sensitive program, whether other users
run any program at all, etc.
gid= defines a group authorized to learn processes information otherwise
prohibited by hidepid=. If you use some daemon like identd which needs to learn
information about processes information, just add identd to this group.

2
Documentation/filesystems/sysfs.txt
View File

@ -70,7 +70,7 @@ An attribute definition is simply:
struct attribute {
char * name;
struct module *owner;
mode_t mode;
umode_t mode;
};

8
Documentation/filesystems/vfs.txt
View File

@ -225,7 +225,7 @@ struct super_operations {
void (*clear_inode) (struct inode *);
void (*umount_begin) (struct super_block *);
int (*show_options)(struct seq_file *, struct vfsmount *);
int (*show_options)(struct seq_file *, struct dentry *);
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
@ -341,14 +341,14 @@ This describes how the VFS can manipulate an inode in your
filesystem. As of kernel 2.6.22, the following members are defined:
struct inode_operations {
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
int (*create) (struct inode *,struct dentry *, umode_t, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
int (*mkdir) (struct inode *,struct dentry *,int);
int (*mkdir) (struct inode *,struct dentry *,umode_t);
int (*rmdir) (struct inode *,struct dentry *);
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
int (*rename) (struct inode *, struct dentry *,
struct inode *, struct dentry *);
int (*readlink) (struct dentry *, char __user *,int);

5
Documentation/hwmon/pmbus
View File

@ -2,9 +2,8 @@ Kernel driver pmbus
====================
Supported chips:
* Ericsson BMR45X series
DC/DC Converter
Prefixes: 'bmr450', 'bmr451', 'bmr453', 'bmr454'
* Ericsson BMR453, BMR454
Prefixes: 'bmr453', 'bmr454'
Addresses scanned: -
Datasheet:
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395

15
Documentation/hwmon/zl6100
View File

@ -6,6 +6,10 @@ Supported chips:
Prefix: 'zl2004'
Addresses scanned: -
Datasheet: http://www.intersil.com/data/fn/fn6847.pdf
* Intersil / Zilker Labs ZL2005
Prefix: 'zl2005'
Addresses scanned: -
Datasheet: http://www.intersil.com/data/fn/fn6848.pdf
* Intersil / Zilker Labs ZL2006
Prefix: 'zl2006'
Addresses scanned: -
@ -30,6 +34,17 @@ Supported chips:
Prefix: 'zl6105'
Addresses scanned: -
Datasheet: http://www.intersil.com/data/fn/fn6906.pdf
* Ericsson BMR450, BMR451
Prefix: 'bmr450', 'bmr451'
Addresses scanned: -
Datasheet:
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401
* Ericsson BMR462, BMR463, BMR464
Prefixes: 'bmr462', 'bmr463', 'bmr464'
Addresses scanned: -
Datasheet:
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
Author: Guenter Roeck <guenter.roeck@ericsson.com>

188
Documentation/input/alps.txt Normal file
View File

@ -0,0 +1,188 @@
ALPS Touchpad Protocol
----------------------
Introduction
------------
Currently the ALPS touchpad driver supports four protocol versions in use by
ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
protocol versions is contained in the following sections.
Detection
---------
All ALPS touchpads should respond to the "E6 report" command sequence:
E8-E6-E6-E6-E9. An ALPS touchpad should respond with either 00-00-0A or
00-00-64.
If the E6 report is successful, the touchpad model is identified using the "E7
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
matched against known models in the alps_model_data_array.
With protocol versions 3 and 4, the E7 report model signature is always
73-02-64. To differentiate between these versions, the response from the
"Enter Command Mode" sequence must be inspected as described below.
Command Mode
------------
Protocol versions 3 and 4 have a command mode that is used to read and write
one-byte device registers in a 16-bit address space. The command sequence
EC-EC-EC-E9 places the device in command mode, and the device will respond
with 88-07 followed by a third byte. This third byte can be used to determine
whether the devices uses the version 3 or 4 protocol.
To exit command mode, PSMOUSE_CMD_SETSTREAM (EA) is sent to the touchpad.
While in command mode, register addresses can be set by first sending a
specific command, either EC for v3 devices or F5 for v4 devices. Then the
address is sent one nibble at a time, where each nibble is encoded as a
command with optional data. This enoding differs slightly between the v3 and
v4 protocols.
Once an address has been set, the addressed register can be read by sending
PSMOUSE_CMD_GETINFO (E9). The first two bytes of the response contains the
address of the register being read, and the third contains the value of the
register. Registers are written by writing the value one nibble at a time
using the same encoding used for addresses.
Packet Format
-------------
In the following tables, the following notation is used.
CAPITALS = stick, miniscules = touchpad
?'s can have different meanings on different models, such as wheel rotation,
extra buttons, stick buttons on a dualpoint, etc.
PS/2 packet format
------------------
byte 0: 0 0 YSGN XSGN 1 M R L
byte 1: X7 X6 X5 X4 X3 X2 X1 X0
byte 2: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
Note that the device never signals overflow condition.
ALPS Absolute Mode - Protocol Verion 1
--------------------------------------
byte 0: 1 0 0 0 1 x9 x8 x7
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
byte 2: 0 ? ? l r ? fin ges
byte 3: 0 ? ? ? ? y9 y8 y7
byte 4: 0 y6 y5 y4 y3 y2 y1 y0
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
ALPS Absolute Mode - Protocol Version 2
---------------------------------------
byte 0: 1 ? ? ? 1 ? ? ?
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
byte 2: 0 x10 x9 x8 x7 ? fin ges
byte 3: 0 y9 y8 y7 1 M R L
byte 4: 0 y6 y5 y4 y3 y2 y1 y0
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
Dualpoint device -- interleaved packet format
---------------------------------------------
byte 0: 1 1 0 0 1 1 1 1
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
byte 2: 0 x10 x9 x8 x7 0 fin ges
byte 3: 0 0 YSGN XSGN 1 1 1 1
byte 4: X7 X6 X5 X4 X3 X2 X1 X0
byte 5: Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0
byte 6: 0 y9 y8 y7 1 m r l
byte 7: 0 y6 y5 y4 y3 y2 y1 y0
byte 8: 0 z6 z5 z4 z3 z2 z1 z0
ALPS Absolute Mode - Protocol Version 3
---------------------------------------
ALPS protocol version 3 has three different packet formats. The first two are
associated with touchpad events, and the third is associatd with trackstick
events.
The first type is the touchpad position packet.
byte 0: 1 ? x1 x0 1 1 1 1
byte 1: 0 x10 x9 x8 x7 x6 x5 x4
byte 2: 0 y10 y9 y8 y7 y6 y5 y4
byte 3: 0 M R L 1 m r l
byte 4: 0 mt x3 x2 y3 y2 y1 y0
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
Note that for some devices the trackstick buttons are reported in this packet,
and on others it is reported in the trackstick packets.
The second packet type contains bitmaps representing the x and y axes. In the
bitmaps a given bit is set if there is a finger covering that position on the
given axis. Thus the bitmap packet can be used for low-resolution multi-touch
data, although finger tracking is not possible. This packet also encodes the
number of contacts (f1 and f0 in the table below).
byte 0: 1 1 x1 x0 1 1 1 1
byte 1: 0 x8 x7 x6 x5 x4 x3 x2
byte 2: 0 y7 y6 y5 y4 y3 y2 y1
byte 3: 0 y10 y9 y8 1 1 1 1
byte 4: 0 x14 x13 x12 x11 x10 x9 y0
byte 5: 0 1 ? ? ? ? f1 f0
This packet only appears after a position packet with the mt bit set, and
ususally only appears when there are two or more contacts (although
ocassionally it's seen with only a single contact).
The final v3 packet type is the trackstick packet.
byte 0: 1 1 x7 y7 1 1 1 1
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
byte 2: 0 y6 y5 y4 y3 y2 y1 y0
byte 3: 0 1 0 0 1 0 0 0
byte 4: 0 z4 z3 z2 z1 z0 ? ?
byte 5: 0 0 1 1 1 1 1 1
ALPS Absolute Mode - Protocol Version 4
---------------------------------------
Protocol version 4 has an 8-byte packet format.
byte 0: 1 ? x1 x0 1 1 1 1
byte 1: 0 x10 x9 x8 x7 x6 x5 x4
byte 2: 0 y10 y9 y8 y7 y6 y5 y4
byte 3: 0 1 x3 x2 y3 y2 y1 y0
byte 4: 0 ? ? ? 1 ? r l
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
byte 6: bitmap data (described below)
byte 7: bitmap data (described below)
The last two bytes represent a partial bitmap packet, with 3 full packets
required to construct a complete bitmap packet. Once assembled, the 6-byte
bitmap packet has the following format:
byte 0: 0 1 x7 x6 x5 x4 x3 x2
byte 1: 0 x1 x0 y4 y3 y2 y1 y0
byte 2: 0 0 ? x14 x13 x12 x11 x10
byte 3: 0 x9 x8 y9 y8 y7 y6 y5
byte 4: 0 0 0 0 0 0 0 0
byte 5: 0 0 0 0 0 0 0 y10
There are several things worth noting here.
1) In the bitmap data, bit 6 of byte 0 serves as a sync byte to
identify the first fragment of a bitmap packet.
2) The bitmaps represent the same data as in the v3 bitmap packets, although
the packet layout is different.
3) There doesn't seem to be a count of the contact points anywhere in the v4
protocol packets. Deriving a count of contact points must be done by
analyzing the bitmaps.
4) There is a 3 to 1 ratio of position packets to bitmap packets. Therefore
MT position can only be updated for every third ST position update, and
the count of contact points can only be updated every third packet as
well.
So far no v4 devices with tracksticks have been encountered.

103
Documentation/input/gpio-tilt.txt Normal file
View File

@ -0,0 +1,103 @@
Driver for tilt-switches connected via GPIOs
============================================
Generic driver to read data from tilt switches connected via gpios.
Orientation can be provided by one or more than one tilt switches,
i.e. each tilt switch providing one axis, and the number of axes
is also not limited.
Data structures:
----------------
The array of struct gpio in the gpios field is used to list the gpios
that represent the current tilt state.
The array of struct gpio_tilt_axis describes the axes that are reported
to the input system. The values set therein are used for the
input_set_abs_params calls needed to init the axes.
The array of struct gpio_tilt_state maps gpio states to the corresponding
values to report. The gpio state is represented as a bitfield where the
bit-index corresponds to the index of the gpio in the struct gpio array.
In the same manner the values stored in the axes array correspond to
the elements of the gpio_tilt_axis-array.
Example:
--------
Example configuration for a single TS1003 tilt switch that rotates around
one axis in 4 steps and emitts the current tilt via two GPIOs.
static int sg060_tilt_enable(struct device *dev) {
/* code to enable the sensors */
};
static void sg060_tilt_disable(struct device *dev) {
/* code to disable the sensors */
};
static struct gpio sg060_tilt_gpios[] = {
{ SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
{ SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
};
static struct gpio_tilt_state sg060_tilt_states[] = {
{
.gpios = (0 << 1) | (0 << 0),
.axes = (int[]) {
0,
},
}, {
.gpios = (0 << 1) | (1 << 0),
.axes = (int[]) {
1, /* 90 degrees */
},
}, {
.gpios = (1 << 1) | (1 << 0),
.axes = (int[]) {
2, /* 180 degrees */
},
}, {
.gpios = (1 << 1) | (0 << 0),
.axes = (int[]) {
3, /* 270 degrees */
},
},
};
static struct gpio_tilt_axis sg060_tilt_axes[] = {
{
.axis = ABS_RY,
.min = 0,
.max = 3,
.fuzz = 0,
.flat = 0,
},
};
static struct gpio_tilt_platform_data sg060_tilt_pdata= {
.gpios = sg060_tilt_gpios,
.nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
.axes = sg060_tilt_axes,
.nr_axes = ARRAY_SIZE(sg060_tilt_axes),
.states = sg060_tilt_states,
.nr_states = ARRAY_SIZE(sg060_tilt_states),
.debounce_interval = 100,
.poll_interval = 1000,
.enable = sg060_tilt_enable,
.disable = sg060_tilt_disable,
};
static struct platform_device sg060_device_tilt = {
.name = "gpio-tilt-polled",
.id = -1,
.dev = {
.platform_data = &sg060_tilt_pdata,
},
};

364
Documentation/input/sentelic.txt
View File

@ -1,5 +1,5 @@
Copyright (C) 2002-2010 Sentelic Corporation.
Last update: Jan-13-2010
Copyright (C) 2002-2011 Sentelic Corporation.
Last update: Dec-07-2011
==============================================================================
* Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons)
@ -140,6 +140,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordination packet
=> 10, Notify packet
=> 11, Normal data packet with on-pad click
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
When both fingers are up, the last two reports have zero valid
bit.
@ -164,6 +165,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordinates packet
=> 10, Notify packet
=> 11, Normal data packet with on-pad click
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
When both fingers are up, the last two reports have zero valid
bit.
@ -188,6 +190,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordinates packet
=> 10, Notify packet
=> 11, Normal data packet with on-pad click
Bit5 => 1
Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1):
0: left button is generated by the on-pad command
@ -205,7 +208,7 @@ Byte 4: Bit7 => scroll right button
Bit6 => scroll left button
Bit5 => scroll down button
Bit4 => scroll up button
* Note that if gesture and additional buttoni (Bit4~Bit7)
* Note that if gesture and additional button (Bit4~Bit7)
happen at the same time, the button information will not
be sent.
Bit3~Bit0 => Reserved
@ -227,6 +230,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordinates packet
=> 10, Notify packet
=> 11, Normal data packet with on-pad click
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
When both fingers are up, the last two reports have zero valid
bit.
@ -253,6 +257,7 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordination packet
=> 10, Notify packet
=> 11, Normal data packet with on-pad click
Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up.
When both fingers are up, the last two reports have zero valid
bit.
@ -279,8 +284,9 @@ BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordination packet
=> 10, Notify packet
=> 11, Normal data packet with on-pad click
Bit5 => 1
Bit4 => when in absolute coordinate mode (valid when EN_PKT_GO is 1):
Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1):
0: left button is generated by the on-pad command
1: left button is generated by the external button
Bit3 => 1
@ -306,6 +312,110 @@ Sample sequence of Multi-finger, Multi-coordinate mode:
notify packet (valid bit == 1), abs pkt 1, abs pkt 2, abs pkt 1,
abs pkt 2, ..., notify packet (valid bit == 0)
==============================================================================
* Absolute position for STL3888-Cx and STL3888-Dx.
==============================================================================
Single Finger, Absolute Coordinate Mode (SFAC)
Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------|
1 |0|1|0|P|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|B|F|X|X|Y|Y|
|---------------| |---------------| |---------------| |---------------|
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordinates packet
=> 10, Notify packet
Bit5 => Coordinate mode(always 0 in SFAC mode):
0: single-finger absolute coordinates (SFAC) mode
1: multi-finger, multiple coordinates (MFMC) mode
Bit4 => 0: The LEFT button is generated by on-pad command (OPC)
1: The LEFT button is generated by external button
Default is 1 even if the LEFT button is not pressed.
Bit3 => Always 1, as specified by PS/2 protocol.
Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
Bit1 => Right Button, 1 is pressed, 0 is not pressed.
Bit0 => Left Button, 1 is pressed, 0 is not pressed.
Byte 2: X coordinate (xpos[9:2])
Byte 3: Y coordinate (ypos[9:2])
Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0])
Bit3~Bit2 => X coordinate (ypos[1:0])
Bit4 => 4th mouse button(forward one page)
Bit5 => 5th mouse button(backward one page)
Bit6 => scroll left button
Bit7 => scroll right button
Multi Finger, Multiple Coordinates Mode (MFMC):
Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------|
1 |0|1|1|P|1|F|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|B|F|X|X|Y|Y|
|---------------| |---------------| |---------------| |---------------|
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordination packet
=> 10, Notify packet
Bit5 => Coordinate mode (always 1 in MFMC mode):
0: single-finger absolute coordinates (SFAC) mode
1: multi-finger, multiple coordinates (MFMC) mode
Bit4 => 0: The LEFT button is generated by on-pad command (OPC)
1: The LEFT button is generated by external button
Default is 1 even if the LEFT button is not pressed.
Bit3 => Always 1, as specified by PS/2 protocol.
Bit2 => Finger index, 0 is the first finger, 1 is the second finger.
If bit 1 and 0 are all 1 and bit 4 is 0, the middle external
button is pressed.
Bit1 => Right Button, 1 is pressed, 0 is not pressed.
Bit0 => Left Button, 1 is pressed, 0 is not pressed.
Byte 2: X coordinate (xpos[9:2])
Byte 3: Y coordinate (ypos[9:2])
Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0])
Bit3~Bit2 => X coordinate (ypos[1:0])
Bit4 => 4th mouse button(forward one page)
Bit5 => 5th mouse button(backward one page)
Bit6 => scroll left button
Bit7 => scroll right button
When one of the two fingers is up, the device will output four consecutive
MFMC#0 report packets with zero X and Y to represent 1st finger is up or
four consecutive MFMC#1 report packets with zero X and Y to represent that
the 2nd finger is up. On the other hand, if both fingers are up, the device
will output four consecutive single-finger, absolute coordinate(SFAC) packets
with zero X and Y.
Notify Packet for STL3888-Cx/Dx
Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------|
1 |1|0|0|P|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |0|0|F|F|0|0|0|i| 4 |r|l|u|d|0|0|0|0|
|---------------| |---------------| |---------------| |---------------|
Byte 1: Bit7~Bit6 => 00, Normal data packet
=> 01, Absolute coordinates packet
=> 10, Notify packet
Bit5 => Always 0
Bit4 => 0: The LEFT button is generated by on-pad command(OPC)
1: The LEFT button is generated by external button
Default is 1 even if the LEFT button is not pressed.
Bit3 => 1
Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
Bit1 => Right Button, 1 is pressed, 0 is not pressed.
Bit0 => Left Button, 1 is pressed, 0 is not pressed.
Byte 2: Message type:
0xba => gesture information
0xc0 => one finger hold-rotating gesture
Byte 3: The first parameter for the received message:
0xba => gesture ID (refer to the 'Gesture ID' section)
0xc0 => region ID
Byte 4: The second parameter for the received message:
0xba => N/A
0xc0 => finger up/down information
Sample sequence of Multi-finger, Multi-coordinates mode:
notify packet (valid bit == 1), MFMC packet 1 (byte 1, bit 2 == 0),
MFMC packet 2 (byte 1, bit 2 == 1), MFMC packet 1, MFMC packet 2,
..., notify packet (valid bit == 0)
That is, when the device is in MFMC mode, the host will receive
interleaved absolute coordinate packets for each finger.
==============================================================================
* FSP Enable/Disable packet
==============================================================================
@ -348,9 +458,10 @@ http://www.computer-engineering.org/ps2mouse/
==============================================================================
1. Identify FSP by reading device ID(0x00) and version(0x01) register
2. Determine number of buttons by reading status2 (0x0b) register
2a. For FSP version < STL3888 Cx, determine number of buttons by reading
the 'test mode status' (0x20) register:
buttons = reg[0x0b] & 0x30
buttons = reg[0x20] & 0x30
if buttons == 0x30 or buttons == 0x20:
# two/four buttons
@ -365,6 +476,10 @@ http://www.computer-engineering.org/ps2mouse/
Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse'
section A for packet parsing detail
2b. For FSP version >= STL3888 Cx:
Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse'
section A for packet parsing detail (ignore byte 4, bit ~ 7)
==============================================================================
* Programming Sequence for Register Reading/Writing
==============================================================================
@ -374,7 +489,7 @@ Register inversion requirement:
Following values needed to be inverted(the '~' operator in C) before being
sent to FSP:
0xe9, 0xee, 0xf2 and 0xff.
0xe8, 0xe9, 0xee, 0xf2, 0xf3 and 0xff.
Register swapping requirement:
@ -415,7 +530,18 @@ Register reading sequence:
8. send 0xe9(status request) PS/2 command to FSP;
9. the response read from FSP should be the requested register value.
9. the 4th byte of the response read from FSP should be the
requested register value(?? indicates don't care byte):
host: 0xe9
3888: 0xfa (??) (??) (val)
* Note that since the Cx release, the hardware will return 1's
complement of the register value at the 3rd byte of status request
result:
host: 0xe9
3888: 0xfa (??) (~val) (val)
Register writing sequence:
@ -465,71 +591,194 @@ Register writing sequence:
9. the register writing sequence is completed.
* Note that since the Cx release, the hardware will return 1's
complement of the register value at the 3rd byte of status request
result. Host can optionally send another 0xe9 (status request) PS/2
command to FSP at the end of register writing to verify that the
register writing operation is successful (?? indicates don't care
byte):
host: 0xe9
3888: 0xfa (??) (~val) (val)
==============================================================================
* Programming Sequence for Page Register Reading/Writing
==============================================================================
In order to overcome the limitation of maximum number of registers
supported, the hardware separates register into different groups called
'pages.' Each page is able to include up to 255 registers.
The default page after power up is 0x82; therefore, if one has to get
access to register 0x8301, one has to use following sequence to switch
to page 0x83, then start reading/writing from/to offset 0x01 by using
the register read/write sequence described in previous section.
Page register reading sequence:
1. send 0xf3 PS/2 command to FSP;
2. send 0x66 PS/2 command to FSP;
3. send 0x88 PS/2 command to FSP;
4. send 0xf3 PS/2 command to FSP;
5. send 0x83 PS/2 command to FSP;
6. send 0x88 PS/2 command to FSP;
7. send 0xe9(status request) PS/2 command to FSP;
8. the response read from FSP should be the requested page value.
Page register writing sequence:
1. send 0xf3 PS/2 command to FSP;
2. send 0x38 PS/2 command to FSP;
3. send 0x88 PS/2 command to FSP;
4. send 0xf3 PS/2 command to FSP;
5. if the page address being written is not required to be
inverted(refer to the 'Register inversion requirement' section),
goto step 6
5a. send 0x47 PS/2 command to FSP;
5b. send the inverted page address to FSP and goto step 9;
6. if the page address being written is not required to be
swapped(refer to the 'Register swapping requirement' section),
goto step 7
6a. send 0x44 PS/2 command to FSP;
6b. send the swapped page address to FSP and goto step 9;
7. send 0x33 PS/2 command to FSP;
8. send the page address to FSP;
9. the page register writing sequence is completed.
==============================================================================
* Gesture ID
==============================================================================
Unlike other devices which sends multiple fingers' coordinates to host,
FSP processes multiple fingers' coordinates internally and convert them
into a 8 bits integer, namely 'Gesture ID.' Following is a list of
supported gesture IDs:
ID Description
0x86 2 finger straight up
0x82 2 finger straight down
0x80 2 finger straight right
0x84 2 finger straight left
0x8f 2 finger zoom in
0x8b 2 finger zoom out
0xc0 2 finger curve, counter clockwise
0xc4 2 finger curve, clockwise
0x2e 3 finger straight up
0x2a 3 finger straight down
0x28 3 finger straight right
0x2c 3 finger straight left
0x38 palm
==============================================================================
* Register Listing
==============================================================================
Registers are represented in 16 bits values. The higher 8 bits represent
the page address and the lower 8 bits represent the relative offset within
that particular page. Refer to the 'Programming Sequence for Page Register
Reading/Writing' section for instructions on how to change current page
address.
offset width default r/w name
0x00 bit7~bit0 0x01 RO device ID
0x8200 bit7~bit0 0x01 RO device ID
0x01 bit7~bit0 0xc0 RW version ID
0x8201 bit7~bit0 RW version ID
0xc1: STL3888 Ax
0xd0 ~ 0xd2: STL3888 Bx
0xe0 ~ 0xe1: STL3888 Cx
0xe2 ~ 0xe3: STL3888 Dx
0x02 bit7~bit0 0x01 RO vendor ID
0x8202 bit7~bit0 0x01 RO vendor ID
0x03 bit7~bit0 0x01 RO product ID
0x8203 bit7~bit0 0x01 RO product ID
0x04 bit3~bit0 0x01 RW revision ID
0x8204 bit3~bit0 0x01 RW revision ID
0x0b RO test mode status 1
bit3 1 RO 0: rotate 180 degree, 1: no rotation
0x820b test mode status 1
bit3 1 RO 0: rotate 180 degree
1: no rotation
*only supported by H/W prior to Cx
bit5~bit4 RO number of buttons
11 => 2, lbtn/rbtn
10 => 4, lbtn/rbtn/scru/scrd
01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr
00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn
0x820f register file page control
bit2 0 RW 1: rotate 180 degree
0: no rotation
*supported since Cx
0x0f RW register file page control
bit0 0 RW 1 to enable page 1 register files
*only supported by H/W prior to Cx
0x10 RW system control 1
0x8210 RW system control 1
bit0 1 RW Reserved, must be 1
bit1 0 RW Reserved, must be 0
bit4 1 RW Reserved, must be 0
bit5 0 RW register clock gating enable
bit4 0 RW Reserved, must be 0
bit5 1 RW register clock gating enable
0: read only, 1: read/write enable
(Note that following registers does not require clock gating being
enabled prior to write: 05 06 07 08 09 0c 0f 10 11 12 16 17 18 23 2e
40 41 42 43. In addition to that, this bit must be 1 when gesture
mode is enabled)
0x31 RW on-pad command detection
0x8220 test mode status
bit5~bit4 RO number of buttons
11 => 2, lbtn/rbtn
10 => 4, lbtn/rbtn/scru/scrd
01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr
00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn
*only supported by H/W prior to Cx
0x8231 RW on-pad command detection
bit7 0 RW on-pad command left button down tag
enable
0: disable, 1: enable
*only supported by H/W prior to Cx
0x34 RW on-pad command control 5
0x8234 RW on-pad command control 5
bit4~bit0 0x05 RW XLO in 0s/4/1, so 03h = 0010.1b = 2.5
(Note that position unit is in 0.5 scanline)
*only supported by H/W prior to Cx
bit7 0 RW on-pad tap zone enable
0: disable, 1: enable
*only supported by H/W prior to Cx
0x35 RW on-pad command control 6
0x8235 RW on-pad command control 6
bit4~bit0 0x1d RW XHI in 0s/4/1, so 19h = 1100.1b = 12.5
(Note that position unit is in 0.5 scanline)
*only supported by H/W prior to Cx
0x36 RW on-pad command control 7
0x8236 RW on-pad command control 7
bit4~bit0 0x04 RW YLO in 0s/4/1, so 03h = 0010.1b = 2.5
(Note that position unit is in 0.5 scanline)
*only supported by H/W prior to Cx
0x37 RW on-pad command control 8
0x8237 RW on-pad command control 8
bit4~bit0 0x13 RW YHI in 0s/4/1, so 11h = 1000.1b = 8.5
(Note that position unit is in 0.5 scanline)
*only supported by H/W prior to Cx
0x40 RW system control 5
0x8240 RW system control 5
bit1 0 RW FSP Intellimouse mode enable
0: disable, 1: enable
*only supported by H/W prior to Cx
bit2 0 RW movement + abs. coordinate mode enable
0: disable, 1: enable
@ -537,6 +786,7 @@ offset width default r/w name
bit 1 is not set. However, the format is different from that of bit 1.
In addition, when bit 1 and bit 2 are set at the same time, bit 2 will
override bit 1.)
*only supported by H/W prior to Cx
bit3 0 RW abs. coordinate only mode enable
0: disable, 1: enable
@ -544,9 +794,11 @@ offset width default r/w name
bit 1 is not set. However, the format is different from that of bit 1.
In addition, when bit 1, bit 2 and bit 3 are set at the same time,
bit 3 will override bit 1 and 2.)
*only supported by H/W prior to Cx
bit5 0 RW auto switch enable
0: disable, 1: enable
*only supported by H/W prior to Cx
bit6 0 RW G0 abs. + notify packet format enable
0: disable, 1: enable
@ -554,18 +806,68 @@ offset width default r/w name
bit 2 and 3. That is, if any of those bit is 1, host will receive
absolute coordinates; otherwise, host only receives packets with
relative coordinate.)
*only supported by H/W prior to Cx
bit7 0 RW EN_PS2_F2: PS/2 gesture mode 2nd
finger packet enable
0: disable, 1: enable
*only supported by H/W prior to Cx
0x43 RW on-pad control
0x8243 RW on-pad control
bit0 0 RW on-pad control enable
0: disable, 1: enable
(Note that if this bit is cleared, bit 3/5 will be ineffective)
*only supported by H/W prior to Cx
bit3 0 RW on-pad fix vertical scrolling enable
0: disable, 1: enable
*only supported by H/W prior to Cx
bit5 0 RW on-pad fix horizontal scrolling enable
0: disable, 1: enable
*only supported by H/W prior to Cx
0x8290 RW software control register 1
bit0 0 RW absolute coordination mode
0: disable, 1: enable
*supported since Cx
bit1 0 RW gesture ID output
0: disable, 1: enable
*supported since Cx
bit2 0 RW two fingers' coordinates output
0: disable, 1: enable
*supported since Cx
bit3 0 RW finger up one packet output
0: disable, 1: enable
*supported since Cx
bit4 0 RW absolute coordination continuous mode
0: disable, 1: enable
*supported since Cx
bit6~bit5 00 RW gesture group selection
00: basic
01: suite
10: suite pro
11: advanced
*supported since Cx
bit7 0 RW Bx packet output compatible mode
0: disable, 1: enable *supported since Cx
*supported since Cx
0x833d RW on-pad command control 1
bit7 1 RW on-pad command detection enable
0: disable, 1: enable
*supported since Cx
0x833e RW on-pad command detection
bit7 0 RW on-pad command left button down tag
enable. Works only in H/W based PS/2
data packet mode.
0: disable, 1: enable
*supported since Cx

35
Documentation/kdump/kdump.txt
View File

@ -17,8 +17,8 @@ You can use common commands, such as cp and scp, to copy the
memory image to a dump file on the local disk, or across the network to
a remote system.
Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
architectures.
Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
and s390x architectures.
When the system kernel boots, it reserves a small section of memory for
the dump-capture kernel. This ensures that ongoing Direct Memory Access
@ -34,11 +34,18 @@ Similarly on PPC64 machines first 32KB of physical memory is needed for
booting regardless of where the kernel is loaded and to support 64K page
size kexec backs up the first 64KB memory.
For s390x, when kdump is triggered, the crashkernel region is exchanged
with the region [0, crashkernel region size] and then the kdump kernel
runs in [0, crashkernel region size]. Therefore no relocatable kernel is
needed for s390x.
All of the necessary information about the system kernel's core image is
encoded in the ELF format, and stored in a reserved area of memory
before a crash. The physical address of the start of the ELF header is
passed to the dump-capture kernel through the elfcorehdr= boot
parameter.
parameter. Optionally the size of the ELF header can also be passed
when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
With the dump-capture kernel, you can access the memory image, or "old
memory," in two ways:
@ -291,6 +298,10 @@ Boot into System Kernel
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
dependent on the memory size of the production system.
Load the Dump-capture Kernel
============================
@ -308,6 +319,8 @@ For ppc64:
- Use vmlinux
For ia64:
- Use vmlinux or vmlinuz.gz
For s390x:
- Use image or bzImage
If you are using a uncompressed vmlinux image then use following command
@ -337,6 +350,8 @@ For i386, x86_64 and ia64:
For ppc64:
"1 maxcpus=1 noirqdistrib reset_devices"
For s390x:
"1 maxcpus=1 cgroup_disable=memory"
Notes on loading the dump-capture kernel:
@ -362,6 +377,20 @@ Notes on loading the dump-capture kernel:
dump. Hence generally it is useful either to build a UP dump-capture
kernel or specify maxcpus=1 option while loading dump-capture kernel.
* For s390x there are two kdump modes: If a ELF header is specified with
the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
is done on all other architectures. If no elfcorehdr= kernel parameter is
specified, the s390x kdump kernel dynamically creates the header. The
second mode has the advantage that for CPU and memory hotplug, kdump has
not to be reloaded with kexec_load().
* For s390x systems with many attached devices the "cio_ignore" kernel
parameter should be used for the kdump kernel in order to prevent allocation
of kernel memory for devices that are not relevant for kdump. The same
applies to systems that use SCSI/FCP devices. In that case the
"allow_lun_scan" zfcp module parameter should be set to zero before
setting FCP devices online.
Kernel Panic
============

74
Documentation/kernel-parameters.txt
View File

@ -329,6 +329,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
is a lot of faster
off - do not initialize any AMD IOMMU found in
the system
force_isolation - Force device isolation for all
devices. The IOMMU driver is not
allowed anymore to lift isolation
requirements as needed. This option
does not override iommu=pt
amijoy.map= [HW,JOY] Amiga joystick support
Map of devices attached to JOY0DAT and JOY1DAT
@ -623,6 +628,25 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
no_debug_objects
[KNL] Disable object debugging
debug_guardpage_minorder=
[KNL] When CONFIG_DEBUG_PAGEALLOC is set, this
parameter allows control of the order of pages that will
be intentionally kept free (and hence protected) by the
buddy allocator. Bigger value increase the probability
of catching random memory corruption, but reduce the
amount of memory for normal system use. The maximum
possible value is MAX_ORDER/2. Setting this parameter
to 1 or 2 should be enough to identify most random
memory corruption problems caused by bugs in kernel or
driver code when a CPU writes to (or reads from) a
random memory location. Note that there exists a class
of memory corruptions problems caused by buggy H/W or
F/W or by drivers badly programing DMA (basically when
memory is written at bus level and the CPU MMU is
bypassed) which are not detectable by
CONFIG_DEBUG_PAGEALLOC, hence this option will not help
tracking down these problems.
debugpat [X86] Enable PAT debugging
decnet.addr= [HW,NET]
@ -1059,7 +1083,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
nomerge
forcesac
soft
pt [x86, IA-64]
pt [x86, IA-64]
group_mf [x86, IA-64]
io7= [HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in
@ -1178,9 +1204,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
Default is 0 (don't ignore, but inject #GP)
kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging.
Default is 1 (enabled)
kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit
KVM MMU at runtime.
Default is 0 (off)
@ -1630,12 +1653,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The default is to return 64-bit inode numbers.
nfs.nfs4_disable_idmapping=
[NFSv4] When set, this option disables the NFSv4
idmapper on the client, but only if the mount
is using the 'sec=sys' security flavour. This may
make migration from legacy NFSv2/v3 systems easier
provided that the server has the appropriate support.
The default is to always enable NFSv4 idmapping.
[NFSv4] When set to the default of '1', this option
ensures that both the RPC level authentication
scheme and the NFS level operations agree to use
numeric uids/gids if the mount is using the
'sec=sys' security flavour. In effect it is
disabling idmapping, which can make migration from
legacy NFSv2/v3 systems to NFSv4 easier.
Servers that do not support this mode of operation
will be autodetected by the client, and it will fall
back to using the idmapper.
To turn off this behaviour, set the value to '0'.
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
when a NMI is triggered.
@ -1796,6 +1824,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
nomfgpt [X86-32] Disable Multi-Function General Purpose
Timer usage (for AMD Geode machines).
nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to
shutdown the other cpus. Instead use the REBOOT_VECTOR
irq.
nopat [X86] Disable PAT (page attribute table extension of
pagetables) support.
@ -1885,6 +1917,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
arch_perfmon: [X86] Force use of architectural
perfmon on Intel CPUs instead of the
CPU specific event set.
timer: [X86] Force use of architectural NMI
timer mode (see also oprofile.timer
for generic hr timer mode)
[s390] Force legacy basic mode sampling
(report cpu_type "timer")
oops=panic Always panic on oopses. Default is to just kill the
process, but there is a small probability of
@ -2362,6 +2399,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
slram= [HW,MTD]
slab_max_order= [MM, SLAB]
Determines the maximum allowed order for slabs.
A high setting may cause OOMs due to memory
fragmentation. Defaults to 1 for systems with
more than 32MB of RAM, 0 otherwise.
slub_debug[=options[,slabs]] [MM, SLUB]
Enabling slub_debug allows one to determine the
culprit if slab objects become corrupted. Enabling
@ -2632,6 +2675,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
[USB] Start with the old device initialization
scheme (default 0 = off).
usbcore.usbfs_memory_mb=
[USB] Memory limit (in MB) for buffers allocated by
usbfs (default = 16, 0 = max = 2047).
usbcore.use_both_schemes=
[USB] Try the other device initialization scheme
if the first one fails (default 1 = enabled).
@ -2750,11 +2797,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
functions are at fixed addresses, they make nice
targets for exploits that can control RIP.
emulate Vsyscalls turn into traps and are emulated
reasonably safely.
emulate [default] Vsyscalls turn into traps and are
emulated reasonably safely.
native [default] Vsyscalls are native syscall
instructions.
native Vsyscalls are native syscall instructions.
This is a little bit faster than trapping
and makes a few dynamic recompilers work
better than they would in emulation mode.

63
Documentation/lockdep-design.txt
View File

@ -221,3 +221,66 @@ when the chain is validated for the first time, is then put into a hash
table, which hash-table can be checked in a lockfree manner. If the
locking chain occurs again later on, the hash table tells us that we
dont have to validate the chain again.
Troubleshooting:
----------------
The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
Exceeding this number will trigger the following lockdep warning:
(DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS))
By default, MAX_LOCKDEP_KEYS is currently set to 8191, and typical
desktop systems have less than 1,000 lock classes, so this warning
normally results from lock-class leakage or failure to properly
initialize locks. These two problems are illustrated below:
1. Repeated module loading and unloading while running the validator
will result in lock-class leakage. The issue here is that each
load of the module will create a new set of lock classes for
that module's locks, but module unloading does not remove old
classes (see below discussion of reuse of lock classes for why).
Therefore, if that module is loaded and unloaded repeatedly,
the number of lock classes will eventually reach the maximum.
2. Using structures such as arrays that have large numbers of
locks that are not explicitly initialized. For example,
a hash table with 8192 buckets where each bucket has its own
spinlock_t will consume 8192 lock classes -unless- each spinlock
is explicitly initialized at runtime, for example, using the
run-time spin_lock_init() as opposed to compile-time initializers
such as __SPIN_LOCK_UNLOCKED(). Failure to properly initialize
the per-bucket spinlocks would guarantee lock-class overflow.
In contrast, a loop that called spin_lock_init() on each lock
would place all 8192 locks into a single lock class.
The moral of this story is that you should always explicitly
initialize your locks.
One might argue that the validator should be modified to allow
lock classes to be reused. However, if you are tempted to make this
argument, first review the code and think through the changes that would
be required, keeping in mind that the lock classes to be removed are
likely to be linked into the lock-dependency graph. This turns out to
be harder to do than to say.
Of course, if you do run out of lock classes, the next thing to do is
to find the offending lock classes. First, the following command gives
you the number of lock classes currently in use along with the maximum:
grep "lock-classes" /proc/lockdep_stats
This command produces the following output on a modest system:
lock-classes: 748 [max: 8191]
If the number allocated (748 above) increases continually over time,
then there is likely a leak. The following command can be used to
identify the leaking lock classes:
grep "BD" /proc/lockdep
Run the command and save the output, then compare against the output from
a later run of this command to identify the leakers. This same output
can also help you find situations where runtime lock initialization has
been omitted.

22
Documentation/md.txt
View File

@ -357,14 +357,14 @@ Each directory contains:
written to, that device.
state
A file recording the current state of the device in the array
A file recording the current state of the device in the array
which can be a comma separated list of
faulty - device has been kicked from active use due to
a detected fault or it has unacknowledged bad
blocks
a detected fault, or it has unacknowledged bad
blocks
in_sync - device is a fully in-sync member of the array
writemostly - device will only be subject to read
requests if there are no other options.
requests if there are no other options.
This applies only to raid1 arrays.
blocked - device has failed, and the failure hasn't been
acknowledged yet by the metadata handler.
@ -374,6 +374,13 @@ Each directory contains:
This includes spares that are in the process
of being recovered to
write_error - device has ever seen a write error.
want_replacement - device is (mostly) working but probably
should be replaced, either due to errors or
due to user request.
replacement - device is a replacement for another active
device with same raid_disk.
This list may grow in future.
This can be written to.
Writing "faulty" simulates a failure on the device.
@ -386,6 +393,13 @@ Each directory contains:
Writing "in_sync" sets the in_sync flag.
Writing "write_error" sets writeerrorseen flag.
Writing "-write_error" clears writeerrorseen flag.
Writing "want_replacement" is allowed at any time except to a
replacement device or a spare. It sets the flag.
Writing "-want_replacement" is allowed at any time. It clears
the flag.
Writing "replacement" or "-replacement" is only allowed before
starting the array. It sets or clears the flag.
This file responds to select/poll. Any change to 'faulty'
or 'blocked' causes an event.

286
Documentation/pinctrl.txt
View File

@ -7,12 +7,9 @@ This subsystem deals with:
- Multiplexing of pins, pads, fingers (etc) see below for details
The intention is to also deal with:
- Software-controlled biasing and driving mode specific pins, such as
pull-up/down, open drain etc, load capacitance configuration when controlled
by software, etc.
- Configuration of pins, pads, fingers (etc), such as software-controlled
biasing and driving mode specific pins, such as pull-up/down, open drain,
load capacitance etc.
Top-level interface
===================
@ -32,7 +29,7 @@ Definition of PIN:
be sparse - i.e. there may be gaps in the space with numbers where no
pin exists.
When a PIN CONTROLLER is instatiated, it will register a descriptor to the
When a PIN CONTROLLER is instantiated, it will register a descriptor to the
pin control framework, and this descriptor contains an array of pin descriptors
describing the pins handled by this specific pin controller.
@ -61,14 +58,14 @@ this in our driver:
#include <linux/pinctrl/pinctrl.h>
const struct pinctrl_pin_desc __refdata foo_pins[] = {
PINCTRL_PIN(0, "A1"),
PINCTRL_PIN(1, "A2"),
PINCTRL_PIN(2, "A3"),
const struct pinctrl_pin_desc foo_pins[] = {
PINCTRL_PIN(0, "A8"),
PINCTRL_PIN(1, "B8"),
PINCTRL_PIN(2, "C8"),
...
PINCTRL_PIN(61, "H6"),
PINCTRL_PIN(62, "H7"),
PINCTRL_PIN(63, "H8"),
PINCTRL_PIN(61, "F1"),
PINCTRL_PIN(62, "G1"),
PINCTRL_PIN(63, "H1"),
};
static struct pinctrl_desc foo_desc = {
@ -88,11 +85,16 @@ int __init foo_probe(void)
pr_err("could not register foo pin driver\n");
}
To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and
selected drivers, you need to select them from your machine's Kconfig entry,
since these are so tightly integrated with the machines they are used on.
See for example arch/arm/mach-u300/Kconfig for an example.
Pins usually have fancier names than this. You can find these in the dataheet
for your chip. Notice that the core pinctrl.h file provides a fancy macro
called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
the pins from 0 in the upper left corner to 63 in the lower right corner,
this enumeration was arbitrarily chosen, in practice you need to think
the pins from 0 in the upper left corner to 63 in the lower right corner.
This enumeration was arbitrarily chosen, in practice you need to think
through your numbering system so that it matches the layout of registers
and such things in your driver, or the code may become complicated. You must
also consider matching of offsets to the GPIO ranges that may be handled by
@ -133,8 +135,8 @@ struct foo_group {
const unsigned num_pins;
};
static unsigned int spi0_pins[] = { 0, 8, 16, 24 };
static unsigned int i2c0_pins[] = { 24, 25 };
static const unsigned int spi0_pins[] = { 0, 8, 16, 24 };
static const unsigned int i2c0_pins[] = { 24, 25 };
static const struct foo_group foo_groups[] = {
{
@ -193,6 +195,88 @@ structure, for example specific register ranges associated with each group
and so on.
Pin configuration
=================
Pins can sometimes be software-configured in an various ways, mostly related
to their electronic properties when used as inputs or outputs. For example you
may be able to make an output pin high impedance, or "tristate" meaning it is
effectively disconnected. You may be able to connect an input pin to VDD or GND
using a certain resistor value - pull up and pull down - so that the pin has a
stable value when nothing is driving the rail it is connected to, or when it's
unconnected.
For example, a platform may do this:
ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP);
To pull up a pin to VDD. The pin configuration driver implements callbacks for
changing pin configuration in the pin controller ops like this:
#include <linux/pinctrl/pinctrl.h>
#include <linux/pinctrl/pinconf.h>
#include "platform_x_pindefs.h"
static int foo_pin_config_get(struct pinctrl_dev *pctldev,
unsigned offset,
unsigned long *config)
{
struct my_conftype conf;
... Find setting for pin @ offset ...
*config = (unsigned long) conf;
}
static int foo_pin_config_set(struct pinctrl_dev *pctldev,
unsigned offset,
unsigned long config)
{
struct my_conftype *conf = (struct my_conftype *) config;
switch (conf) {
case PLATFORM_X_PULL_UP:
...
}
}
}
static int foo_pin_config_group_get (struct pinctrl_dev *pctldev,
unsigned selector,
unsigned long *config)
{
...
}
static int foo_pin_config_group_set (struct pinctrl_dev *pctldev,
unsigned selector,
unsigned long config)
{
...
}
static struct pinconf_ops foo_pconf_ops = {
.pin_config_get = foo_pin_config_get,
.pin_config_set = foo_pin_config_set,
.pin_config_group_get = foo_pin_config_group_get,
.pin_config_group_set = foo_pin_config_group_set,
};
/* Pin config operations are handled by some pin controller */
static struct pinctrl_desc foo_desc = {
...
.confops = &foo_pconf_ops,
};
Since some controllers have special logic for handling entire groups of pins
they can exploit the special whole-group pin control function. The
pin_config_group_set() callback is allowed to return the error code -EAGAIN,
for groups it does not want to handle, or if it just wants to do some
group-level handling and then fall through to iterate over all pins, in which
case each individual pin will be treated by separate pin_config_set() calls as
well.
Interaction with the GPIO subsystem
===================================
@ -214,19 +298,20 @@ static struct pinctrl_gpio_range gpio_range_a = {
.name = "chip a",
.id = 0,
.base = 32,
.pin_base = 32,
.npins = 16,
.gc = &chip_a;
};
static struct pinctrl_gpio_range gpio_range_a = {
static struct pinctrl_gpio_range gpio_range_b = {
.name = "chip b",
.id = 0,
.base = 48,
.pin_base = 64,
.npins = 8,
.gc = &chip_b;
};
{
struct pinctrl_dev *pctl;
...
@ -235,42 +320,39 @@ static struct pinctrl_gpio_range gpio_range_a = {
}
So this complex system has one pin controller handling two different
GPIO chips. Chip a has 16 pins and chip b has 8 pins. They are mapped in
the global GPIO pin space at:
GPIO chips. "chip a" has 16 pins and "chip b" has 8 pins. The "chip a" and
"chip b" have different .pin_base, which means a start pin number of the
GPIO range.
chip a: [32 .. 47]
chip b: [48 .. 55]
The GPIO range of "chip a" starts from the GPIO base of 32 and actual
pin range also starts from 32. However "chip b" has different starting
offset for the GPIO range and pin range. The GPIO range of "chip b" starts
from GPIO number 48, while the pin range of "chip b" starts from 64.
We can convert a gpio number to actual pin number using this "pin_base".
They are mapped in the global GPIO pin space at:
chip a:
- GPIO range : [32 .. 47]
- pin range : [32 .. 47]
chip b:
- GPIO range : [48 .. 55]
- pin range : [64 .. 71]
When GPIO-specific functions in the pin control subsystem are called, these
ranges will be used to look up the apropriate pin controller by inspecting
ranges will be used to look up the appropriate pin controller by inspecting
and matching the pin to the pin ranges across all controllers. When a
pin controller handling the matching range is found, GPIO-specific functions
will be called on that specific pin controller.
For all functionalities dealing with pin biasing, pin muxing etc, the pin
controller subsystem will subtract the range's .base offset from the passed
in gpio pin number, and pass that on to the pin control driver, so the driver
will get an offset into its handled number range. Further it is also passed
in gpio number, and add the ranges's .pin_base offset to retrive a pin number.
After that, the subsystem passes it on to the pin control driver, so the driver
will get an pin number into its handled number range. Further it is also passed
the range ID value, so that the pin controller knows which range it should
deal with.
For example: if a user issues pinctrl_gpio_set_foo(50), the pin control
subsystem will find that the second range on this pin controller matches,
subtract the base 48 and call the
pinctrl_driver_gpio_set_foo(pinctrl, range, 2) where the latter function has
this signature:
int pinctrl_driver_gpio_set_foo(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *rangeid,
unsigned offset);
Now the driver knows that we want to do some GPIO-specific operation on the
second GPIO range handled by "chip b", at offset 2 in that specific range.
(If the GPIO subsystem is ever refactored to use a local per-GPIO controller
pin space, this mapping will need to be augmented accordingly.)
PINMUX interfaces
=================
@ -438,7 +520,7 @@ you. Define enumerators only for the pins you can control if that makes sense.
Assumptions:
We assume that the number possible function maps to pin groups is limited by
We assume that the number of possible function maps to pin groups is limited by
the hardware. I.e. we assume that there is no system where any function can be
mapped to any pin, like in a phone exchange. So the available pins groups for
a certain function will be limited to a few choices (say up to eight or so),
@ -585,7 +667,7 @@ int foo_list_funcs(struct pinctrl_dev *pctldev, unsigned selector)
const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector)
{
return myfuncs[selector].name;
return foo_functions[selector].name;
}
static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
@ -600,16 +682,16 @@ static int foo_get_groups(struct pinctrl_dev *pctldev, unsigned selector,
int foo_enable(struct pinctrl_dev *pctldev, unsigned selector,
unsigned group)
{
u8 regbit = (1 << group);
u8 regbit = (1 << selector + group);
writeb((readb(MUX)|regbit), MUX)
return 0;
}
int foo_disable(struct pinctrl_dev *pctldev, unsigned selector,
void foo_disable(struct pinctrl_dev *pctldev, unsigned selector,
unsigned group)
{
u8 regbit = (1 << group);
u8 regbit = (1 << selector + group);
writeb((readb(MUX) & ~(regbit)), MUX)
return 0;
@ -647,6 +729,17 @@ All the above functions are mandatory to implement for a pinmux driver.
Pinmux interaction with the GPIO subsystem
==========================================
The public pinmux API contains two functions named pinmux_request_gpio()
and pinmux_free_gpio(). These two functions shall *ONLY* be called from
gpiolib-based drivers as part of their gpio_request() and
gpio_free() semantics. Likewise the pinmux_gpio_direction_[input|output]
shall only be called from within respective gpio_direction_[input|output]
gpiolib implementation.
NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be
muxed in. Instead, implement a proper gpiolib driver and have that driver
request proper muxing for its pins.
The function list could become long, especially if you can convert every
individual pin into a GPIO pin independent of any other pins, and then try
the approach to define every pin as a function.
@ -654,19 +747,24 @@ the approach to define every pin as a function.
In this case, the function array would become 64 entries for each GPIO
setting and then the device functions.
For this reason there is an additional function a pinmux driver can implement
to enable only GPIO on an individual pin: .gpio_request_enable(). The same
.free() function as for other functions is assumed to be usable also for
GPIO pins.
For this reason there are two functions a pinmux driver can implement
to enable only GPIO on an individual pin: .gpio_request_enable() and
.gpio_disable_free().
This function will pass in the affected GPIO range identified by the pin
controller core, so you know which GPIO pins are being affected by the request
operation.
Alternatively it is fully allowed to use named functions for each GPIO
pin, the pinmux_request_gpio() will attempt to obtain the function "gpioN"
where "N" is the global GPIO pin number if no special GPIO-handler is
registered.
If your driver needs to have an indication from the framework of whether the
GPIO pin shall be used for input or output you can implement the
.gpio_set_direction() function. As described this shall be called from the
gpiolib driver and the affected GPIO range, pin offset and desired direction
will be passed along to this function.
Alternatively to using these special functions, it is fully allowed to use
named functions for each GPIO pin, the pinmux_request_gpio() will attempt to
obtain the function "gpioN" where "N" is the global GPIO pin number if no
special GPIO-handler is registered.
Pinmux board/machine configuration
@ -683,19 +781,19 @@ spi on the second function mapping:
#include <linux/pinctrl/machine.h>
static struct pinmux_map pmx_mapping[] = {
static const struct pinmux_map __initdata pmx_mapping[] = {
{
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "spi0",
.dev_name = "foo-spi.0",
},
{
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "i2c0",
.dev_name = "foo-i2c.0",
},
{
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.dev_name = "foo-mmc.0",
},
@ -714,14 +812,14 @@ for example if they are not yet instantiated or cumbersome to obtain.
You register this pinmux mapping to the pinmux subsystem by simply:
ret = pinmux_register_mappings(&pmx_mapping, ARRAY_SIZE(pmx_mapping));
ret = pinmux_register_mappings(pmx_mapping, ARRAY_SIZE(pmx_mapping));
Since the above construct is pretty common there is a helper macro to make
it even more compact which assumes you want to use pinctrl.0 and position
it even more compact which assumes you want to use pinctrl-foo and position
0 for mapping, for example:
static struct pinmux_map pmx_mapping[] = {
PINMUX_MAP_PRIMARY("I2CMAP", "i2c0", "foo-i2c.0"),
static struct pinmux_map __initdata pmx_mapping[] = {
PINMUX_MAP("I2CMAP", "pinctrl-foo", "i2c0", "foo-i2c.0"),
};
@ -734,14 +832,14 @@ As it is possible to map a function to different groups of pins an optional
...
{
.name = "spi0-pos-A",
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "spi0",
.group = "spi0_0_grp",
.dev_name = "foo-spi.0",
},
{
.name = "spi0-pos-B",
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "spi0",
.group = "spi0_1_grp",
.dev_name = "foo-spi.0",
@ -760,46 +858,46 @@ case), we define a mapping like this:
...
{
.name "2bit"
.ctrl_dev_name = "pinctrl.0",
.function = "mmc0",
.group = "mmc0_0_grp",
.dev_name = "foo-mmc.0",
},
{
.name "4bit"
.ctrl_dev_name = "pinctrl.0",
.function = "mmc0",
.group = "mmc0_0_grp",
.dev_name = "foo-mmc.0",
},
{
.name "4bit"
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_1_grp",
.dev_name = "foo-mmc.0",
},
{
.name "8bit"
.ctrl_dev_name = "pinctrl.0",
.function = "mmc0",
.group = "mmc0_0_grp",
.dev_name = "foo-mmc.0",
},
{
.name "8bit"
.ctrl_dev_name = "pinctrl.0",
.name "4bit"
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_1_grp",
.dev_name = "foo-mmc.0",
},
{
.name "8bit"
.ctrl_dev_name = "pinctrl.0",
.name "4bit"
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_2_grp",
.dev_name = "foo-mmc.0",
},
{
.name "8bit"
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_1_grp",
.dev_name = "foo-mmc.0",
},
{
.name "8bit"
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_2_grp",
.dev_name = "foo-mmc.0",
},
{
.name "8bit"
.ctrl_dev_name = "pinctrl-foo",
.function = "mmc0",
.group = "mmc0_3_grp",
.dev_name = "foo-mmc.0",
},
...
The result of grabbing this mapping from the device with something like
@ -898,7 +996,7 @@ like this:
{
.name "POWERMAP"
.ctrl_dev_name = "pinctrl.0",
.ctrl_dev_name = "pinctrl-foo",
.function = "power_func",
.hog_on_boot = true,
},

163
Documentation/power/charger-manager.txt Normal file
View File

@ -0,0 +1,163 @@
Charger Manager
(C) 2011 MyungJoo Ham <myungjoo.ham@samsung.com>, GPL
Charger Manager provides in-kernel battery charger management that
requires temperature monitoring during suspend-to-RAM state
and where each battery may have multiple chargers attached and the userland
wants to look at the aggregated information of the multiple chargers.
Charger Manager is a platform_driver with power-supply-class entries.
An instance of Charger Manager (a platform-device created with Charger-Manager)
represents an independent battery with chargers. If there are multiple
batteries with their own chargers acting independently in a system,
the system may need multiple instances of Charger Manager.
1. Introduction
===============
Charger Manager supports the following:
* Support for multiple chargers (e.g., a device with USB, AC, and solar panels)
A system may have multiple chargers (or power sources) and some of
they may be activated at the same time. Each charger may have its
own power-supply-class and each power-supply-class can provide
different information about the battery status. This framework
aggregates charger-related information from multiple sources and
shows combined information as a single power-supply-class.
* Support for in suspend-to-RAM polling (with suspend_again callback)
While the battery is being charged and the system is in suspend-to-RAM,
we may need to monitor the battery health by looking at the ambient or
battery temperature. We can accomplish this by waking up the system
periodically. However, such a method wakes up devices unncessary for
monitoring the battery health and tasks, and user processes that are
supposed to be kept suspended. That, in turn, incurs unnecessary power
consumption and slow down charging process. Or even, such peak power
consumption can stop chargers in the middle of charging
(external power input < device power consumption), which not
only affects the charging time, but the lifespan of the battery.
Charger Manager provides a function "cm_suspend_again" that can be
used as suspend_again callback of platform_suspend_ops. If the platform
requires tasks other than cm_suspend_again, it may implement its own
suspend_again callback that calls cm_suspend_again in the middle.
Normally, the platform will need to resume and suspend some devices
that are used by Charger Manager.
2. Global Charger-Manager Data related with suspend_again
========================================================
In order to setup Charger Manager with suspend-again feature
(in-suspend monitoring), the user should provide charger_global_desc
with setup_charger_manager(struct charger_global_desc *).
This charger_global_desc data for in-suspend monitoring is global
as the name suggests. Thus, the user needs to provide only once even
if there are multiple batteries. If there are multiple batteries, the
multiple instances of Charger Manager share the same charger_global_desc
and it will manage in-suspend monitoring for all instances of Charger Manager.
The user needs to provide all the two entries properly in order to activate
in-suspend monitoring:
struct charger_global_desc {
char *rtc_name;
: The name of rtc (e.g., "rtc0") used to wakeup the system from
suspend for Charger Manager. The alarm interrupt (AIE) of the rtc
should be able to wake up the system from suspend. Charger Manager
saves and restores the alarm value and use the previously-defined
alarm if it is going to go off earlier than Charger Manager so that
Charger Manager does not interfere with previously-defined alarms.
bool (*rtc_only_wakeup)(void);
: This callback should let CM know whether
the wakeup-from-suspend is caused only by the alarm of "rtc" in the
same struct. If there is any other wakeup source triggered the
wakeup, it should return false. If the "rtc" is the only wakeup
reason, it should return true.
};
3. How to setup suspend_again
=============================
Charger Manager provides a function "extern bool cm_suspend_again(void)".
When cm_suspend_again is called, it monitors every battery. The suspend_ops
callback of the system's platform_suspend_ops can call cm_suspend_again
function to know whether Charger Manager wants to suspend again or not.
If there are no other devices or tasks that want to use suspend_again
feature, the platform_suspend_ops may directly refer to cm_suspend_again
for its suspend_again callback.
The cm_suspend_again() returns true (meaning "I want to suspend again")
if the system was woken up by Charger Manager and the polling
(in-suspend monitoring) results in "normal".
4. Charger-Manager Data (struct charger_desc)
=============================================
For each battery charged independently from other batteries (if a series of
batteries are charged by a single charger, they are counted as one independent
battery), an instance of Charger Manager is attached to it.
struct charger_desc {
char *psy_name;
: The power-supply-class name of the battery. Default is
"battery" if psy_name is NULL. Users can access the psy entries
at "/sys/class/power_supply/[psy_name]/".
enum polling_modes polling_mode;
: CM_POLL_DISABLE: do not poll this battery.
CM_POLL_ALWAYS: always poll this battery.
CM_POLL_EXTERNAL_POWER_ONLY: poll this battery if and only if
an external power source is attached.
CM_POLL_CHARGING_ONLY: poll this battery if and only if the
battery is being charged.
unsigned int fullbatt_uV;
: If specified with a non-zero value, Charger Manager assumes
that the battery is full (capacity = 100) if the battery is not being
charged and the battery voltage is equal to or greater than
fullbatt_uV.
unsigned int polling_interval_ms;
: Required polling interval in ms. Charger Manager will poll
this battery every polling_interval_ms or more frequently.
enum data_source battery_present;
CM_FUEL_GAUGE: get battery presence information from fuel gauge.
CM_CHARGER_STAT: get battery presence from chargers.
char **psy_charger_stat;
: An array ending with NULL that has power-supply-class names of
chargers. Each power-supply-class should provide "PRESENT" (if
battery_present is "CM_CHARGER_STAT"), "ONLINE" (shows whether an
external power source is attached or not), and "STATUS" (shows whether
the battery is {"FULL" or not FULL} or {"FULL", "Charging",
"Discharging", "NotCharging"}).
int num_charger_regulators;
struct regulator_bulk_data *charger_regulators;
: Regulators representing the chargers in the form for
regulator framework's bulk functions.
char *psy_fuel_gauge;
: Power-supply-class name of the fuel gauge.
int (*temperature_out_of_range)(int *mC);
bool measure_battery_temp;
: This callback returns 0 if the temperature is safe for charging,
a positive number if it is too hot to charge, and a negative number
if it is too cold to charge. With the variable mC, the callback returns
the temperature in 1/1000 of centigrade.
The source of temperature can be battery or ambient one according to
the value of measure_battery_temp.
};
5. Other Considerations
=======================
At the charger/battery-related events such as battery-pulled-out,
charger-pulled-out, charger-inserted, DCIN-over/under-voltage, charger-stopped,
and others critical to chargers, the system should be configured to wake up.
At least the following should wake up the system from a suspend:
a) charger-on/off b) external-power-in/out c) battery-in/out (while charging)
It is usually accomplished by configuring the PMIC as a wakeup source.

37
Documentation/power/devices.txt
View File

@ -126,7 +126,9 @@ The core methods to suspend and resume devices reside in struct dev_pm_ops
pointed to by the ops member of struct dev_pm_domain, or by the pm member of
struct bus_type, struct device_type and struct class. They are mostly of
interest to the people writing infrastructure for platforms and buses, like PCI
or USB, or device type and device class drivers.
or USB, or device type and device class drivers. They also are relevant to the
writers of device drivers whose subsystems (PM domains, device types, device
classes and bus types) don't provide all power management methods.
Bus drivers implement these methods as appropriate for the hardware and the
drivers using it; PCI works differently from USB, and so on. Not many people
@ -268,32 +270,35 @@ various phases always run after tasks have been frozen and before they are
unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have
been disabled (except for those marked with the IRQF_NO_SUSPEND flag).
All phases use PM domain, bus, type, or class callbacks (that is, methods
defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).
These callbacks are regarded by the PM core as mutually exclusive. Moreover,
PM domain callbacks always take precedence over bus, type and class callbacks,
while type callbacks take precedence over bus and class callbacks, and class
callbacks take precedence over bus callbacks. To be precise, the following
rules are used to determine which callback to execute in the given phase:
All phases use PM domain, bus, type, class or driver callbacks (that is, methods
defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, dev->class->pm or
dev->driver->pm). These callbacks are regarded by the PM core as mutually
exclusive. Moreover, PM domain callbacks always take precedence over all of the
other callbacks and, for example, type callbacks take precedence over bus, class
and driver callbacks. To be precise, the following rules are used to determine
which callback to execute in the given phase:
1. If dev->pm_domain is present, the PM core will attempt to execute the
callback included in dev->pm_domain->ops. If that callback is not
present, no action will be carried out for the given device.
1. If dev->pm_domain is present, the PM core will choose the callback
included in dev->pm_domain->ops for execution
2. Otherwise, if both dev->type and dev->type->pm are present, the callback
included in dev->type->pm will be executed.
included in dev->type->pm will be chosen for execution.
3. Otherwise, if both dev->class and dev->class->pm are present, the
callback included in dev->class->pm will be executed.
callback included in dev->class->pm will be chosen for execution.
4. Otherwise, if both dev->bus and dev->bus->pm are present, the callback
included in dev->bus->pm will be executed.
included in dev->bus->pm will be chosen for execution.
This allows PM domains and device types to override callbacks provided by bus
types or device classes if necessary.
These callbacks may in turn invoke device- or driver-specific methods stored in
dev->driver->pm, but they don't have to.
The PM domain, type, class and bus callbacks may in turn invoke device- or
driver-specific methods stored in dev->driver->pm, but they don't have to do
that.
If the subsystem callback chosen for execution is not present, the PM core will
execute the corresponding method from dev->driver->pm instead if there is one.
Entering System Suspend

39
Documentation/power/freezing-of-tasks.txt
View File

@ -21,7 +21,7 @@ freeze_processes() (defined in kernel/power/process.c) is called. It executes
try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
either wakes them up, if they are kernel threads, or sends fake signals to them,
if they are user space processes. A task that has TIF_FREEZE set, should react
to it by calling the function called refrigerator() (defined in
to it by calling the function called __refrigerator() (defined in
kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
Then, we say that the task is 'frozen' and therefore the set of functions
@ -29,10 +29,10 @@ handling this mechanism is referred to as 'the freezer' (these functions are
defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
User space processes are generally frozen before kernel threads.
It is not recommended to call refrigerator() directly. Instead, it is
recommended to use the try_to_freeze() function (defined in
include/linux/freezer.h), that checks the task's TIF_FREEZE flag and makes the
task enter refrigerator() if the flag is set.
__refrigerator() must not be called directly. Instead, use the
try_to_freeze() function (defined in include/linux/freezer.h), that checks
the task's TIF_FREEZE flag and makes the task enter __refrigerator() if the
flag is set.
For user space processes try_to_freeze() is called automatically from the
signal-handling code, but the freezable kernel threads need to call it
@ -61,13 +61,13 @@ wait_event_freezable() and wait_event_freezable_timeout() macros.
After the system memory state has been restored from a hibernation image and
devices have been reinitialized, the function thaw_processes() is called in
order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
have been frozen leave refrigerator() and continue running.
have been frozen leave __refrigerator() and continue running.
III. Which kernel threads are freezable?
Kernel threads are not freezable by default. However, a kernel thread may clear
PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
directly is strongly discouraged). From this point it is regarded as freezable
directly is not allowed). From this point it is regarded as freezable
and must call try_to_freeze() in a suitable place.
IV. Why do we do that?
@ -176,3 +176,28 @@ tasks, since it generally exists anyway.
A driver must have all firmwares it may need in RAM before suspend() is called.
If keeping them is not practical, for example due to their size, they must be
requested early enough using the suspend notifier API described in notifiers.txt.
VI. Are there any precautions to be taken to prevent freezing failures?
Yes, there are.
First of all, grabbing the 'pm_mutex' lock to mutually exclude a piece of code
from system-wide sleep such as suspend/hibernation is not encouraged.
If possible, that piece of code must instead hook onto the suspend/hibernation
notifiers to achieve mutual exclusion. Look at the CPU-Hotplug code
(kernel/cpu.c) for an example.
However, if that is not feasible, and grabbing 'pm_mutex' is deemed necessary,
it is strongly discouraged to directly call mutex_[un]lock(&pm_mutex) since
that could lead to freezing failures, because if the suspend/hibernate code
successfully acquired the 'pm_mutex' lock, and hence that other entity failed
to acquire the lock, then that task would get blocked in TASK_UNINTERRUPTIBLE
state. As a consequence, the freezer would not be able to freeze that task,
leading to freezing failure.
However, the [un]lock_system_sleep() APIs are safe to use in this scenario,
since they ask the freezer to skip freezing this task, since it is anyway
"frozen enough" as it is blocked on 'pm_mutex', which will be released
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.

2
Documentation/power/regulator/regulator.txt
View File

@ -12,7 +12,7 @@ Drivers can register a regulator by calling :-
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
struct device *dev, struct regulator_init_data *init_data,
void *driver_data);
void *driver_data, struct device_node *of_node);
This will register the regulators capabilities and operations to the regulator
core.

114
Documentation/power/runtime_pm.txt
View File

@ -57,6 +57,10 @@ the following:
4. Bus type of the device, if both dev->bus and dev->bus->pm are present.
If the subsystem chosen by applying the above rules doesn't provide the relevant
callback, the PM core will invoke the corresponding driver callback stored in
dev->driver->pm directly (if present).
The PM core always checks which callback to use in the order given above, so the
priority order of callbacks from high to low is: PM domain, device type, class
and bus type. Moreover, the high-priority one will always take precedence over
@ -64,86 +68,88 @@ a low-priority one. The PM domain, bus type, device type and class callbacks
are referred to as subsystem-level callbacks in what follows.
By default, the callbacks are always invoked in process context with interrupts
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
to tell the PM core that their ->runtime_suspend(), ->runtime_resume() and
->runtime_idle() callbacks may be invoked in atomic context with interrupts
disabled for a given device. This implies that the callback routines in
question must not block or sleep, but it also means that the synchronous helper
functions listed at the end of Section 4 may be used for that device within an
interrupt handler or generally in an atomic context.
enabled. However, the pm_runtime_irq_safe() helper function can be used to tell
the PM core that it is safe to run the ->runtime_suspend(), ->runtime_resume()
and ->runtime_idle() callbacks for the given device in atomic context with
interrupts disabled. This implies that the callback routines in question must
not block or sleep, but it also means that the synchronous helper functions
listed at the end of Section 4 may be used for that device within an interrupt
handler or generally in an atomic context.
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
the suspend of the device as appropriate, which may, but need not include
executing the device driver's own ->runtime_suspend() callback (from the
The subsystem-level suspend callback, if present, is _entirely_ _responsible_
for handling the suspend of the device as appropriate, which may, but need not
include executing the device driver's own ->runtime_suspend() callback (from the
PM core's point of view it is not necessary to implement a ->runtime_suspend()
callback in a device driver as long as the subsystem-level suspend callback
knows what to do to handle the device).
* Once the subsystem-level suspend callback has completed successfully
for given device, the PM core regards the device as suspended, which need
not mean that the device has been put into a low power state. It is
supposed to mean, however, that the device will not process data and will
not communicate with the CPU(s) and RAM until the subsystem-level resume
callback is executed for it. The runtime PM status of a device after
successful execution of the subsystem-level suspend callback is 'suspended'.
* Once the subsystem-level suspend callback (or the driver suspend callback,
if invoked directly) has completed successfully for the given device, the PM
core regards the device as suspended, which need not mean that it has been
put into a low power state. It is supposed to mean, however, that the
device will not process data and will not communicate with the CPU(s) and
RAM until the appropriate resume callback is executed for it. The runtime
PM status of a device after successful execution of the suspend callback is
'suspended'.
* If the subsystem-level suspend callback returns -EBUSY or -EAGAIN,
the device's runtime PM status is 'active', which means that the device
_must_ be fully operational afterwards.
* If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
status remains 'active', which means that the device _must_ be fully
operational afterwards.
* If the subsystem-level suspend callback returns an error code different
from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will
refuse to run the helper functions described in Section 4 for the device,
until the status of it is directly set either to 'active', or to 'suspended'
(the PM core provides special helper functions for this purpose).
* If the suspend callback returns an error code different from -EBUSY and
-EAGAIN, the PM core regards this as a fatal error and will refuse to run
the helper functions described in Section 4 for the device until its status
is directly set to either'active', or 'suspended' (the PM core provides
special helper functions for this purpose).
In particular, if the driver requires remote wake-up capability (i.e. hardware
In particular, if the driver requires remote wakeup capability (i.e. hardware
mechanism allowing the device to request a change of its power state, such as
PCI PME) for proper functioning and device_run_wake() returns 'false' for the
device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
device_run_wake() returns 'true' for the device and the device is put into a low
power state during the execution of the subsystem-level suspend callback, it is
expected that remote wake-up will be enabled for the device. Generally, remote
wake-up should be enabled for all input devices put into a low power state at
run time.
device_run_wake() returns 'true' for the device and the device is put into a
low-power state during the execution of the suspend callback, it is expected
that remote wakeup will be enabled for the device. Generally, remote wakeup
should be enabled for all input devices put into low-power states at run time.
The subsystem-level resume callback is _entirely_ _responsible_ for handling the
resume of the device as appropriate, which may, but need not include executing
the device driver's own ->runtime_resume() callback (from the PM core's point of
view it is not necessary to implement a ->runtime_resume() callback in a device
driver as long as the subsystem-level resume callback knows what to do to handle
the device).
The subsystem-level resume callback, if present, is _entirely_ _responsible_ for
handling the resume of the device as appropriate, which may, but need not
include executing the device driver's own ->runtime_resume() callback (from the
PM core's point of view it is not necessary to implement a ->runtime_resume()
callback in a device driver as long as the subsystem-level resume callback knows
what to do to handle the device).
* Once the subsystem-level resume callback has completed successfully, the PM
core regards the device as fully operational, which means that the device
_must_ be able to complete I/O operations as needed. The runtime PM status
of the device is then 'active'.
* Once the subsystem-level resume callback (or the driver resume callback, if
invoked directly) has completed successfully, the PM core regards the device
as fully operational, which means that the device _must_ be able to complete
I/O operations as needed. The runtime PM status of the device is then
'active'.
* If the subsystem-level resume callback returns an error code, the PM core
regards this as a fatal error and will refuse to run the helper functions
described in Section 4 for the device, until its status is directly set
either to 'active' or to 'suspended' (the PM core provides special helper
functions for this purpose).
* If the resume callback returns an error code, the PM core regards this as a
fatal error and will refuse to run the helper functions described in Section
4 for the device, until its status is directly set to either 'active', or
'suspended' (by means of special helper functions provided by the PM core
for this purpose).
The subsystem-level idle callback is executed by the PM core whenever the device
appears to be idle, which is indicated to the PM core by two counters, the
device's usage counter and the counter of 'active' children of the device.
The idle callback (a subsystem-level one, if present, or the driver one) is
executed by the PM core whenever the device appears to be idle, which is
indicated to the PM core by two counters, the device's usage counter and the
counter of 'active' children of the device.
* If any of these counters is decreased using a helper function provided by
the PM core and it turns out to be equal to zero, the other counter is
checked. If that counter also is equal to zero, the PM core executes the
subsystem-level idle callback with the device as an argument.
idle callback with the device as its argument.
The action performed by a subsystem-level idle callback is totally dependent on
the subsystem in question, but the expected and recommended action is to check
The action performed by the idle callback is totally dependent on the subsystem
(or driver) in question, but the expected and recommended action is to check
if the device can be suspended (i.e. if all of the conditions necessary for
suspending the device are satisfied) and to queue up a suspend request for the
device in that case. The value returned by this callback is ignored by the PM
core.
The helper functions provided by the PM core, described in Section 4, guarantee
that the following constraints are met with respect to the bus type's runtime
PM callbacks:
that the following constraints are met with respect to runtime PM callbacks for
one device:
(1) The callbacks are mutually exclusive (e.g. it is forbidden to execute
->runtime_suspend() in parallel with ->runtime_resume() or with another

34
Documentation/s390/Debugging390.txt
View File

@ -41,7 +41,6 @@ ldd
Debugging modules
The proc file system
Starting points for debugging scripting languages etc.
Dumptool & Lcrash
SysRq
References
Special Thanks
@ -2455,39 +2454,6 @@ jdb <filename> another fully interactive gdb style debugger.
Dumptool & Lcrash ( lkcd )
==========================
Michael Holzheu & others here at IBM have a fairly mature port of
SGI's lcrash tool which allows one to look at kernel structures in a
running kernel.
It also complements a tool called dumptool which dumps all the kernel's
memory pages & registers to either a tape or a disk.
This can be used by tech support or an ambitious end user do
post mortem debugging of a machine like gdb core dumps.
Going into how to use this tool in detail will be explained
in other documentation supplied by IBM with the patches & the
lcrash homepage http://oss.sgi.com/projects/lkcd/ & the lcrash manpage.
How they work
-------------
Lcrash is a perfectly normal program,however, it requires 2
additional files, Kerntypes which is built using a patch to the
linux kernel sources in the linux root directory & the System.map.
Kerntypes is an objectfile whose sole purpose in life
is to provide stabs debug info to lcrash, to do this
Kerntypes is built from kerntypes.c which just includes the most commonly
referenced header files used when debugging, lcrash can then read the
.stabs section of this file.
Debugging a live system it uses /dev/mem
alternatively for post mortem debugging it uses the data
collected by dumptool.
SysRq
=====
This is now supported by linux for s/390 & z/Architecture.

21
Documentation/scsi/53c700.txt
View File

@ -16,32 +16,13 @@ fill in to get the driver working.
Compile Time Flags
==================
The driver may be either io mapped or memory mapped. This is
selectable by configuration flags:
CONFIG_53C700_MEM_MAPPED
define if the driver is memory mapped.
CONFIG_53C700_IO_MAPPED
define if the driver is to be io mapped.
One or other of the above flags *must* be defined.
Other flags are:
A compile time flag is:
CONFIG_53C700_LE_ON_BE
define if the chipset must be supported in little endian mode on a big
endian architecture (used for the 700 on parisc).
CONFIG_53C700_USE_CONSISTENT
allocate consistent memory (should only be used if your architecture
has a mixture of consistent and inconsistent memory). Fully
consistent or fully inconsistent architectures should not define this.
Using the Chip Core Driver
==========================

2
Documentation/security/00-INDEX
View File

@ -1,5 +1,7 @@
00-INDEX
- this file.
LSM.txt
- description of the Linux Security Module framework.
SELinux.txt
- how to get started with the SELinux security enhancement.
Smack.txt

34
Documentation/security/LSM.txt Normal file
View File

@ -0,0 +1,34 @@
Linux Security Module framework
-------------------------------
The Linux Security Module (LSM) framework provides a mechanism for
various security checks to be hooked by new kernel extensions. The name
"module" is a bit of a misnomer since these extensions are not actually
loadable kernel modules. Instead, they are selectable at build-time via
CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the
"security=..." kernel command line argument, in the case where multiple
LSMs were built into a given kernel.
The primary users of the LSM interface are Mandatory Access Control
(MAC) extensions which provide a comprehensive security policy. Examples
include SELinux, Smack, Tomoyo, and AppArmor. In addition to the larger
MAC extensions, other extensions can be built using the LSM to provide
specific changes to system operation when these tweaks are not available
in the core functionality of Linux itself.
Without a specific LSM built into the kernel, the default LSM will be the
Linux capabilities system. Most LSMs choose to extend the capabilities
system, building their checks on top of the defined capability hooks.
For more details on capabilities, see capabilities(7) in the Linux
man-pages project.
Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent,
a new LSM is accepted into the kernel when its intent (a description of
what it tries to protect against and in what cases one would expect to
use it) has been appropriately documented in Documentation/security/.
This allows an LSM's code to be easily compared to its goals, and so
that end users and distros can make a more informed decision about which
LSMs suit their requirements.
For extensive documentation on the available LSM hook interfaces, please
see include/linux/security.h.

6
Documentation/security/credentials.txt
View File

@ -221,10 +221,10 @@ The Linux kernel supports the following types of credentials:
(5) LSM
The Linux Security Module allows extra controls to be placed over the
operations that a task may do. Currently Linux supports two main
alternate LSM options: SELinux and Smack.
operations that a task may do. Currently Linux supports several LSM
options.
Both work by labelling the objects in a system and then applying sets of
Some work by labelling the objects in a system and then applying sets of
rules (policies) that say what operations a task with one label may do to
an object with another label.

2
Documentation/serial/driver
View File

@ -101,7 +101,7 @@ hardware.
Returns the current state of modem control inputs. The state
of the outputs should not be returned, since the core keeps
track of their state. The state information should include:
- TIOCM_DCD state of DCD signal
- TIOCM_CAR state of DCD signal
- TIOCM_CTS state of CTS signal
- TIOCM_DSR state of DSR signal
- TIOCM_RI state of RI signal

15
Documentation/sound/alsa/HD-Audio-Models.txt
View File

@ -42,19 +42,7 @@ ALC260
ALC262
======
fujitsu Fujitsu Laptop
benq Benq ED8
benq-t31 Benq T31
hippo Hippo (ATI) with jack detection, Sony UX-90s
hippo_1 Hippo (Benq) with jack detection
toshiba-s06 Toshiba S06
toshiba-rx1 Toshiba RX1
tyan Tyan Thunder n6650W (S2915-E)
ultra Samsung Q1 Ultra Vista model
lenovo-3000 Lenovo 3000 y410
nec NEC Versa S9100
basic fixed pin assignment w/o SPDIF
auto auto-config reading BIOS (default)
N/A
ALC267/268
==========
@ -350,7 +338,6 @@ STAC92HD83*
mic-ref Reference board with power management for ports
dell-s14 Dell laptop
dell-vostro-3500 Dell Vostro 3500 laptop
hp HP laptops with (inverted) mute-LED
hp-dv7-4000 HP dv-7 4000
auto BIOS setup (default)

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