mirrors/linux
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-05-01 08:21:04 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'staging/for_v3.4' into v4l_for_linus

Browse Source 
* staging/for_v3.4: (10117 commits)
  [media] update CARDLIST.em28xx
  [media] partially reverts changeset fa5527c
  [media] stb0899: fix the limits for signal strength values
  [media] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
  [media] em28xx: support for 2013:0251 PCTV QuatroStick nano (520e)
  [media] -EINVAL -> -ENOTTY
  [media] gspca - sn9c20x: Cleanup source
  [media] gspca - sn9c20x: Simplify register write for capture start/stop
  [media] gspca - sn9c20x: Add automatic JPEG compression mechanism
  [media] gspca - sn9c20x: Greater delay in case of sensor no response
  [media] gspca - sn9c20x: Optimize the code of write sequences
  [media] gspca - sn9c20x: Add the JPEG compression quality control
  [media] gspca - sn9c20x: Add a delay after Omnivision sensor reset
  [media] gspca - sn9c20x: Propagate USB errors to higher level
  [media] gspca - sn9c20x: Use the new video control mechanism
  [media] gspca - sn9c20x: Fix loss of frame start
  [media] gspca - zc3xx: Lack of register 08 value for sensor cs2102k
  [media] gspca - ov534_9: Add brightness to OmniVision 5621 sensor
  [media] gspca - zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
  [media] pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5
  ...
This commit is contained in:
Mauro Carvalho Chehab
2012-03-23 08:06:43 -03:00
parent 3e85fc1b9f f92c97c8bd
commit 7483d45f0a
10168 changed files with 459751 additions and 298034 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
CREDITS
View File

@@ -514,6 +514,11 @@ S: Bessemerstraat 21
S: Amsterdam
S: The Netherlands
N: NeilBrown
E: neil@brown.name
P: 4096R/566281B9 1BC6 29EB D390 D870 7B5F 497A 39EC 9EDD 5662 81B9
D: NFSD Maintainer 2000-2007
N: Zach Brown
E: zab@zabbo.net
D: maestro pci sound

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<EFBFBD> <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

16
Documentation/ABI/testing/sysfs-module
View File

@@ -33,3 +33,19 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
Beware, non-standard modes are usually not thoroughly tested by
hardware designers, and the hardware can malfunction when this
setting differ from default 100.
What: /sys/module/*/{coresize,initsize}
Date: Jan 2012
KernelVersion:»·3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module size in bytes.
What: /sys/module/*/taint
Date: Jan 2012
KernelVersion:»·3.3
Contact: Kay Sievers <kay.sievers@vrfy.org>
Description: Module taint flags:
P - proprietary module
O - out-of-tree module
F - force-loaded module
C - staging driver module

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>

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

@@ -50,7 +50,9 @@
<sect1><title>Delaying, scheduling, and timer routines</title>
!Iinclude/linux/sched.h
!Ekernel/sched.c
!Ekernel/sched/core.c
!Ikernel/sched/cpupri.c
!Ikernel/sched/fair.c
!Iinclude/linux/completion.h
!Ekernel/timer.c
</sect1>
@@ -100,9 +102,12 @@ X!Iinclude/linux/kobject.h
!Iinclude/linux/device.h
</sect1>
<sect1><title>Device Drivers Base</title>
!Idrivers/base/init.c
!Edrivers/base/driver.c
!Edrivers/base/core.c
!Edrivers/base/syscore.c
!Edrivers/base/class.c
!Idrivers/base/node.c
!Edrivers/base/firmware_class.c
!Edrivers/base/transport_class.c
<!-- Cannot be included, because
@@ -111,13 +116,18 @@ X!Iinclude/linux/kobject.h
exceed allowed 44 characters maximum
X!Edrivers/base/attribute_container.c
-->
!Edrivers/base/sys.c
!Edrivers/base/dd.c
<!--
X!Edrivers/base/interface.c
-->
!Iinclude/linux/platform_device.h
!Edrivers/base/platform.c
!Edrivers/base/bus.c
</sect1>
<sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-buf.c
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
</sect1>
<sect1><title>Device Drivers Power Management</title>
!Edrivers/base/power/main.c
@@ -216,9 +226,8 @@ X!Isound/sound_firmware.c
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
!Iinclude/linux/serial_core.h
!Edrivers/tty/serial/serial_core.c
!Edrivers/tty/serial/8250.c
!Edrivers/tty/serial/8250/8250.c
</chapter>
<chapter id="fbdev">

2
Documentation/DocBook/deviceiobook.tmpl
View File

@@ -317,7 +317,7 @@ CPU B: spin_unlock_irqrestore(&amp;dev_lock, flags)
<chapter id="pubfunctions">
<title>Public Functions Provided</title>
!Iarch/x86/include/asm/io.h
!Elib/iomap.c
!Elib/pci_iomap.c
</chapter>
</book>

20
Documentation/DocBook/media/v4l/biblio.xml
View File

@@ -128,6 +128,26 @@ url="http://www.ijg.org">http://www.ijg.org</ulink>)</corpauthor>
<subtitle>Version 1.02</subtitle>
</biblioentry>
<biblioentry id="itu-t81">
<abbrev>ITU-T.81</abbrev>
<authorgroup>
<corpauthor>International Telecommunication Union
(<ulink url="http://www.itu.int">http://www.itu.int</ulink>)</corpauthor>
</authorgroup>
<title>ITU-T Recommendation T.81
"Information Technology &mdash; Digital Compression and Coding of Continous-Tone
Still Images &mdash; Requirements and Guidelines"</title>
</biblioentry>
<biblioentry id="w3c-jpeg-jfif">
<abbrev>W3C JPEG JFIF</abbrev>
<authorgroup>
<corpauthor>The World Wide Web Consortium (<ulink
url="http://www.w3.org/Graphics/JPEG">http://www.w3.org</ulink>)</corpauthor>
</authorgroup>
<title>JPEG JFIF</title>
</biblioentry>
<biblioentry id="smpte12m">
<abbrev>SMPTE&nbsp;12M</abbrev>
<authorgroup>

14
Documentation/DocBook/media/v4l/compat.xml
View File

@@ -2393,6 +2393,20 @@ details.</para>
to the <link linkend="control">User controls class</link>.
</para>
</listitem>
<listitem>
<para>Added the device_caps field to struct v4l2_capabilities and added the new
V4L2_CAP_DEVICE_CAPS capability.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.4</title>
<orderedlist>
<listitem>
<para>Added <link linkend="jpeg-controls">JPEG compression control
class</link>.</para>
</listitem>
</orderedlist>
</section>

220
Documentation/DocBook/media/v4l/controls.xml
View File

@@ -1284,6 +1284,49 @@ values are:</entry>
capturing. This is not done by muting audio hardware, which can still
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-audio-dec-playback">
<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant>&nbsp;</entry>
<entry>enum&nbsp;v4l2_mpeg_audio_dec_playback</entry>
</row><row><entry spanname="descr">Determines how monolingual audio should be played back.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO</constant>&nbsp;</entry>
<entry>Automatically determines the best playback mode.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO</constant>&nbsp;</entry>
<entry>Stereo playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT</constant>&nbsp;</entry>
<entry>Left channel playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT</constant>&nbsp;</entry>
<entry>Right channel playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO</constant>&nbsp;</entry>
<entry>Mono playback.</entry>
</row>
<row>
<entry><constant>V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO</constant>&nbsp;</entry>
<entry>Stereo playback with swapped left and right channels.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-audio-dec-multilingual-playback">
<entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant>&nbsp;</entry>
<entry>enum&nbsp;v4l2_mpeg_audio_dec_playback</entry>
</row><row><entry spanname="descr">Determines how multilingual audio should be played back.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-encoding">
@@ -1447,6 +1490,22 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-dec-pts">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DEC_PTS</constant>&nbsp;</entry>
<entry>integer64</entry>
</row><row><entry spanname="descr">This read-only control returns the
33-bit video Presentation Time Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of
the currently displayed frame. This is the same PTS as is used in &VIDIOC-DECODER-CMD;.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-dec-frame">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant>&nbsp;</entry>
<entry>integer64</entry>
</row><row><entry spanname="descr">This read-only control returns the
frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever
the decoder is started.</entry>
</row>
<row><entry></entry></row>
@@ -3377,6 +3436,167 @@ interface and may change in the future.</para>
</tbody>
</tgroup>
</table>
</section>
<section id="jpeg-controls">
<title>JPEG Control Reference</title>
<para>The JPEG class includes controls for common features of JPEG
encoders and decoders. Currently it includes features for codecs
implementing progressive baseline DCT compression process with
Huffman entrophy coding.</para>
<table pgwide="1" frame="none" id="jpeg-control-id">
<title>JPEG Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_JPEG_CLASS</constant>&nbsp;</entry>
<entry>class</entry>
</row><row><entry spanname="descr">The JPEG class descriptor. Calling
&VIDIOC-QUERYCTRL; for this control will return a description of this
control class.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_JPEG_CHROMA_SUBSAMPLING</constant></entry>
<entry>menu</entry>
</row>
<row id="jpeg-chroma-subsampling-control">
<entry spanname="descr">The chroma subsampling factors describe how
each component of an input image is sampled, in respect to maximum
sample rate in each spatial dimension. See <xref linkend="itu-t81"/>,
clause A.1.1. for more details. The <constant>
V4L2_CID_JPEG_CHROMA_SUBSAMPLING</constant> control determines how
Cb and Cr components are downsampled after coverting an input image
from RGB to Y'CbCr color space.
</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_444</constant>
</entry><entry>No chroma subsampling, each pixel has
Y, Cr and Cb values.</entry>
</row>
<row>
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_422</constant>
</entry><entry>Horizontally subsample Cr, Cb components
by a factor of 2.</entry>
</row>
<row>
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_420</constant>
</entry><entry>Subsample Cr, Cb components horizontally
and vertically by 2.</entry>
</row>
<row>
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_411</constant>
</entry><entry>Horizontally subsample Cr, Cb components
by a factor of 4.</entry>
</row>
<row>
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_410</constant>
</entry><entry>Subsample Cr, Cb components horizontally
by 4 and vertically by 2.</entry>
</row>
<row>
<entry><constant>V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY</constant>
</entry><entry>Use only luminance component.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_JPEG_RESTART_INTERVAL</constant>
</entry><entry>integer</entry>
</row>
<row><entry spanname="descr">
The restart interval determines an interval of inserting RSTm
markers (m = 0..7). The purpose of these markers is to additionally
reinitialize the encoder process, in order to process blocks of
an image independently.
For the lossy compression processes the restart interval unit is
MCU (Minimum Coded Unit) and its value is contained in DRI
(Define Restart Interval) marker. If <constant>
V4L2_CID_JPEG_RESTART_INTERVAL</constant> control is set to 0,
DRI and RSTm markers will not be inserted.
</entry>
</row>
<row id="jpeg-quality-control">
<entry spanname="id"><constant>V4L2_CID_JPEG_COMPRESION_QUALITY</constant></entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">
<constant>V4L2_CID_JPEG_COMPRESION_QUALITY</constant> control
determines trade-off between image quality and size.
It provides simpler method for applications to control image quality,
without a need for direct reconfiguration of luminance and chrominance
quantization tables.
In cases where a driver uses quantization tables configured directly
by an application, using interfaces defined elsewhere, <constant>
V4L2_CID_JPEG_COMPRESION_QUALITY</constant> control should be set
by driver to 0.
<para>The value range of this control is driver-specific. Only
positive, non-zero values are meaningful. The recommended range
is 1 - 100, where larger values correspond to better image quality.
</para>
</entry>
</row>
<row id="jpeg-active-marker-control">
<entry spanname="id"><constant>V4L2_CID_JPEG_ACTIVE_MARKER</constant></entry>
<entry>bitmask</entry>
</row>
<row>
<entry spanname="descr">Specify which JPEG markers are included
in compressed stream. This control is valid only for encoders.
</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_APP0</constant></entry>
<entry>Application data segment APP<subscript>0</subscript>.</entry>
</row><row>
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_APP1</constant></entry>
<entry>Application data segment APP<subscript>1</subscript>.</entry>
</row><row>
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_COM</constant></entry>
<entry>Comment segment.</entry>
</row><row>
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_DQT</constant></entry>
<entry>Quantization tables segment.</entry>
</row><row>
<entry><constant>V4L2_JPEG_ACTIVE_MARKER_DHT</constant></entry>
<entry>Huffman tables segment.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
<para>For more details about JPEG specification, refer
to <xref linkend="itu-t81"/>, <xref linkend="jfif"/>,
<xref linkend="w3c-jpeg-jfif"/>.</para>
</section>
</section>

121
Documentation/DocBook/media/v4l/pixfmt-nv24.xml Normal file
View File

@@ -0,0 +1,121 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-NV24"><constant>V4L2_PIX_FMT_NV24</constant></refname>
<refname id="V4L2-PIX-FMT-NV42"><constant>V4L2_PIX_FMT_NV42</constant></refname>
<refpurpose>Formats with full horizontal and vertical
chroma resolutions, also known as YUV 4:4:4. One luminance and one
chrominance plane with alternating chroma samples as opposed to
<constant>V4L2_PIX_FMT_YVU420</constant></refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>These are two-plane versions of the YUV 4:4:4 format. The three
components are separated into two sub-images or planes. The Y plane is
first, with each Y sample stored in one byte per pixel. For
<constant>V4L2_PIX_FMT_NV24</constant>, a combined CbCr plane
immediately follows the Y plane in memory. The CbCr plane has the same
width and height, in pixels, as the Y plane (and the image). Each line
contains one CbCr pair per pixel, with each Cb and Cr sample stored in
one byte. <constant>V4L2_PIX_FMT_NV42</constant> is the same except that
the Cb and Cr samples are swapped, the CrCb plane starts with a Cr
sample.</para>
<para>If the Y plane has pad bytes after each row, then the CbCr plane
has twice as many pad bytes after its rows.</para>
<example>
<title><constant>V4L2_PIX_FMT_NV24</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;32:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;40:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

1
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@@ -714,6 +714,7 @@ information.</para>
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
&sub-nv24;
&sub-m420;
</section>

8
Documentation/DocBook/media/v4l/selection-api.xml
View File

@@ -52,6 +52,10 @@ cropping and composing rectangles have the same size.</para>
</textobject>
</mediaobject>
</figure>
For complete list of the available selection targets see table <xref
linkend="v4l2-sel-target"/>
</section>
<section>
@@ -186,7 +190,7 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
<section>
<title>Scaling control.</title>
<title>Scaling control</title>
<para>An application can detect if scaling is performed by comparing the width
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP_ACTIVE
@@ -200,7 +204,7 @@ the scaling ratios using these values.</para>
<section>
<title>Comparison with old cropping API.</title>
<title>Comparison with old cropping API</title>
<para>The selection API was introduced to cope with deficiencies of previous
<link linkend="crop"> API </link>, that was designed to control simple capture

19
Documentation/DocBook/media/v4l/v4l2.xml
View File

@@ -127,6 +127,22 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.4</revnumber>
<date>2012-01-25</date>
<authorinitials>sn</authorinitials>
<revremark>Added <link linkend="jpeg-controls">JPEG compression
control class.</link>
</revremark>
</revision>
<revision>
<revnumber>3.3</revnumber>
<date>2012-01-11</date>
<authorinitials>hv</authorinitials>
<revremark>Added device_caps field to struct v4l2_capabilities.</revremark>
</revision>
<revision>
<revnumber>3.2</revnumber>
<date>2011-08-26</date>
@@ -417,7 +433,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.2</subtitle>
<subtitle>Revision 3.3</subtitle>
<chapter id="common">
&sub-common;
@@ -473,6 +489,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-cropcap;
&sub-dbg-g-chip-ident;
&sub-dbg-g-register;
&sub-decoder-cmd;
&sub-dqevent;
&sub-encoder-cmd;
&sub-enumaudio;

256
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml Normal file
View File

@@ -0,0 +1,256 @@
<refentry id="vidioc-decoder-cmd">
<refmeta>
<refentrytitle>ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_DECODER_CMD</refname>
<refname>VIDIOC_TRY_DECODER_CMD</refname>
<refpurpose>Execute an decoder command</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_decoder_cmd *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls control an audio/video (usually MPEG-) decoder.
<constant>VIDIOC_DECODER_CMD</constant> sends a command to the
decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to
try a command without actually executing it. To send a command applications
must initialize all fields of a &v4l2-decoder-cmd; and call
<constant>VIDIOC_DECODER_CMD</constant> or <constant>VIDIOC_TRY_DECODER_CMD</constant>
with a pointer to this structure.</para>
<para>The <structfield>cmd</structfield> field must contain the
command code. Some commands use the <structfield>flags</structfield> field for
additional information.
</para>
<para>A <function>write</function>() or &VIDIOC-STREAMON; call sends an implicit
START command to the decoder if it has not been started yet.
</para>
<para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming
file descriptor sends an implicit immediate STOP command to the decoder, and all
buffered data is discarded.</para>
<para>These ioctls are optional, not all drivers may support
them. They were introduced in Linux 3.3.</para>
<table pgwide="1" frame="none" id="v4l2-decoder-cmd">
<title>struct <structname>v4l2_decoder_cmd</structname></title>
<tgroup cols="5">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>cmd</structfield></entry>
<entry></entry>
<entry></entry>
<entry>The decoder command, see <xref linkend="decoder-cmds" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Flags to go with the command. If no flags are defined for
this command, drivers and applications must set this field to zero.</entry>
</row>
<row>
<entry>union</entry>
<entry>(anonymous)</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>start</structfield></entry>
<entry></entry>
<entry>Structure containing additional data for the
<constant>V4L2_DEC_CMD_START</constant> command.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__s32</entry>
<entry><structfield>speed</structfield></entry>
<entry>Playback speed and direction. The playback speed is defined as
<structfield>speed</structfield>/1000 of the normal speed. So 1000 is normal playback.
Negative numbers denote reverse playback, so -1000 does reverse playback at normal
speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000
(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps
just one frame back.
</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>format</structfield></entry>
<entry>Format restrictions. This field is set by the driver, not the
application. Possible values are <constant>V4L2_DEC_START_FMT_NONE</constant> if
there are no format restrictions or <constant>V4L2_DEC_START_FMT_GOP</constant>
if the decoder operates on full GOPs (<wordasword>Group Of Pictures</wordasword>).
This is usually the case for reverse playback: the decoder needs full GOPs, which
it can then play in reverse order. So to implement reverse playback the application
must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc.
</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>stop</structfield></entry>
<entry></entry>
<entry>Structure containing additional data for the
<constant>V4L2_DEC_CMD_STOP</constant> command.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u64</entry>
<entry><structfield>pts</structfield></entry>
<entry>Stop playback at this <structfield>pts</structfield> or immediately
if the playback is already past that timestamp. Leave to 0 if you want to stop after the
last frame was decoded.
</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>raw</structfield></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>data</structfield>[16]</entry>
<entry>Reserved for future extensions. Drivers and
applications must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="decoder-cmds">
<title>Decoder Commands</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_DEC_CMD_START</constant></entry>
<entry>0</entry>
<entry>Start the decoder. When the decoder is already
running or paused, this command will just change the playback speed.
That means that calling <constant>V4L2_DEC_CMD_START</constant> when
the decoder was paused will <emphasis>not</emphasis> resume the decoder.
You have to explicitly call <constant>V4L2_DEC_CMD_RESUME</constant> for that.
This command has one flag:
<constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant>. If set, then audio will
be muted when playing back at a non-standard speed.
</entry>
</row>
<row>
<entry><constant>V4L2_DEC_CMD_STOP</constant></entry>
<entry>1</entry>
<entry>Stop the decoder. When the decoder is already stopped,
this command does nothing. This command has two flags:
if <constant>V4L2_DEC_CMD_STOP_TO_BLACK</constant> is set, then the decoder will
set the picture to black after it stopped decoding. Otherwise the last image will
repeat. If <constant>V4L2_DEC_CMD_STOP_IMMEDIATELY</constant> is set, then the decoder
stops immediately (ignoring the <structfield>pts</structfield> value), otherwise it
will keep decoding until timestamp >= pts or until the last of the pending data from
its internal buffers was decoded.
</entry>
</row>
<row>
<entry><constant>V4L2_DEC_CMD_PAUSE</constant></entry>
<entry>2</entry>
<entry>Pause the decoder. When the decoder has not been
started yet, the driver will return an &EPERM;. When the decoder is
already paused, this command does nothing. This command has one flag:
if <constant>V4L2_DEC_CMD_PAUSE_TO_BLACK</constant> is set, then set the
decoder output to black when paused.
</entry>
</row>
<row>
<entry><constant>V4L2_DEC_CMD_RESUME</constant></entry>
<entry>3</entry>
<entry>Resume decoding after a PAUSE command. When the
decoder has not been started yet, the driver will return an &EPERM;.
When the decoder is already running, this command does nothing. No
flags are defined for this command.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>cmd</structfield> field is invalid.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EPERM</errorcode></term>
<listitem>
<para>The application sent a PAUSE or RESUME command when
the decoder was not running.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

9
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
View File

@@ -74,15 +74,16 @@ only used by the STOP command and contains one bit: If the
encoding will continue until the end of the current <wordasword>Group
Of Pictures</wordasword>, otherwise it will stop immediately.</para>
<para>A <function>read</function>() call sends a START command to
the encoder if it has not been started yet. After a STOP command,
<para>A <function>read</function>() or &VIDIOC-STREAMON; call sends an implicit
START command to the encoder if it has not been started yet. After a STOP command,
<function>read</function>() calls will read the remaining data
buffered by the driver. When the buffer is empty,
<function>read</function>() will return zero and the next
<function>read</function>() call will restart the encoder.</para>
<para>A <function>close</function>() call sends an immediate STOP
to the encoder, and all buffered data is discarded.</para>
<para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming
file descriptor sends an implicit immediate STOP to the encoder, and all buffered
data is discarded.</para>
<para>These ioctls are optional, not all drivers may support
them. They were introduced in Linux 2.6.21.</para>

16
Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml
View File

@@ -57,6 +57,11 @@
<refsect1>
<title>Description</title>
<para>These ioctls are <emphasis role="bold">deprecated</emphasis>.
New drivers and applications should use <link linkend="jpeg-controls">
JPEG class controls</link> for image quality and JPEG markers control.
</para>
<para>[to do]</para>
<para>Ronald Bultje elaborates:</para>
@@ -86,7 +91,10 @@ to add them.</para>
<row>
<entry>int</entry>
<entry><structfield>quality</structfield></entry>
<entry></entry>
<entry>Deprecated. If <link linkend="jpeg-quality-control"><constant>
V4L2_CID_JPEG_IMAGE_QUALITY</constant></link> control is exposed by
a driver applications should use it instead and ignore this field.
</entry>
</row>
<row>
<entry>int</entry>
@@ -116,7 +124,11 @@ to add them.</para>
<row>
<entry>__u32</entry>
<entry><structfield>jpeg_markers</structfield></entry>
<entry>See <xref linkend="jpeg-markers" />.</entry>
<entry>See <xref linkend="jpeg-markers"/>. Deprecated.
If <link linkend="jpeg-active-marker-control"><constant>
V4L2_CID_JPEG_ACTIVE_MARKER</constant></link> control
is exposed by a driver applications should use it instead
and ignore this field.</entry>
</row>
</tbody>
</tgroup>

106
Documentation/DocBook/media/v4l/vidioc-g-selection.xml
View File

@@ -58,43 +58,43 @@
<para>The ioctls are used to query and configure selection rectangles.</para>
<para> To query the cropping (composing) rectangle set <structfield>
&v4l2-selection;::type </structfield> to the respective buffer type. Do not
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
<para> To query the cropping (composing) rectangle set &v4l2-selection;
<structfield> type </structfield> field to the respective buffer type.
Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
setting <structfield> &v4l2-selection;::target </structfield> to value
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
setting the value of &v4l2-selection; <structfield>target</structfield> field
to <constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
targets. Fields <structfield> &v4l2-selection;::flags </structfield> and
<structfield> &v4l2-selection;::reserved </structfield> are ignored and they
must be filled with zeros. The driver fills the rest of the structure or
targets. The <structfield>flags</structfield> and <structfield>reserved
</structfield> fields of &v4l2-selection; are ignored and they must be filled
with zeros. The driver fills the rest of the structure or
returns &EINVAL; if incorrect buffer type or target was used. If cropping
(composing) is not supported then the active rectangle is not mutable and it is
always equal to the bounds rectangle. Finally, structure <structfield>
&v4l2-selection;::r </structfield> is filled with the current cropping
always equal to the bounds rectangle. Finally, the &v4l2-rect;
<structfield>r</structfield> rectangle is filled with the current cropping
(composing) coordinates. The coordinates are expressed in driver-dependent
units. The only exception are rectangles for images in raw formats, whose
coordinates are always expressed in pixels. </para>
<para> To change the cropping (composing) rectangle set <structfield>
&v4l2-selection;::type </structfield> to the respective buffer type. Do not
<para> To change the cropping (composing) rectangle set the &v4l2-selection;
<structfield>type</structfield> field to the respective buffer type. Do not
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
setting <structfield> &v4l2-selection;::target </structfield> to value
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
setting the value of &v4l2-selection; <structfield>target</structfield> to
<constant>V4L2_SEL_TGT_CROP_ACTIVE</constant> (<constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
targets. Set desired active area into the field <structfield>
&v4l2-selection;::r </structfield>. Field <structfield>
&v4l2-selection;::reserved </structfield> is ignored and must be filled with
zeros. The driver may adjust the rectangle coordinates. An application may
introduce constraints to control rounding behaviour. Set the field
<structfield> &v4l2-selection;::flags </structfield> to one of values:
targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
set to the desired active area. Field &v4l2-selection; <structfield> reserved
</structfield> is ignored and must be filled with zeros. The driver may adjust
coordinates of the requested rectangle. An application may
introduce constraints to control rounding behaviour. The &v4l2-selection;
<structfield>flags</structfield> field must be set to one of the following:
<itemizedlist>
<listitem>
@@ -129,7 +129,7 @@ and vertical offset and sizes are chosen according to following priority:
<orderedlist>
<listitem>
<para>Satisfy constraints from <structfield>&v4l2-selection;::flags</structfield>.</para>
<para>Satisfy constraints from &v4l2-selection; <structfield>flags</structfield>.</para>
</listitem>
<listitem>
<para>Adjust width, height, left, and top to hardware limits and alignments.</para>
@@ -145,7 +145,7 @@ and vertical offset and sizes are chosen according to following priority:
</listitem>
</orderedlist>
On success the field <structfield> &v4l2-selection;::r </structfield> contains
On success the &v4l2-rect; <structfield>r</structfield> field contains
the adjusted rectangle. When the parameters are unsuitable the application may
modify the cropping (composing) or image parameters and repeat the cycle until
satisfactory parameters have been negotiated. If constraints flags have to be
@@ -162,38 +162,38 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_TGT_CROP_ACTIVE</constant></entry>
<entry>0</entry>
<entry>area that is currently cropped by hardware</entry>
<entry>0x0000</entry>
<entry>The area that is currently cropped by hardware.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
<entry>1</entry>
<entry>suggested cropping rectangle that covers the "whole picture"</entry>
<entry>0x0001</entry>
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>2</entry>
<entry>limits for the cropping rectangle</entry>
<entry>0x0002</entry>
<entry>Limits for the cropping rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_ACTIVE</constant></entry>
<entry>256</entry>
<entry>area to which data are composed by hardware</entry>
<entry>0x0100</entry>
<entry>The area to which data is composed by hardware.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
<entry>257</entry>
<entry>suggested composing rectangle that covers the "whole picture"</entry>
<entry>0x0101</entry>
<entry>Suggested composing rectangle that covers the "whole picture".</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>258</entry>
<entry>limits for the composing rectangle</entry>
<entry>0x0102</entry>
<entry>Limits for the composing rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
<entry>259</entry>
<entry>the active area and all padding pixels that are inserted or modified by the hardware</entry>
<entry>0x0103</entry>
<entry>The active area and all padding pixels that are inserted or modified by hardware.</entry>
</row>
</tbody>
</tgroup>
@@ -209,12 +209,14 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
<row>
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
<entry>0x00000001</entry>
<entry>indicate that adjusted rectangle must contain a rectangle from <structfield>&v4l2-selection;::r</structfield></entry>
<entry>Indicates that the adjusted rectangle must contain the original
&v4l2-selection; <structfield>r</structfield> rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
<entry>0x00000002</entry>
<entry>indicate that adjusted rectangle must be inside a rectangle from <structfield>&v4l2-selection;::r</structfield></entry>
<entry>Indicates that the adjusted rectangle must be inside the original
&v4l2-rect; <structfield>r</structfield> rectangle.</entry>
</row>
</tbody>
</tgroup>
@@ -245,27 +247,29 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>Type of the buffer (from &v4l2-buf-type;)</entry>
<entry>Type of the buffer (from &v4l2-buf-type;).</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>target</structfield></entry>
<entry>used to select between <link linkend="v4l2-sel-target"> cropping and composing rectangles </link></entry>
<entry>Used to select between <link linkend="v4l2-sel-target"> cropping
and composing rectangles</link>.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>control over coordinates adjustments, refer to <link linkend="v4l2-sel-flags">selection flags</link></entry>
<entry>Flags controlling the selection rectangle adjustments, refer to
<link linkend="v4l2-sel-flags">selection flags</link>.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>
<entry><structfield>r</structfield></entry>
<entry>selection rectangle</entry>
<entry>The selection rectangle.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[9]</structfield></entry>
<entry>Reserved fields for future use</entry>
<entry>Reserved fields for future use.</entry>
</row>
</tbody>
</tgroup>
@@ -278,24 +282,24 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The buffer <structfield> &v4l2-selection;::type </structfield>
or <structfield> &v4l2-selection;::target </structfield> is not supported, or
the <structfield> &v4l2-selection;::flags </structfield> are invalid.</para>
<para>Given buffer type <structfield>type</structfield> or
the selection target <structfield>target</structfield> is not supported,
or the <structfield>flags</structfield> argument is not valid.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ERANGE</errorcode></term>
<listitem>
<para>it is not possible to adjust a rectangle <structfield>
&v4l2-selection;::r </structfield> that satisfies all contraints from
<structfield> &v4l2-selection;::flags </structfield>.</para>
<para>It is not possible to adjust &v4l2-rect; <structfield>
r</structfield> rectangle to satisfy all contraints given in the
<structfield>flags</structfield> argument.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>it is not possible to apply change of selection rectangle at the moment.
Usually because streaming is in progress.</para>
<para>It is not possible to apply change of the selection rectangle
at the moment. Usually because streaming is in progress.</para>
</listitem>
</varlistentry>
</variablelist>

36
Documentation/DocBook/media/v4l/vidioc-querycap.xml
View File

@@ -124,12 +124,35 @@ printf ("Version: %u.%u.%u\n",
<row>
<entry>__u32</entry>
<entry><structfield>capabilities</structfield></entry>
<entry>Device capabilities, see <xref
linkend="device-capabilities" />.</entry>
<entry>Available capabilities of the physical device as a whole, see <xref
linkend="device-capabilities" />. The same physical device can export
multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and /dev/radioZ).
The <structfield>capabilities</structfield> field should contain a union
of all capabilities available around the several V4L2 devices exported
to userspace.
For all those devices the <structfield>capabilities</structfield> field
returns the same set of capabilities. This allows applications to open
just one of the devices (typically the video device) and discover whether
video, vbi and/or radio are also supported.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[4]</entry>
<entry><structfield>device_caps</structfield></entry>
<entry>Device capabilities of the opened device, see <xref
linkend="device-capabilities" />. Should contain the available capabilities
of that specific device node. So, for example, <structfield>device_caps</structfield>
of a radio device will only contain radio related capabilities and
no video or vbi capabilities. This field is only set if the <structfield>capabilities</structfield>
field contains the <constant>V4L2_CAP_DEVICE_CAPS</constant> capability.
Only the <structfield>capabilities</structfield> field can have the
<constant>V4L2_CAP_DEVICE_CAPS</constant> capability, <structfield>device_caps</structfield>
will never set <constant>V4L2_CAP_DEVICE_CAPS</constant>.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[3]</entry>
<entry>Reserved for future extensions. Drivers must set
this array to zero.</entry>
</row>
@@ -276,6 +299,13 @@ linkend="async">asynchronous</link> I/O methods.</entry>
<entry>The device supports the <link
linkend="mmap">streaming</link> I/O method.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_DEVICE_CAPS</constant></entry>
<entry>0x80000000</entry>
<entry>The driver fills the <structfield>device_caps</structfield>
field. This capability can only appear in the <structfield>capabilities</structfield>
field and never in the <structfield>device_caps</structfield> field.</entry>
</row>
</tbody>
</tgroup>
</table>

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

@@ -96,8 +96,8 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[7]</entry>
<entry>Reserved for future extensions. Drivers and
applications must set the array to zero.</entry>
<entry>Reserved for future extensions. Applications
must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
@@ -112,7 +112,7 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>tuner</structfield> index is out of
bounds or the value in the <structfield>type</structfield> field is
bounds, the wrap_around value is not supported or the value in the <structfield>type</structfield> field is
wrong.</para>
</listitem>
</varlistentry>

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.

55
Documentation/acpi/apei/einj.txt
View File

@@ -47,20 +47,53 @@ directory apei/einj. The following files are provided.
- param1
This file is used to set the first error parameter value. Effect of
parameter depends on error_type specified. For memory error, this is
physical memory address. Only available if param_extension module
parameter is specified.
parameter depends on error_type specified.
- param2
This file is used to set the second error parameter value. Effect of
parameter depends on error_type specified. For memory error, this is
physical memory address mask. Only available if param_extension
module parameter is specified.
parameter depends on error_type specified.
BIOS versions based in the ACPI 4.0 specification have limited options
to control where the errors are injected. Your BIOS may support an
extension (enabled with the param_extension=1 module parameter, or
boot command line einj.param_extension=1). This allows the address
and mask for memory injections to be specified by the param1 and
param2 files in apei/einj.
BIOS versions using the ACPI 5.0 specification have more control over
the target of the injection. For processor related errors (type 0x1,
0x2 and 0x4) the APICID of the target should be provided using the
param1 file in apei/einj. For memory errors (type 0x8, 0x10 and 0x20)
the address is set using param1 with a mask in param2 (0x0 is equivalent
to all ones). For PCI express errors (type 0x40, 0x80 and 0x100) the
segment, bus, device and function are specified using param1:
31 24 23 16 15 11 10 8 7 0
+-------------------------------------------------+
| segment | bus | device | function | reserved |
+-------------------------------------------------+
An ACPI 5.0 BIOS may also allow vendor specific errors to be injected.
In this case a file named vendor will contain identifying information
from the BIOS that hopefully will allow an application wishing to use
the vendor specific extension to tell that they are running on a BIOS
that supports it. All vendor extensions have the 0x80000000 bit set in
error_type. A file vendor_flags controls the interpretation of param1
and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
documentation for details (and expect changes to this API if vendors
creativity in using this feature expands beyond our expectations).
Example:
# cd /sys/kernel/debug/apei/einj
# cat available_error_type # See which errors can be injected
0x00000002 Processor Uncorrectable non-fatal
0x00000008 Memory Correctable
0x00000010 Memory Uncorrectable non-fatal
# echo 0x12345000 > param1 # Set memory address for injection
# echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page
# echo 0x8 > error_type # Choose correctable memory error
# echo 1 > error_inject # Inject now
Injecting parameter support is a BIOS version specific extension, that
is, it only works on some BIOS version. If you want to use it, please
make sure your BIOS version has the proper support and specify
"param_extension=y" in module parameter.
For more information about EINJ, please refer to ACPI specification
version 4.0, section 17.5.
version 4.0, section 17.5 and ACPI 5.0, section 18.6.

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)

37
Documentation/cgroups/memory.txt
View File

@@ -44,8 +44,8 @@ Features:
- oom-killer disable knob and oom-notifier
- Root cgroup has no limit controls.
Kernel memory and Hugepages are not under control yet. We just manage
pages on LRU. To add more controls, we have to take care of performance.
Kernel memory support is work in progress, and the current version provides
basically functionality. (See Section 2.7)
Brief summary of control files.
@@ -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
@@ -72,6 +72,9 @@ Brief summary of control files.
memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
1. History
The memory controller has a long history. A request for comments for the memory
@@ -255,6 +258,27 @@ When oom event notifier is registered, event will be delivered.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
zone->lru_lock, it has no lock of its own.
2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
With the Kernel memory extension, the Memory Controller is able to limit
the amount of kernel memory used by the system. Kernel memory is fundamentally
different than user memory, since it can't be swapped out, which makes it
possible to DoS the system by consuming too much of this precious resource.
Kernel memory limits are not imposed for the root cgroup. Usage for the root
cgroup may or may not be accounted.
Currently no soft limit is implemented for kernel memory. It is future work
to trigger slab reclaim when those limits are reached.
2.7.1 Current Kernel Memory resources accounted
* sockets memory pressure: some sockets protocols have memory pressure
thresholds. The Memory Controller allows them to be controlled individually
per cgroup, instead of globally.
* tcp memory pressure: sockets memory pressure for the tcp protocol.
3. User Interface
0. Configuration
@@ -386,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.

53
Documentation/cgroups/net_prio.txt Normal file
View File

@@ -0,0 +1,53 @@
Network priority cgroup
-------------------------
The Network priority cgroup provides an interface to allow an administrator to
dynamically set the priority of network traffic generated by various
applications
Nominally, an application would set the priority of its traffic via the
SO_PRIORITY socket option. This however, is not always possible because:
1) The application may not have been coded to set this value
2) The priority of application traffic is often a site-specific administrative
decision rather than an application defined one.
This cgroup allows an administrator to assign a process to a group which defines
the priority of egress traffic on a given interface. Network priority groups can
be created by first mounting the cgroup filesystem.
# mount -t cgroup -onet_prio none /sys/fs/cgroup/net_prio
With the above step, the initial group acting as the parent accounting group
becomes visible at '/sys/fs/cgroup/net_prio'. This group includes all tasks in
the system. '/sys/fs/cgroup/net_prio/tasks' lists the tasks in this cgroup.
Each net_prio cgroup contains two files that are subsystem specific
net_prio.prioidx
This file is read-only, and is simply informative. It contains a unique integer
value that the kernel uses as an internal representation of this cgroup.
net_prio.ifpriomap
This file contains a map of the priorities assigned to traffic originating from
processes in this group and egressing the system on various interfaces. It
contains a list of tuples in the form <ifname priority>. Contents of this file
can be modified by echoing a string into the file using the same tuple format.
for example:
echo "eth0 5" > /sys/fs/cgroups/net_prio/iscsi/net_prio.ifpriomap
This command would force any traffic originating from processes belonging to the
iscsi net_prio cgroup and egressing on interface eth0 to have the priority of
said traffic set to the value 5. The parent accounting group also has a
writeable 'net_prio.ifpriomap' file that can be used to set a system default
priority.
Priorities are set immediately prior to queueing a frame to the device
queueing discipline (qdisc) so priorities will be assigned prior to the hardware
queue selection being made.
One usage for the net_prio cgroup is with mqprio qdisc allowing application
traffic to be steered to hardware/driver based traffic classes. These mappings
can then be managed by administrators or other networking protocols such as
DCBX.

10
Documentation/coccinelle.txt
View File

@@ -102,9 +102,15 @@ or
make coccicheck COCCI=<my_SP.cocci> MODE=report
Using Coccinelle on (modified) files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Controlling Which Files are Processed by Coccinelle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default the entire kernel source tree is checked.
To apply Coccinelle to a specific directory, M= can be used.
For example, to check drivers/net/wireless/ one may write:
make coccicheck M=drivers/net/wireless/
To apply Coccinelle on a file basis, instead of a directory basis, the
following command may be used:

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>;

14
Documentation/devicetree/bindings/dma/atmel-dma.txt Normal file
View File

@@ -0,0 +1,14 @@
* Atmel Direct Memory Access Controller (DMA)
Required properties:
- compatible: Should be "atmel,<chip>-dma"
- reg: Should contain DMA registers location and length
- interrupts: Should contain DMA interrupt
Examples:
dma@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21>;
};

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;
};

6
Documentation/devicetree/bindings/gpio/led.txt
View File

@@ -7,9 +7,9 @@ Each LED is represented as a sub-node of the gpio-leds device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
- gpios : Should specify the LED's GPIO, see "Specifying GPIO information
for devices" in Documentation/devicetree/booting-without-of.txt. Active
low LEDs should be indicated using flags in the GPIO specifier.
- gpios : Should specify the LED's GPIO, see "gpios property" in
Documentation/devicetree/gpio.txt. Active low LEDs should be
indicated using flags in the GPIO specifier.
- label : (optional) The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
- linux,default-trigger : (optional) This parameter, if present, is a

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>;
};

30
Documentation/devicetree/bindings/i2c/omap-i2c.txt Normal file
View File

@@ -0,0 +1,30 @@
I2C for OMAP platforms
Required properties :
- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
- #address-cells = <1>;
- #size-cells = <0>;
Recommended properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
the default 100 kHz frequency will be used.
Optional properties:
- Child nodes conforming to i2c bus binding
Note: Current implementation will fetch base address, irq and dma
from omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Examples :
i2c1: i2c@0 {
compatible = "ti,omap3-i2c";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
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;
};

78
Documentation/devicetree/bindings/mfd/mc13xxx.txt Normal file
View File

@@ -0,0 +1,78 @@
* Freescale MC13783/MC13892 Power Management Integrated Circuit (PMIC)
Required properties:
- compatible : Should be "fsl,mc13783" or "fsl,mc13892"
Optional properties:
- fsl,mc13xxx-uses-adc : Indicate the ADC is being used
- fsl,mc13xxx-uses-codec : Indicate the Audio Codec is being used
- fsl,mc13xxx-uses-rtc : Indicate the RTC is being used
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
Sub-nodes:
- regulators : Contain the regulator nodes. The MC13892 regulators are
bound using their names as listed below with their registers and bits
for enabling.
vcoincell : regulator VCOINCELL (register 13, bit 23)
sw1 : regulator SW1 (register 24, bit 0)
sw2 : regulator SW2 (register 25, bit 0)
sw3 : regulator SW3 (register 26, bit 0)
sw4 : regulator SW4 (register 27, bit 0)
swbst : regulator SWBST (register 29, bit 20)
vgen1 : regulator VGEN1 (register 32, bit 0)
viohi : regulator VIOHI (register 32, bit 3)
vdig : regulator VDIG (register 32, bit 9)
vgen2 : regulator VGEN2 (register 32, bit 12)
vpll : regulator VPLL (register 32, bit 15)
vusb2 : regulator VUSB2 (register 32, bit 18)
vgen3 : regulator VGEN3 (register 33, bit 0)
vcam : regulator VCAM (register 33, bit 6)
vvideo : regulator VVIDEO (register 33, bit 12)
vaudio : regulator VAUDIO (register 33, bit 15)
vsd : regulator VSD (register 33, bit 18)
gpo1 : regulator GPO1 (register 34, bit 6)
gpo2 : regulator GPO2 (register 34, bit 8)
gpo3 : regulator GPO3 (register 34, bit 10)
gpo4 : regulator GPO4 (register 34, bit 12)
pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
vusb : regulator VUSB (register 50, bit 3)
The bindings details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
Examples:
ecspi@70010000 { /* ECSPI1 */
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
<&gpio3 25 0>; /* GPIO4_25 */
status = "okay";
pmic: mc13892@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mc13892";
spi-max-frequency = <6000000>;
reg = <0>;
interrupt-parent = <&gpio0>;
interrupts = <8>;
regulators {
sw1_reg: mc13892__sw1 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1375000>;
regulator-boot-on;
regulator-always-on;
};
sw2_reg: mc13892__sw2 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1850000>;
regulator-boot-on;
regulator-always-on;
};
};
};
};

47
Documentation/devicetree/bindings/mfd/twl-familly.txt Normal file
View File

@@ -0,0 +1,47 @@
Texas Instruments TWL family
The TWLs are Integrated Power Management Chips.
Some version might contain much more analog function like
USB transceiver or Audio amplifier.
These chips are connected to an i2c bus.
Required properties:
- compatible : Must be "ti,twl4030";
For Integrated power-management/audio CODEC device used in OMAP3
based boards
- compatible : Must be "ti,twl6030";
For Integrated power-management used in OMAP4 based boards
- interrupts : This i2c device has an IRQ line connected to the main SoC
- interrupt-controller : Since the twl support several interrupts internally,
it is considered as an interrupt controller cascaded to the SoC one.
- #interrupt-cells = <1>;
- interrupt-parent : The parent interrupt controller.
Optional node:
- Child nodes contain in the twl. The twl family is made of several variants
that support a different number of features.
The children nodes will thus depend of the capability of the variant.
Example:
/*
* Integrated Power Management Chip
* http://www.ti.com/lit/ds/symlink/twl6030.pdf
*/
twl@48 {
compatible = "ti,twl6030";
reg = <0x48>;
interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
twl_rtc {
compatible = "ti,twl_rtc";
interrupts = <11>;
reg = <0>;
};
};

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 {
...
};
};

15
Documentation/devicetree/bindings/net/calxeda-xgmac.txt Normal file
View File

@@ -0,0 +1,15 @@
* Calxeda Highbank 10Gb XGMAC Ethernet
Required properties:
- compatible : Should be "calxeda,hb-xgmac"
- reg : Address and length of the register set for the device
- interrupts : Should contain 3 xgmac interrupts. The 1st is main interrupt.
The 2nd is pwr mgt interrupt. The 3rd is low power state interrupt.
Example:
ethernet@fff50000 {
compatible = "calxeda,hb-xgmac";
reg = <0xfff50000 0x1000>;
interrupts = <0 77 4 0 78 4 0 79 4>;
};

53
Documentation/devicetree/bindings/net/can/cc770.txt Normal file
View File

@@ -0,0 +1,53 @@
Memory mapped Bosch CC770 and Intel AN82527 CAN controller
Note: The CC770 is a CAN controller from Bosch, which is 100%
compatible with the old AN82527 from Intel, but with "bugs" being fixed.
Required properties:
- compatible : should be "bosch,cc770" for the CC770 and "intc,82527"
for the AN82527.
- reg : should specify the chip select, address offset and size required
to map the registers of the controller. The size is usually 0x80.
- interrupts : property with a value describing the interrupt source
(number and sensitivity) required for the controller.
Optional properties:
- bosch,external-clock-frequency : frequency of the external oscillator
clock in Hz. Note that the internal clock frequency used by the
controller is half of that value. If not specified, a default
value of 16000000 (16 MHz) is used.
- bosch,clock-out-frequency : slock frequency in Hz on the CLKOUT pin.
If not specified or if the specified value is 0, the CLKOUT pin
will be disabled.
- bosch,slew-rate : slew rate of the CLKOUT signal. If not specified,
a resonable value will be calculated.
- bosch,disconnect-rx0-input : see data sheet.
- bosch,disconnect-rx1-input : see data sheet.
- bosch,disconnect-tx1-output : see data sheet.
- bosch,polarity-dominant : see data sheet.
- bosch,divide-memory-clock : see data sheet.
- bosch,iso-low-speed-mux : see data sheet.
For further information, please have a look to the CC770 or AN82527.
Examples:
can@3,100 {
compatible = "bosch,cc770";
reg = <3 0x100 0x80>;
interrupts = <2 0>;
interrupt-parent = <&mpic>;
bosch,external-clock-frequency = <16000000>;
};

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>;
};

54
Documentation/devicetree/bindings/resource-names.txt Normal file
View File

@@ -0,0 +1,54 @@
Some properties contain an ordered list of 1 or more datum which are
normally accessed by index. However, some devices will have multiple
values which are more naturally accessed by name. Device nodes can
include a supplemental property for assigning names to each of the list
items. The names property consists of a list of strings in the same
order as the data in the resource property.
The following supplemental names properties are defined.
Resource Property Supplemental Names Property
----------------- ---------------------------
reg reg-names
clocks clock-names
interrupts interrupt-names
Usage:
The -names property must be used in conjunction with the normal resource
property. If not it will be ignored.
Examples:
l4-abe {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x48000000 0x00001000>, /* MPU path */
<1 0 0x49000000 0x00001000>; /* L3 path */
mcasp {
compatible = "ti,mcasp";
reg = <0 0x10 0x10>, <0 0x20 0x10>,
<1 0x10 0x10>, <1 0x20 0x10>;
reg-names = "mpu", "dat",
"dma", "dma_dat";
interrupts = <11>, <12>;
interrupt-names = "rx", "tx";
};
timer {
compatible = "ti,timer";
reg = <0 0x40 0x10>, <1 0x40 0x10>;
reg-names = "mpu", "dma";
};
};
usb {
compatible = "ti,usb-host";
reg = <0x4a064000 0x800>, <0x4a064800 0x200>,
<0x4a064c00 0x200>;
reg-names = "config", "ohci", "ehci";
interrupts = <14>, <15>;
interrupt-names = "ohci", "ehci";
};

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.

6
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.
@@ -28,14 +30,18 @@ national National Semiconductor
nintendo Nintendo
nvidia NVIDIA
nxp NXP Semiconductors
picochip Picochip Ltd
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

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

@@ -0,0 +1,228 @@
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.
Miscellaneous notes:
- Any exporters or users of the dma-buf buffer sharing framework must have
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
References:
[1] struct dma_buf_ops in include/linux/dma-buf.h
[2] All interfaces mentioned above defined in include/linux/dma-buf.h

8
Documentation/dmaengine.txt
View File

@@ -75,6 +75,10 @@ The slave DMA usage consists of following steps:
slave_sg - DMA a list of scatter gather buffers from/to a peripheral
dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the
operation is explicitly stopped.
interleaved_dma - This is common to Slave as well as M2M clients. For slave
address of devices' fifo could be already known to the driver.
Various types of operations could be expressed by setting
appropriate values to the 'dma_interleaved_template' members.
A non-NULL return of this transfer API represents a "descriptor" for
the given transaction.
@@ -89,6 +93,10 @@ The slave DMA usage consists of following steps:
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_data_direction direction);
struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
struct dma_chan *chan, struct dma_interleaved_template *xt,
unsigned long flags);
The peripheral driver is expected to have mapped the scatterlist for
the DMA operation prior to calling device_prep_slave_sg, and must
keep the scatterlist mapped until the DMA operation has completed.

1
Documentation/dontdiff
View File

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

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

@@ -233,6 +233,10 @@ certainly invest a bit more effort into libata core layer).
6. List of managed interfaces
-----------------------------
MEM
devm_kzalloc()
devm_kfree()
IO region
devm_request_region()
devm_request_mem_region()
@@ -262,6 +266,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

1
Documentation/dvb/cards.txt
View File

@@ -119,4 +119,5 @@ o Cards based on the Phillips saa7134 PCI bridge:
- Compro Videomate DVB-T300
- Compro Videomate DVB-T200
- AVerMedia AVerTVHD MCE A180
- KWorld PC150-U ATSC Hybrid

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