OpenE2K
/
linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge branch 'sh/dmaengine' into sh-latest

This commit is contained in:
Paul Mundt 2012-08-01 13:49:13 +09:00
parent b9ccfda293 4dc4c51675
commit 91ba548cfd
3266 changed files with 269648 additions and 85497 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads Normal file
View File

@ -0,0 +1,5 @@
What: /proc/sys/vm/nr_pdflush_threads
Date: June 2012
Contact: Wanpeng Li <liwp@linux.vnet.ibm.com>
Description: Since pdflush is replaced by per-BDI flusher, the interface of old pdflush
exported in /proc/sys/vm/ should be removed.

11
Documentation/ABI/stable/sysfs-bus-firewire
View File

@ -39,6 +39,17 @@ Users: udev rules to set ownership and access permissions or ACLs of
/dev/fw[0-9]+ character device files
What: /sys/bus/firewire/devices/fw[0-9]+/is_local
Date: July 2012
KernelVersion: 3.6
Contact: linux1394-devel@lists.sourceforge.net
Description:
IEEE 1394 node device attribute.
Read-only and immutable.
Values: 1: The sysfs entry represents a local node (a controller card).
0: The sysfs entry represents a remote node.
What: /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/
Date: May 2007
KernelVersion: 2.6.22

15
Documentation/ABI/stable/sysfs-driver-w1_ds28e04 Normal file
View File

@ -0,0 +1,15 @@
What: /sys/bus/w1/devices/.../pio
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the two PIO's of the DS28E04-100
see Documentation/w1/slaves/w1_ds28e04 for detailed information
Users: any user space application which wants to communicate with DS28E04-100
What: /sys/bus/w1/devices/.../eeprom
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the EEPROM memory of the DS28E04-100
see Documentation/w1/slaves/w1_ds28e04 for detailed information
Users: any user space application which wants to communicate with DS28E04-100

29
Documentation/ABI/testing/dev-kmsg
View File

@ -58,16 +58,18 @@ Description: The /dev/kmsg character device node provides userspace access
The output format consists of a prefix carrying the syslog
prefix including priority and facility, the 64 bit message
sequence number and the monotonic timestamp in microseconds.
The values are separated by a ','. Future extensions might
add more comma separated values before the terminating ';'.
Unknown values should be gracefully ignored.
sequence number and the monotonic timestamp in microseconds,
and a flag field. All fields are separated by a ','.
Future extensions might add more comma separated values before
the terminating ';'. Unknown fields and values should be
gracefully ignored.
The human readable text string starts directly after the ';'
and is terminated by a '\n'. Untrusted values derived from
hardware or other facilities are printed, therefore
all non-printable characters in the log message are escaped
by "\x00" C-style hex encoding.
all non-printable characters and '\' itself in the log message
are escaped by "\x00" C-style hex encoding.
A line starting with ' ', is a continuation line, adding
key/value pairs to the log message, which provide the machine
@ -75,11 +77,11 @@ Description: The /dev/kmsg character device node provides userspace access
userspace.
Example:
7,160,424069;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored)
7,160,424069,-;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored)
SUBSYSTEM=acpi
DEVICE=+acpi:PNP0A03:00
6,339,5140900;NET: Registered protocol family 10
30,340,5690716;udevd[80]: starting version 181
6,339,5140900,-;NET: Registered protocol family 10
30,340,5690716,-;udevd[80]: starting version 181
The DEVICE= key uniquely identifies devices the following way:
b12:8 - block dev_t
@ -87,4 +89,13 @@ Description: The /dev/kmsg character device node provides userspace access
n8 - netdev ifindex
+sound:card0 - subsystem:devname
The flags field carries '-' by default. A 'c' indicates a
fragment of a line. All following fragments are flagged with
'+'. Note, that these hints about continuation lines are not
neccessarily correct, and the stream could be interleaved with
unrelated messages, but merging the lines in the output
usually produces better human readable results. A similar
logic is used internally when messages are printed to the
console, /proc/kmsg or the syslog() syscall.
Users: dmesg(1), userspace kernel log consumers

54
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -40,9 +40,9 @@ Contact: linux-iio@vger.kernel.org
Description:
Some devices have internal clocks. This parameter sets the
resulting sampling frequency. In many devices this
parameter has an effect on input filters etc rather than
parameter has an effect on input filters etc. rather than
simply controlling when the input is sampled. As this
effects datardy triggers, hardware buffers and the sysfs
effects data ready triggers, hardware buffers and the sysfs
direct access interfaces, it may be found in any of the
relevant directories. If it effects all of the above
then it is to be found in the base device directory.
@ -74,7 +74,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no bias removal etc) voltage measurement from
Raw (unscaled no bias removal etc.) voltage measurement from
channel Y. In special cases where the channel does not
correspond to externally available input one of the named
versions may be used. The number must always be specified and
@ -118,11 +118,11 @@ What: /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no bias removal etc) temperature measurement.
Raw (unscaled no bias removal etc.) temperature measurement.
If an axis is specified it generally means that the temperature
sensor is associated with one part of a compound device (e.g.
a gyroscope axis). Units after application of scale and offset
are milli degrees Celsuis.
are milli degrees Celsius.
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input
KernelVersion: 2.6.38
@ -148,10 +148,9 @@ KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Angular velocity about axis x, y or z (may be arbitrarily
assigned) Data converted by application of offset then scale to
radians per second. Has all the equivalent parameters as
per voltageY. Units after application of scale and offset are
radians per second.
assigned). Has all the equivalent parameters as per voltageY.
Units after application of scale and offset are radians per
second.
What: /sys/bus/iio/devices/iio:deviceX/in_incli_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_incli_y_raw
@ -161,7 +160,7 @@ Contact: linux-iio@vger.kernel.org
Description:
Inclination raw reading about axis x, y or z (may be
arbitrarily assigned). Data converted by application of offset
and scale to Degrees.
and scale to degrees.
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw
@ -203,7 +202,7 @@ Contact: linux-iio@vger.kernel.org
Description:
If known for a device, offset to be added to <type>[Y]_raw prior
to scaling by <type>[Y]_scale in order to obtain value in the
<type> units as specified in <type>[y]_raw documentation.
<type> units as specified in <type>[Y]_raw documentation.
Not present if the offset is always 0 or unknown. If Y or
axis <x|y|z> is not present, then the offset applies to all
in channels of <type>.
@ -249,7 +248,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Hardware applied calibration offset. (assumed to fix production
Hardware applied calibration offset (assumed to fix production
inaccuracies).
What /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
@ -266,7 +265,7 @@ what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Hardware applied calibration scale factor. (assumed to fix
Hardware applied calibration scale factor (assumed to fix
production inaccuracies). If shared across all channels,
<type>_calibscale is used.
@ -276,10 +275,10 @@ What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
What: /sys/.../iio:deviceX/out_voltageX_scale_available
What: /sys/.../iio:deviceX/out_altvoltageX_scale_available
What: /sys/.../iio:deviceX/in_capacitance_scale_available
KernelVersion: 2.635
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
If a discrete set of scale values are available, they
If a discrete set of scale values is available, they
are listed in this attribute.
What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
@ -330,9 +329,11 @@ Contact: linux-iio@vger.kernel.org
Description:
Specifies the output powerdown mode.
DAC output stage is disconnected from the amplifier and
1kohm_to_gnd: connected to ground via an 1kOhm resistor
100kohm_to_gnd: connected to ground via an 100kOhm resistor
three_state: left floating
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
three_state: left floating.
For a list of available output power down options read
outX_powerdown_mode_available. If Y is not present the
mode is shared across all outputs.
@ -355,9 +356,10 @@ KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
Writing 1 causes output Y to enter the power down mode specified
by the corresponding outY_powerdown_mode. Clearing returns to
normal operation. Y may be suppressed if all outputs are
controlled together.
by the corresponding outY_powerdown_mode. DAC output stage is
disconnected from the amplifier. Clearing returns to normal
operation. Y may be suppressed if all outputs are controlled
together.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
KernelVersion: 3.4.0
@ -421,12 +423,12 @@ Description:
different values, but the device can only enable both thresholds
or neither.
Note the driver will assume the last p events requested are
to be enabled where p is however many it supports (which may
vary depending on the exact set requested. So if you want to be
to be enabled where p is how many it supports (which may vary
depending on the exact set requested. So if you want to be
sure you have set what you think you have, check the contents of
these attributes after everything is configured. Drivers may
have to buffer any parameters so that they are consistent when
a given event type is enabled a future point (and not those for
a given event type is enabled at a future point (and not those for
whatever event was previously enabled).
What: /sys/.../iio:deviceX/events/in_accel_x_roc_rising_en
@ -702,7 +704,7 @@ What: /sys/.../buffer/scan_elements/in_anglvel_type
What: /sys/.../buffer/scan_elements/in_magn_type
What: /sys/.../buffer/scan_elements/in_incli_type
What: /sys/.../buffer/scan_elements/in_voltageY_type
What: /sys/.../buffer/scan_elements/in_voltage-in_type
What: /sys/.../buffer/scan_elements/in_voltage_type
What: /sys/.../buffer/scan_elements/in_voltageY_supply_type
What: /sys/.../buffer/scan_elements/in_timestamp_type
KernelVersion: 2.6.37
@ -723,7 +725,7 @@ Description:
the buffer output value appropriately. The storagebits value
also specifies the data alignment. So s48/64>>2 will be a
signed 48 bit integer stored in a 64 bit location aligned to
a a64 bit boundary. To obtain the clean value, shift right 2
a 64 bit boundary. To obtain the clean value, shift right 2
and apply a mask to zero the top 16 bits of the result.
For other storage combinations this attribute will be extended
appropriately.

37
Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 Normal file
View File

@ -0,0 +1,37 @@
What: /sys/bus/iio/devices/iio:deviceX/pll2_feedback_clk_present
What: /sys/bus/iio/devices/iio:deviceX/pll2_reference_clk_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_a_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_b_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_test_present
What: /sys/bus/iio/devices/iio:deviceX/vcxo_clk_present
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'.
'1' means that the clock in question is present.
'0' means that the clock is missing.
What: /sys/bus/iio/devices/iio:deviceX/pllY_locked
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'. '1' means that the
pllY is locked.
What: /sys/bus/iio/devices/iio:deviceX/store_eeprom
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Writing '1' stores the current device configuration into
on-chip EEPROM. After power-up or chip reset the device will
automatically load the saved configuration.
What: /sys/bus/iio/devices/iio:deviceX/sync_dividers
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Writing '1' triggers the clock distribution synchronization
functionality. All dividers are reset and the channels start
with their predefined phase offsets (out_altvoltageY_phase).
Writing this file has the effect as driving the external
/SYNC pin low.

21
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 Normal file
View File

@ -0,0 +1,21 @@
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_resolution
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Stores channel Y frequency resolution/channel spacing in Hz.
The value given directly influences the MODULUS used by
the fractional-N PLL. It is assumed that the algorithm
that is used to compute the various dividers, is able to
generate proper values for multiples of channel spacing.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_refin_frequency
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Sets channel Y REFin frequency in Hz. In some clock chained
applications, the reference frequency used by the PLL may
change during runtime. This attribute allows the user to
adjust the reference frequency accordingly.
The value written has no effect until out_altvoltageY_frequency
is updated. Consider to use out_altvoltageY_powerdown to power
down the PLL and it's RFOut buffers during REFin changes.

61
Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als Normal file
View File

@ -0,0 +1,61 @@
What: /sys/.../events/in_illuminance0_thresh_either_en
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Event generated when channel passes one of the four thresholds
in each direction (rising|falling) and a zone change occurs.
The corresponding light zone can be read from
in_illuminance0_zone.
What: /sys/.../events/in_illuminance0_threshY_hysteresis
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the hysteresis for thresholds Y, that is,
threshY_hysteresis = threshY_raising - threshY_falling
What: /sys/.../events/illuminance_threshY_falling_value
What: /sys/.../events/illuminance_threshY_raising_value
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Specifies the value of threshold that the device is comparing
against for the events enabled by
in_illuminance0_thresh_either_en (0..255), where Y in 0..3.
Note that threshY_falling must be less than or equal to
threshY_raising.
These thresholds correspond to the eight zone-boundary
registers (boundaryY_{low,high}) and define the five light
zones.
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_zone
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the current light zone (0..4) as defined by the
in_illuminance0_threshY_{falling,rising} thresholds.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get output current for channel Y (0..255), that is,
out_currentY_currentZ_raw, where Z is the current zone.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_currentZ_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the output current for channel out_currentY when in zone
Z (0..255), where Y in 0..2 and Z in 0..4.
These values correspond to the ALS-mapper target registers for
ALS-mapper Y + 1.

10
Documentation/ABI/testing/sysfs-bus-rbd
View File

@ -35,8 +35,14 @@ name
pool
The pool where this rbd image resides. The pool-name pair is unique
per rados system.
The name of the storage pool where this rbd image resides.
An rbd image name is unique within its pool.
pool_id
The unique identifier for the rbd image's pool. This is
a permanent attribute of the pool. A pool's id will never
change.
size

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

@ -208,3 +208,15 @@ Description:
such as ACPI. This file will read either "removable" or
"fixed" if the information is available, and "unknown"
otherwise.
What: /sys/bus/usb/devices/.../ltm_capable
Date: July 2012
Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Description:
USB 3.0 devices may optionally support Latency Tolerance
Messaging (LTM). They indicate their support by setting a bit
in the bmAttributes field of their SuperSpeed BOS descriptors.
If that bit is set for the device, ltm_capable will read "yes".
If the device doesn't support LTM, the file will read "no".
The file will be present for all speeds of USB devices, and will
always read "no" for USB 1.1 and USB 2.0 devices.

140
Documentation/ABI/testing/sysfs-devices-edac Normal file
View File

@ -0,0 +1,140 @@
What: /sys/devices/system/edac/mc/mc*/reset_counters
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This write-only control file will zero all the statistical
counters for UE and CE errors on the given memory controller.
Zeroing the counters will also reset the timer indicating how
long since the last counter were reset. This is useful for
computing errors/time. Since the counters are always reset
at driver initialization time, no module/kernel parameter
is available.
What: /sys/devices/system/edac/mc/mc*/seconds_since_reset
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays how many seconds have elapsed
since the last counter reset. This can be used with the error
counters to measure error rates.
What: /sys/devices/system/edac/mc/mc*/mc_name
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the type of memory controller
that is being utilized.
What: /sys/devices/system/edac/mc/mc*/size_mb
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays, in count of megabytes, of memory
that this memory controller manages.
What: /sys/devices/system/edac/mc/mc*/ue_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the total count of uncorrectable
errors that have occurred on this memory controller. If
panic_on_ue is set, this counter will not have a chance to
increment, since EDAC will panic the system
What: /sys/devices/system/edac/mc/mc*/ue_noinfo_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the number of UEs that have
occurred on this memory controller with no information as to
which DIMM slot is having errors.
What: /sys/devices/system/edac/mc/mc*/ce_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the total count of correctable
errors that have occurred on this memory controller. This
count is very important to examine. CEs provide early
indications that a DIMM is beginning to fail. This count
field should be monitored for non-zero values and report
such information to the system administrator.
What: /sys/devices/system/edac/mc/mc*/ce_noinfo_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the number of CEs that
have occurred on this memory controller wherewith no
information as to which DIMM slot is having errors. Memory is
handicapped, but operational, yet no information is available
to indicate which slot the failing memory is in. This count
field should be also be monitored for non-zero values.
What: /sys/devices/system/edac/mc/mc*/sdram_scrub_rate
Date: February 2007
Contact: linux-edac@vger.kernel.org
Description: Read/Write attribute file that controls memory scrubbing.
The scrubbing rate used by the memory controller is set by
writing a minimum bandwidth in bytes/sec to the attribute file.
The rate will be translated to an internal value that gives at
least the specified rate.
Reading the file will return the actual scrubbing rate employed.
If configuration fails or memory scrubbing is not implemented,
the value of the attribute file will be -1.
What: /sys/devices/system/edac/mc/mc*/max_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file displays the information about the last
available memory slot in this memory controller. It is used by
userspace tools in order to display the memory filling layout.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the size of dimm or rank.
For dimm*/size, this is the size, in MB of the DIMM memory
stick. For rank*/size, this is the size, in MB for one rank
of the DIMM memory stick. On single rank memories (1R), this
is also the total size of the dimm. On dual rank (2R) memories,
this is half the size of the total DIMM memories.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of DRAM device is
being utilized on this DIMM (x1, x2, x4, x8, ...).
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of Error detection
and correction is being utilized. For example: S4ECD4ED would
mean a Chipkill with x4 DRAM.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This control file allows this DIMM to have a label assigned
to it. With this label in the module, when errors occur
the output can provide the DIMM label in the system log.
This becomes vital for panic events to isolate the
cause of the UE event.
DIMM Labels must be assigned after booting, with information
that correctly identifies the physical slot with its
silk screen label. This information is currently very
motherboard specific and determination of this information
must occur in userland at this time.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the location (csrow/channel,
branch/channel/slot or channel/slot) of the dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of memory is
currently on this csrow. Normally, either buffered or
unbuffered memory (for example, Unbuffered-DDR3).

7
Documentation/ABI/testing/sysfs-platform-asus-wmi
View File

@ -29,3 +29,10 @@ KernelVersion: 2.6.39
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Control the card touchpad. 1 means on, 0 means off.
What: /sys/devices/platform/<platform>/lid_resume
Date: May 2012
KernelVersion: 3.5
Contact: "AceLan Kao" <acelan.kao@canonical.com>
Description:
Resume on lid open. 1 means on, 0 means off.

42
Documentation/DMA-attributes.txt
View File

@ -49,3 +49,45 @@ DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
consistent or non-consistent memory as it sees fit. By using this API,
you are guaranteeing to the platform that you have all the correct and
necessary sync points for this memory in the driver.
DMA_ATTR_NO_KERNEL_MAPPING
--------------------------
DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel
virtual mapping for the allocated buffer. On some architectures creating
such mapping is non-trivial task and consumes very limited resources
(like kernel virtual address space or dma consistent address space).
Buffers allocated with this attribute can be only passed to user space
by calling dma_mmap_attrs(). By using this API, you are guaranteeing
that you won't dereference the pointer returned by dma_alloc_attr(). You
can threat it as a cookie that must be passed to dma_mmap_attrs() and
dma_free_attrs(). Make sure that both of these also get this attribute
set on each call.
Since it is optional for platforms to implement
DMA_ATTR_NO_KERNEL_MAPPING, those that do not will simply ignore the
attribute and exhibit default behavior.
DMA_ATTR_SKIP_CPU_SYNC
----------------------
By default dma_map_{single,page,sg} functions family transfer a given
buffer from CPU domain to device domain. Some advanced use cases might
require sharing a buffer between more than one device. This requires
having a mapping created separately for each device and is usually
performed by calling dma_map_{single,page,sg} function more than once
for the given buffer with device pointer to each device taking part in
the buffer sharing. The first call transfers a buffer from 'CPU' domain
to 'device' domain, what synchronizes CPU caches for the given region
(usually it means that the cache has been flushed or invalidated
depending on the dma direction). However, next calls to
dma_map_{single,page,sg}() for other devices will perform exactly the
same sychronization operation on the CPU cache. CPU cache sychronization
might be a time consuming operation, especially if the buffers are
large, so it is highly recommended to avoid it if possible.
DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
the CPU cache for the given buffer assuming that it has been already
transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!

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

@ -194,7 +194,7 @@ in the frequency range from 87,5 to 108,0 MHz</title>
<corpauthor>National Radio Systems Committee
(<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor>
</authorgroup>
<title>NTSC-4: United States RBDS Standard</title>
<title>NRSC-4: United States RBDS Standard</title>
</biblioentry>
<biblioentry id="iso12232">

17
Documentation/DocBook/media/v4l/common.xml
View File

@ -464,14 +464,14 @@ The <structfield>type</structfield> field of the respective
<structfield>tuner</structfield> field contains the index number of
the tuner.</para>
<para>Radio devices have exactly one tuner with index zero, no
<para>Radio input devices have exactly one tuner with index zero, no
video inputs.</para>
<para>To query and change tuner properties applications use the
&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The
&v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also
contains signal status information applicable when the tuner of the
current video input, or a radio tuner is queried. Note that
current video or radio input is queried. Note that
<constant>VIDIOC_S_TUNER</constant> does not switch the current tuner,
when there is more than one at all. The tuner is solely determined by
the current video input. Drivers must support both ioctls and set the
@ -491,8 +491,17 @@ the modulator. The <structfield>type</structfield> field of the
respective &v4l2-output; returned by the &VIDIOC-ENUMOUTPUT; ioctl is
set to <constant>V4L2_OUTPUT_TYPE_MODULATOR</constant> and its
<structfield>modulator</structfield> field contains the index number
of the modulator. This specification does not define radio output
devices.</para>
of the modulator.</para>
<para>Radio output devices have exactly one modulator with index
zero, no video outputs.</para>
<para>A video or radio device cannot support both a tuner and a
modulator. Two separate device nodes will have to be used for such
hardware, one that supports the tuner functionality and one that supports
the modulator functionality. The reason is a limitation with the
&VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency
is for a tuner or a modulator.</para>
<para>To query and change modulator properties applications use
the &VIDIOC-G-MODULATOR; and &VIDIOC-S-MODULATOR; ioctl. Note that

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

@ -2377,10 +2377,11 @@ that used it. It was originally scheduled for removal in 2.6.35.
<para>V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace.</para>
</listitem>
<listitem>
<para>Add selection API for extended control over cropping and
composing. Does not affect the compatibility of current drivers and
applications. See <link linkend="selection-api"> selection API </link> for
details.</para>
<para>Add selection API for extended control over cropping
and composing. Does not affect the compatibility of current
drivers and applications. See <link
linkend="selection-api"> selection API </link> for
details.</para>
</listitem>
</orderedlist>
</section>
@ -2458,6 +2459,36 @@ details.</para>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Replaced <structfield>input</structfield> in
<structname>v4l2_buffer</structname> by
<structfield>reserved2</structfield> and removed
<constant>V4L2_BUF_FLAG_INPUT</constant>.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@ -2587,6 +2618,9 @@ ioctls.</para>
<para><link linkend="v4l2-auto-focus-area"><constant>
V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
</listitem>
<listitem>
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
</listitem>
</itemizedlist>
</section>

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

@ -372,6 +372,11 @@ minimum value disables backlight compensation.</entry>
Cr component, bits [15:8] as Cb component and bits [31:16] must be zero.
</entry>
</row>
<row>
<entry><constant>V4L2_CID_AUTOBRIGHTNESS</constant></entry>
<entry>boolean</entry>
<entry>Enable Automatic Brightness.</entry>
</row>
<row>
<entry><constant>V4L2_CID_ROTATE</constant></entry>
<entry>integer</entry>

36
Documentation/DocBook/media/v4l/dev-subdev.xml
View File

@ -276,7 +276,7 @@
</para>
</section>
<section>
<section id="v4l2-subdev-selections">
<title>Selections: cropping, scaling and composition</title>
<para>Many sub-devices support cropping frames on their input or output
@ -290,8 +290,8 @@
size. Both the coordinates and sizes are expressed in pixels.</para>
<para>As for pad formats, drivers store try and active
rectangles for the selection targets of ACTUAL type <xref
linkend="v4l2-subdev-selection-targets">.</xref></para>
rectangles for the selection targets <xref
linkend="v4l2-selections-common" />.</para>
<para>On sink pads, cropping is applied relative to the
current pad format. The pad format represents the image size as
@ -308,7 +308,7 @@
<para>Scaling support is optional. When supported by a subdev,
the crop rectangle on the subdev's sink pad is scaled to the
size configured using the &VIDIOC-SUBDEV-S-SELECTION; IOCTL
using <constant>V4L2_SUBDEV_SEL_COMPOSE_ACTUAL</constant>
using <constant>V4L2_SEL_TGT_COMPOSE</constant>
selection target on the same pad. If the subdev supports scaling
but not composing, the top and left values are not used and must
always be set to zero.</para>
@ -323,32 +323,32 @@
<para>The drivers should always use the closest possible
rectangle the user requests on all selection targets, unless
specifically told otherwise.
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant> and
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant> flags may be
<constant>V4L2_SEL_FLAG_GE</constant> and
<constant>V4L2_SEL_FLAG_LE</constant> flags may be
used to round the image size either up or down. <xref
linkend="v4l2-subdev-selection-flags"></xref></para>
linkend="v4l2-selection-flags" /></para>
</section>
<section>
<title>Types of selection targets</title>
<section>
<title>ACTUAL targets</title>
<title>Actual targets</title>
<para>ACTUAL targets reflect the actual hardware configuration
at any point of time. There is a BOUNDS target
corresponding to every ACTUAL.</para>
<para>Actual targets (without a postfix) reflect the actual
hardware configuration at any point of time. There is a BOUNDS
target corresponding to every actual target.</para>
</section>
<section>
<title>BOUNDS targets</title>
<para>BOUNDS targets is the smallest rectangle that contains
all valid ACTUAL rectangles. It may not be possible to set the
ACTUAL rectangle as large as the BOUNDS rectangle, however.
This may be because e.g. a sensor's pixel array is not
rectangular but cross-shaped or round. The maximum size may
also be smaller than the BOUNDS rectangle.</para>
<para>BOUNDS targets is the smallest rectangle that contains all
valid actual rectangles. It may not be possible to set the actual
rectangle as large as the BOUNDS rectangle, however. This may be
because e.g. a sensor's pixel array is not rectangular but
cross-shaped or round. The maximum size may also be smaller than the
BOUNDS rectangle.</para>
</section>
</section>
@ -362,7 +362,7 @@
performed by the user: the changes made will be propagated to
any subsequent stages. If this behaviour is not desired, the
user must set
<constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant> flag. This
<constant>V4L2_SEL_FLAG_KEEP_CONFIG</constant> flag. This
flag causes no propagation of the changes are allowed in any
circumstances. This may also cause the accessed rectangle to be
adjusted by the driver, depending on the properties of the

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

@ -683,14 +683,12 @@ memory, set by the application. See <xref linkend="userp" /> for details.
</row>
<row>
<entry>__u32</entry>
<entry><structfield>input</structfield></entry>
<entry><structfield>reserved2</structfield></entry>
<entry></entry>
<entry>Some video capture drivers support rapid and
synchronous video input changes, a function useful for example in
video surveillance applications. For this purpose applications set the
<constant>V4L2_BUF_FLAG_INPUT</constant> flag, and this field to the
number of a video input as in &v4l2-input; field
<structfield>index</structfield>.</entry>
<entry>A place holder for future extensions and custom
(driver defined) buffer types
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
should set this to 0.</entry>
</row>
<row>
<entry>__u32</entry>
@ -921,13 +919,6 @@ previous key frame.</entry>
<entry>The <structfield>timecode</structfield> field is valid.
Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant>
ioctl is called.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_INPUT</constant></entry>
<entry>0x0200</entry>
<entry>The <structfield>input</structfield> field is valid.
Applications set or clear this flag before calling the
<constant>VIDIOC_QBUF</constant> ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>

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

@ -53,11 +53,11 @@ cropping and composing rectangles have the same size.</para>
</mediaobject>
</figure>
For complete list of the available selection targets see table <xref
linkend="v4l2-sel-target"/>
</section>
See <xref linkend="v4l2-selection-targets" /> for more
information.
<section>
<title>Configuration</title>
@ -74,7 +74,7 @@ cropping/composing rectangles may have to be aligned, and both the source and
the sink may have arbitrary upper and lower size limits. Therefore, as usual,
drivers are expected to adjust the requested parameters and return the actual
values selected. An application can control the rounding behaviour using <link
linkend="v4l2-sel-flags"> constraint flags </link>.</para>
linkend="v4l2-selection-flags"> constraint flags </link>.</para>
<section>
@ -91,7 +91,7 @@ top/left corner at position <constant> (0,0) </constant>. The rectangle's
coordinates are expressed in pixels.</para>
<para>The top left corner, width and height of the source rectangle, that is
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP_ACTIVE
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP
</constant> target. It uses the same coordinate system as <constant>
V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie
completely inside the capture boundaries. The driver may further adjust the
@ -111,13 +111,13 @@ height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>.
</para>
<para>The part of a buffer into which the image is inserted by the hardware is
controlled by the <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.
controlled by the <constant> V4L2_SEL_TGT_COMPOSE </constant> target.
The rectangle's coordinates are also expressed in the same coordinate system as
the bounds rectangle. The composing rectangle must lie completely inside bounds
rectangle. The driver must adjust the composing rectangle to fit to the
bounding limits. Moreover, the driver can perform other adjustments according
to hardware limitations. The application can control rounding behaviour using
<link linkend="v4l2-sel-flags"> constraint flags </link>.</para>
<link linkend="v4l2-selection-flags"> constraint flags </link>.</para>
<para>For capture devices the default composing rectangle is queried using
<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the
@ -125,7 +125,7 @@ bounding rectangle.</para>
<para>The part of a buffer that is modified by the hardware is given by
<constant> V4L2_SEL_TGT_COMPOSE_PADDED </constant>. It contains all pixels
defined using <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> plus all
defined using <constant> V4L2_SEL_TGT_COMPOSE </constant> plus all
padding data modified by hardware during insertion process. All pixels outside
this rectangle <emphasis>must not</emphasis> be changed by the hardware. The
content of pixels that lie inside the padded area but outside active area is
@ -153,7 +153,7 @@ specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para>
<para>The top left corner, width and height of the source rectangle, that is
the area from which image date are processed by the hardware, is given by the
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant>. Its coordinates are expressed
<constant> V4L2_SEL_TGT_CROP </constant>. Its coordinates are expressed
in in the same coordinate system as the bounds rectangle. The active cropping
area must lie completely inside the crop boundaries and the driver may further
adjust the requested size and/or position according to hardware
@ -165,7 +165,7 @@ bounding rectangle.</para>
<para>The part of a video signal or graphics display where the image is
inserted by the hardware is controlled by <constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target. The rectangle's coordinates
V4L2_SEL_TGT_COMPOSE </constant> target. The rectangle's coordinates
are expressed in pixels. The composing rectangle must lie completely inside the
bounds rectangle. The driver must adjust the area to fit to the bounding
limits. Moreover, the driver can perform other adjustments according to
@ -184,7 +184,7 @@ such a padded area is driver-dependent feature not covered by this document.
Driver developers are encouraged to keep padded rectangle equal to active one.
The padded target is accessed by the <constant> V4L2_SEL_TGT_COMPOSE_PADDED
</constant> identifier. It must contain all pixels from the <constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
V4L2_SEL_TGT_COMPOSE </constant> target.</para>
</section>
@ -193,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
<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
</constant> and <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> targets. If
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP
</constant> and <constant> V4L2_SEL_TGT_COMPOSE </constant> targets. If
these are not equal then the scaling is applied. The application can compute
the scaling ratios using these values.</para>
@ -252,7 +252,7 @@ area)</para>
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &amp;sel);
if (ret)
exit(-1);
sel.target = V4L2_SEL_TGT_CROP_ACTIVE;
sel.target = V4L2_SEL_TGT_CROP;
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &amp;sel);
if (ret)
exit(-1);
@ -281,7 +281,7 @@ area)</para>
r.left = sel.r.width / 4;
r.top = sel.r.height / 4;
sel.r = r;
sel.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
sel.target = V4L2_SEL_TGT_COMPOSE;
sel.flags = V4L2_SEL_FLAG_LE;
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &amp;sel);
if (ret)
@ -298,11 +298,11 @@ V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para>
&v4l2-selection; compose = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_COMPOSE_ACTIVE,
.target = V4L2_SEL_TGT_COMPOSE,
};
&v4l2-selection; crop = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_CROP_ACTIVE,
.target = V4L2_SEL_TGT_CROP,
};
double hscale, vscale;

164
Documentation/DocBook/media/v4l/selections-common.xml Normal file
View File

@ -0,0 +1,164 @@
<section id="v4l2-selections-common">
<title>Common selection definitions</title>
<para>While the <link linkend="selection-api">V4L2 selection
API</link> and <link linkend="v4l2-subdev-selections">V4L2 subdev
selection APIs</link> are very similar, there's one fundamental
difference between the two. On sub-device API, the selection
rectangle refers to the media bus format, and is bound to a
sub-device's pad. On the V4L2 interface the selection rectangles
refer to the in-memory pixel format.</para>
<para>This section defines the common definitions of the
selection interfaces on the two APIs.</para>
<section id="v4l2-selection-targets">
<title>Selection targets</title>
<para>The precise meaning of the selection targets may be
dependent on which of the two interfaces they are used.</para>
<table pgwide="1" frame="none" id="v4l2-selection-targets-table">
<title>Selection target definitions</title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
&cs-def;
<thead>
<row rowsep="1">
<entry align="left">Target name</entry>
<entry align="left">id</entry>
<entry align="left">Definition</entry>
<entry align="left">Valid for V4L2</entry>
<entry align="left">Valid for V4L2 subdev</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_TGT_CROP</constant></entry>
<entry>0x0000</entry>
<entry>Crop rectangle. Defines the cropped area.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
<entry>0x0001</entry>
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>0x0002</entry>
<entry>Bounds of the crop rectangle. All valid crop
rectangles fit inside the crop bounds rectangle.
</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE</constant></entry>
<entry>0x0100</entry>
<entry>Compose rectangle. Used to configure scaling
and composition.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
<entry>0x0101</entry>
<entry>Suggested composition rectangle that covers the "whole picture".</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>0x0102</entry>
<entry>Bounds of the compose rectangle. All valid compose
rectangles fit inside the compose bounds rectangle.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
<entry>0x0103</entry>
<entry>The active area and all padding pixels that are inserted or
modified by hardware.</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section id="v4l2-selection-flags">
<title>Selection flags</title>
<table pgwide="1" frame="none" id="v4l2-selection-flags-table">
<title>Selection flag definitions</title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
&cs-def;
<thead>
<row rowsep="1">
<entry align="left">Flag name</entry>
<entry align="left">id</entry>
<entry align="left">Definition</entry>
<entry align="left">Valid for V4L2</entry>
<entry align="left">Valid for V4L2 subdev</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
<entry>(1 &lt;&lt; 0)</entry>
<entry>Suggest the driver it should choose greater or
equal rectangle (in size) than was requested. Albeit the
driver may choose a lesser size, it will only do so due to
hardware limitations. Without this flag (and
<constant>V4L2_SEL_FLAG_LE</constant>) the
behaviour is to choose the closest possible
rectangle.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
<entry>(1 &lt;&lt; 1)</entry>
<entry>Suggest the driver it
should choose lesser or equal rectangle (in size) than was
requested. Albeit the driver may choose a greater size, it
will only do so due to hardware limitations.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_KEEP_CONFIG</constant></entry>
<entry>(1 &lt;&lt; 2)</entry>
<entry>The configuration must not be propagated to any
further processing steps. If this flag is not given, the
configuration is propagated inside the subdevice to all
further processing steps.</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>

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

@ -140,6 +140,11 @@ structs, ioctls) must be noted in more detail in the history chapter
applications. -->
<revision>
<revnumber>3.6</revnumber>
<date>2012-07-02</date>
<authorinitials>hv</authorinitials>
<revremark>Added VIDIOC_ENUM_FREQ_BANDS.
</revremark>
<revnumber>3.5</revnumber>
<date>2012-05-07</date>
<authorinitials>sa, sn</authorinitials>
@ -534,6 +539,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-enum-fmt;
&sub-enum-framesizes;
&sub-enum-frameintervals;
&sub-enum-freq-bands;
&sub-enuminput;
&sub-enumoutput;
&sub-enumstd;
@ -589,6 +595,11 @@ and discussions on the V4L mailing list.</revremark>
&sub-write;
</appendix>
<appendix>
<title>Common definitions for V4L2 and V4L2 subdev interfaces</title>
&sub-selections-common;
</appendix>
<appendix id="videodev">
<title>Video For Linux Two Header File</title>
&sub-videodev2-h;

12
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
View File

@ -64,7 +64,7 @@ different sizes.</para>
<para>To allocate device buffers applications initialize relevant fields of
the <structname>v4l2_create_buffers</structname> structure. They set the
<structfield>type</structfield> field in the
<structname>v4l2_format</structname> structure, embedded in this
&v4l2-format; structure, embedded in this
structure, to the respective stream or buffer type.
<structfield>count</structfield> must be set to the number of required buffers.
<structfield>memory</structfield> specifies the required I/O method. The
@ -97,7 +97,13 @@ information.</para>
<row>
<entry>__u32</entry>
<entry><structfield>count</structfield></entry>
<entry>The number of buffers requested or granted.</entry>
<entry>The number of buffers requested or granted. If count == 0, then
<constant>VIDIOC_CREATE_BUFS</constant> will set <structfield>index</structfield>
to the current number of created buffers, and it will check the validity of
<structfield>memory</structfield> and <structfield>format.type</structfield>.
If those are invalid -1 is returned and errno is set to &EINVAL;,
otherwise <constant>VIDIOC_CREATE_BUFS</constant> returns 0. It will
never set errno to &EBUSY; in this particular case.</entry>
</row>
<row>
<entry>__u32</entry>
@ -108,7 +114,7 @@ information.</para>
/></entry>
</row>
<row>
<entry>struct&nbsp;v4l2_format</entry>
<entry>&v4l2-format;</entry>
<entry><structfield>format</structfield></entry>
<entry>Filled in by the application, preserved by the driver.</entry>
</row>

14
Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
View File

@ -54,15 +54,9 @@
interface and may change in the future.</para>
</note>
<para>To query the available timings, applications initialize the
<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-timings-cap;
and call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl with a pointer to this
structure. Drivers fill the rest of the structure or return an
&EINVAL; when the index is out of bounds. To enumerate all supported DV timings,
applications shall begin at index zero, incrementing by one until the
driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a
different set of DV timings after switching the video input or
output.</para>
<para>To query the capabilities of the DV receiver/transmitter applications can call
this ioctl and the driver will fill in the structure. Note that drivers may return
different values after switching the video input or output.</para>
<table pgwide="1" frame="none" id="v4l2-bt-timings-cap">
<title>struct <structname>v4l2_bt_timings_cap</structname></title>
@ -115,7 +109,7 @@ output.</para>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[16]</entry>
<entry></entry>
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
</row>
</tbody>
</tgroup>

179
Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml Normal file
View File

@ -0,0 +1,179 @@
<refentry id="vidioc-enum-freq-bands">
<refmeta>
<refentrytitle>ioctl VIDIOC_ENUM_FREQ_BANDS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_ENUM_FREQ_BANDS</refname>
<refpurpose>Enumerate supported frequency bands</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_frequency_band
*<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_ENUM_FREQ_BANDS</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>Enumerates the frequency bands that a tuner or modulator supports.
To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield> and <structfield>index</structfield> fields,
and zero out the <structfield>reserved</structfield> array of a &v4l2-frequency-band; and
call the <constant>VIDIOC_ENUM_FREQ_BANDS</constant> ioctl with a pointer
to this structure.</para>
<para>This ioctl is supported if the <constant>V4L2_TUNER_CAP_FREQ_BANDS</constant> capability
of the corresponding tuner/modulator is set.</para>
<table pgwide="1" frame="none" id="v4l2-frequency-band">
<title>struct <structname>v4l2_frequency_band</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>tuner</structfield></entry>
<entry>The tuner or modulator index number. This is the
same value as in the &v4l2-input; <structfield>tuner</structfield>
field and the &v4l2-tuner; <structfield>index</structfield> field, or
the &v4l2-output; <structfield>modulator</structfield> field and the
&v4l2-modulator; <structfield>index</structfield> field.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>The tuner type. This is the same value as in the
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
for all others. Set this field to <constant>V4L2_TUNER_RADIO</constant> for
modulators (currently only radio modulators are supported).
See <xref linkend="v4l2-tuner-type" /></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Identifies the frequency band, set by the application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>capability</structfield></entry>
<entry spanname="hspan">The tuner/modulator capability flags for
this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant>
capability must be the same for all frequency bands of the selected tuner/modulator.
So either all bands have that capability set, or none of them have that capability.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangelow</structfield></entry>
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangehigh</structfield></entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>modulation</structfield></entry>
<entry spanname="hspan">The supported modulation systems of this frequency band.
See <xref linkend="band-modulation" />. Note that currently only one
modulation system per frequency band is supported. More work will need to
be done if multiple modulation systems are possible. Contact the
linux-media mailing list (&v4l-ml;) if you need that functionality.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers
must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="band-modulation">
<title>Band Modulation Systems</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_BAND_MODULATION_VSB</constant></entry>
<entry>0x02</entry>
<entry>Vestigial Sideband modulation, used for analog TV.</entry>
</row>
<row>
<entry><constant>V4L2_BAND_MODULATION_FM</constant></entry>
<entry>0x04</entry>
<entry>Frequency Modulation, commonly used for analog radio.</entry>
</row>
<row>
<entry><constant>V4L2_BAND_MODULATION_AM</constant></entry>
<entry>0x08</entry>
<entry>Amplitude Modulation, commonly used for analog radio.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>tuner</structfield> or <structfield>index</structfield>
is out of bounds or the <structfield>type</structfield> field is wrong.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

13
Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
View File

@ -98,11 +98,12 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>The tuner type. This is the same value as in the
&v4l2-tuner; <structfield>type</structfield> field. See The type must be set
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
for all others. The field is not applicable to modulators, &ie; ignored
by drivers. See <xref linkend="v4l2-tuner-type" /></entry>
for all others. Set this field to <constant>V4L2_TUNER_RADIO</constant> for
modulators (currently only radio modulators are supported).
See <xref linkend="v4l2-tuner-type" /></entry>
</row>
<row>
<entry>__u32</entry>
@ -135,6 +136,12 @@ bounds or the value in the <structfield>type</structfield> field is
wrong.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>A hardware seek is in progress.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

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

@ -65,9 +65,9 @@ Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
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
to <constant> V4L2_SEL_TGT_CROP </constant> (<constant>
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
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
@ -86,9 +86,9 @@ use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
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
<constant>V4L2_SEL_TGT_CROP</constant> (<constant>
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
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
@ -154,74 +154,8 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
</refsect1>
<refsect1>
<table frame="none" pgwide="1" id="v4l2-sel-target">
<title>Selection targets.</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_TGT_CROP_ACTIVE</constant></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>0x0001</entry>
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>0x0002</entry>
<entry>Limits for the cropping rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_ACTIVE</constant></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>0x0101</entry>
<entry>Suggested composing rectangle that covers the "whole picture".</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>0x0102</entry>
<entry>Limits for the composing rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
<entry>0x0103</entry>
<entry>The active area and all padding pixels that are inserted or modified by hardware.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
<table frame="none" pgwide="1" id="v4l2-sel-flags">
<title>Selection constraint flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
<entry>0x00000001</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>Indicates that the adjusted rectangle must be inside the original
&v4l2-rect; <structfield>r</structfield> rectangle.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para>
<section>
<figure id="sel-const-adjust">
@ -252,14 +186,14 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
<row>
<entry>__u32</entry>
<entry><structfield>target</structfield></entry>
<entry>Used to select between <link linkend="v4l2-sel-target"> cropping
<entry>Used to select between <link linkend="v4l2-selections-common"> cropping
and composing rectangles</link>.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags controlling the selection rectangle adjustments, refer to
<link linkend="v4l2-sel-flags">selection flags</link>.</entry>
<link linkend="v4l2-selection-flags">selection flags</link>.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>

38
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
View File

@ -119,10 +119,14 @@ field is not quite clear.--></para></entry>
<xref linkend="tuner-capability" />. Audio flags indicate the ability
to decode audio subprograms. They will <emphasis>not</emphasis>
change, for example with the current video standard.</para><para>When
the structure refers to a radio tuner only the
<constant>V4L2_TUNER_CAP_LOW</constant>,
<constant>V4L2_TUNER_CAP_STEREO</constant> and
<constant>V4L2_TUNER_CAP_RDS</constant> flags can be set.</para></entry>
the structure refers to a radio tuner the
<constant>V4L2_TUNER_CAP_LANG1</constant>,
<constant>V4L2_TUNER_CAP_LANG2</constant> and
<constant>V4L2_TUNER_CAP_NORM</constant> flags can't be used.</para>
<para>If multiple frequency bands are supported, then
<structfield>capability</structfield> is the union of all
<structfield>capability></structfield> fields of each &v4l2-frequency-band;.
</para></entry>
</row>
<row>
<entry>__u32</entry>
@ -130,7 +134,9 @@ the structure refers to a radio tuner only the
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz. If multiple frequency bands are supported, then
<structfield>rangelow</structfield> is the lowest frequency
of all the frequency bands.</entry>
</row>
<row>
<entry>__u32</entry>
@ -138,7 +144,9 @@ Hz.</entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz. If multiple frequency bands are supported, then
<structfield>rangehigh</structfield> is the highest frequency
of all the frequency bands.</entry>
</row>
<row>
<entry>__u32</entry>
@ -275,6 +283,18 @@ can or must be switched. (B/G PAL tuners for example are typically not
see the description of ioctl &VIDIOC-ENUMINPUT; for details. Only
<constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_HWSEEK_BOUNDED</constant></entry>
<entry>0x0004</entry>
<entry>If set, then this tuner supports the hardware seek functionality
where the seek stops when it reaches the end of the frequency range.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_HWSEEK_WRAP</constant></entry>
<entry>0x0008</entry>
<entry>If set, then this tuner supports the hardware seek functionality
where the seek wraps around when it reaches the end of the frequency range.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_STEREO</constant></entry>
<entry>0x0010</entry>
@ -328,6 +348,12 @@ radio tuners.</entry>
<entry>0x0200</entry>
<entry>The RDS data is parsed by the hardware and set via controls.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_FREQ_BANDS</constant></entry>
<entry>0x0400</entry>
<entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate
the available frequency bands.</entry>
</row>
</tbody>
</tgroup>
</table>

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

@ -71,12 +71,9 @@ initialize the <structfield>bytesused</structfield>,
<structfield>field</structfield> and
<structfield>timestamp</structfield> fields, see <xref
linkend="buffer" /> for details.
Applications must also set <structfield>flags</structfield> to 0. If a driver
supports capturing from specific video inputs and you want to specify a video
input, then <structfield>flags</structfield> should be set to
<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
<structfield>input</structfield> must be initialized to the desired input.
The <structfield>reserved</structfield> field must be set to 0. When using
Applications must also set <structfield>flags</structfield> to 0.
The <structfield>reserved2</structfield> and
<structfield>reserved</structfield> fields must be set to 0. When using
the <link linkend="planar-apis">multi-planar API</link>, the
<structfield>m.planes</structfield> field must contain a userspace pointer
to a filled-in array of &v4l2-plane; and the <structfield>length</structfield>

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

@ -191,6 +191,19 @@ linkend="output">Video Output</link> interface.</entry>
<link linkend="planar-apis">multi-planar API</link> through the
<link linkend="output">Video Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_M2M</constant></entry>
<entry>0x00004000</entry>
<entry>The device supports the single-planar API through the
Video Memory-To-Memory interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant></entry>
<entry>0x00008000</entry>
<entry>The device supports the
<link linkend="planar-apis">multi-planar API</link> through the
Video Memory-To-Memory interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
<entry>0x00000004</entry>

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

@ -52,11 +52,26 @@
<para>Start a hardware frequency seek from the current frequency.
To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield>, <structfield>seek_upward</structfield>,
<structfield>spacing</structfield> and
<structfield>wrap_around</structfield> fields, and zero out the
<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
to this structure.</para>
<structfield>wrap_around</structfield>, <structfield>spacing</structfield>,
<structfield>rangelow</structfield> and <structfield>rangehigh</structfield>
fields, and zero out the <structfield>reserved</structfield> array of a
&v4l2-hw-freq-seek; and call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
ioctl with a pointer to this structure.</para>
<para>The <structfield>rangelow</structfield> and
<structfield>rangehigh</structfield> fields can be set to a non-zero value to
tell the driver to search a specific band. If the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag set, these values
must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If
the <constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag is not set,
then these values must exactly match those of one of the bands returned by
&VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall
within the selected band it will be clamped to fit in the band before the
seek is started.</para>
<para>If an error is returned, then the original frequency will
be restored.</para>
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
@ -87,7 +102,10 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>wrap_around</structfield></entry>
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.</entry>
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.
The &v4l2-tuner; <structfield>capability</structfield> field will tell you what the
hardware supports.
</entry>
</row>
<row>
<entry>__u32</entry>
@ -96,7 +114,27 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[7]</entry>
<entry><structfield>rangelow</structfield></entry>
<entry>If non-zero, the lowest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
If <structfield>rangelow</structfield> is zero a reasonable default value
is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangehigh</structfield></entry>
<entry>If non-zero, the highest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
If <structfield>rangehigh</structfield> is zero a reasonable default value
is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[5]</entry>
<entry>Reserved for future extensions. Applications
must set the array to zero.</entry>
</row>
@ -113,14 +151,22 @@ 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, the wrap_around value is not supported or the value in the <structfield>type</structfield> field is
wrong.</para>
bounds, the <structfield>wrap_around</structfield> value is not supported or
one of the values in the <structfield>type</structfield>,
<structfield>rangelow</structfield> or <structfield>rangehigh</structfield>
fields is wrong.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EAGAIN</errorcode></term>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>The ioctl timed-out. Try again.</para>
<para>The hardware seek found no channels.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>Another hardware seek is already in progress.</para>
</listitem>
</varlistentry>
</variablelist>

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

@ -72,10 +72,10 @@
<section>
<title>Types of selection targets</title>
<para>There are two types of selection targets: actual and bounds.
The ACTUAL targets are the targets which configure the hardware.
The BOUNDS target will return a rectangle that contain all
possible ACTUAL rectangles.</para>
<para>There are two types of selection targets: actual and bounds. The
actual targets are the targets which configure the hardware. The BOUNDS
target will return a rectangle that contain all possible actual
rectangles.</para>
</section>
<section>
@ -87,71 +87,8 @@
<constant>EINVAL</constant>.</para>
</section>
<table pgwide="1" frame="none" id="v4l2-subdev-selection-targets">
<title>V4L2 subdev selection targets</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL</constant></entry>
<entry>0x0000</entry>
<entry>Actual crop. Defines the cropping
performed by the processing step.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>0x0002</entry>
<entry>Bounds of the crop rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL</constant></entry>
<entry>0x0100</entry>
<entry>Actual compose rectangle. Used to configure scaling
on sink pads and composition on source pads.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>0x0102</entry>
<entry>Bounds of the compose rectangle.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-subdev-selection-flags">
<title>V4L2 subdev selection flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant></entry>
<entry>(1 &lt;&lt; 0)</entry> <entry>Suggest the driver it
should choose greater or equal rectangle (in size) than
was requested. Albeit the driver may choose a lesser size,
it will only do so due to hardware limitations. Without
this flag (and
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant>) the
behaviour is to choose the closest possible
rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant></entry>
<entry>(1 &lt;&lt; 1)</entry> <entry>Suggest the driver it
should choose lesser or equal rectangle (in size) than was
requested. Albeit the driver may choose a greater size, it
will only do so due to hardware limitations.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant></entry>
<entry>(1 &lt;&lt; 2)</entry>
<entry>The configuration should not be propagated to any
further processing steps. If this flag is not given, the
configuration is propagated inside the subdevice to all
further processing steps.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-selection">
<title>struct <structname>v4l2_subdev_selection</structname></title>
@ -173,13 +110,13 @@
<entry>__u32</entry>
<entry><structfield>target</structfield></entry>
<entry>Target selection rectangle. See
<xref linkend="v4l2-subdev-selection-targets">.</xref>.</entry>
<xref linkend="v4l2-selections-common" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags. See
<xref linkend="v4l2-subdev-selection-flags">.</xref></entry>
<xref linkend="v4l2-selection-flags" />.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>

45
Documentation/cgroups/hugetlb.txt Normal file
View File

@ -0,0 +1,45 @@
HugeTLB Controller
-------------------
The HugeTLB controller allows to limit the HugeTLB usage per control group and
enforces the controller limit during page fault. Since HugeTLB doesn't
support page reclaim, enforcing the limit at page fault time implies that,
the application will get SIGBUS signal if it tries to access HugeTLB pages
beyond its limit. This requires the application to know beforehand how much
HugeTLB pages it would require for its use.
HugeTLB controller can be created by first mounting the cgroup filesystem.
# mount -t cgroup -o hugetlb none /sys/fs/cgroup
With the above step, the initial or the parent HugeTLB group becomes
visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in
the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
New groups can be created under the parent group /sys/fs/cgroup.
# cd /sys/fs/cgroup
# mkdir g1
# echo $$ > g1/tasks
The above steps create a new group g1 and move the current shell
process (bash) into it.
Brief summary of control files
hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current res_counter usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit
For a system supporting two hugepage size (16M and 16G) the control
files include:
hugetlb.16GB.limit_in_bytes
hugetlb.16GB.max_usage_in_bytes
hugetlb.16GB.usage_in_bytes
hugetlb.16GB.failcnt
hugetlb.16MB.limit_in_bytes
hugetlb.16MB.max_usage_in_bytes
hugetlb.16MB.usage_in_bytes
hugetlb.16MB.failcnt

12
Documentation/cgroups/memory.txt
View File

@ -73,6 +73,8 @@ Brief summary of control files.
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
memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
memory.kmem.tcp.max_usage_in_bytes # show max tcp buf memory usage recorded
1. History
@ -187,12 +189,12 @@ the cgroup that brought it in -- this will happen on memory pressure).
But see section 8.2: when moving a task to another cgroup, its pages may
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
Exception: If CONFIG_CGROUP_CGROUP_MEMCG_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP)
2.4 Swap Extension (CONFIG_MEMCG_SWAP)
Swap Extension allows you to record charge for swap. A swapped-in page is
charged back to original page allocator if possible.
@ -259,7 +261,7 @@ 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)
2.7 Kernel Memory Extension (CONFIG_MEMCG_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
@ -286,8 +288,8 @@ per cgroup, instead of globally.
a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension)
c. Enable CONFIG_MEMCG
d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup

7
Documentation/device-mapper/striped.txt
View File

@ -9,15 +9,14 @@ devices in parallel.
Parameters: <num devs> <chunk size> [<dev path> <offset>]+
<num devs>: Number of underlying devices.
<chunk size>: Size of each chunk of data. Must be a power-of-2 and at
least as large as the system's PAGE_SIZE.
<chunk size>: Size of each chunk of data. Must be at least as
large as the system's PAGE_SIZE.
<dev path>: Full pathname to the underlying block-device, or a
"major:minor" device-number.
<offset>: Starting sector within the device.
One or more underlying devices can be specified. The striped device size must
be a multiple of the chunk size and a multiple of the number of underlying
devices.
be a multiple of the chunk size multiplied by the number of underlying devices.
Example scripts

24
Documentation/device-mapper/thin-provisioning.txt
View File

@ -231,6 +231,9 @@ i) Constructor
no_discard_passdown: Don't pass discards down to the underlying
data device, but just remove the mapping.
read_only: Don't allow any changes to be made to the pool
metadata.
Data block size must be between 64KB (128 sectors) and 1GB
(2097152 sectors) inclusive.
@ -239,7 +242,7 @@ ii) Status
<transaction id> <used metadata blocks>/<total metadata blocks>
<used data blocks>/<total data blocks> <held metadata root>
[no_]discard_passdown ro|rw
transaction id:
A 64-bit number used by userspace to help synchronise with metadata
@ -257,6 +260,21 @@ ii) Status
held root. This feature is not yet implemented so '-' is
always returned.
discard_passdown|no_discard_passdown
Whether or not discards are actually being passed down to the
underlying device. When this is enabled when loading the table,
it can get disabled if the underlying device doesn't support it.
ro|rw
If the pool encounters certain types of device failures it will
drop into a read-only metadata mode in which no changes to
the pool metadata (like allocating new blocks) are permitted.
In serious cases where even a read-only mode is deemed unsafe
no further I/O will be permitted and the status will just
contain the string 'Fail'. The userspace recovery tools
should then be used.
iii) Messages
create_thin <dev id>
@ -329,3 +347,7 @@ regain some space then send the 'trim' message to the pool.
ii) Status
<nr mapped sectors> <highest mapped sector>
If the pool has encountered device errors and failed, the status
will just contain the string 'Fail'. The userspace recovery
tools should then be used.

15
Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt Normal file
View File

@ -0,0 +1,15 @@
Calxeda Highbank L2 cache ECC
Properties:
- compatible : Should be "calxeda,hb-sregs-l2-ecc"
- reg : Address and size for ECC error interrupt clear registers.
- interrupts : Should be single bit error interrupt, then double bit error
interrupt.
Example:
sregs@fff3c200 {
compatible = "calxeda,hb-sregs-l2-ecc";
reg = <0xfff3c200 0x100>;
interrupts = <0 71 4 0 72 4>;
};

14
Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt Normal file
View File

@ -0,0 +1,14 @@
Calxeda DDR memory controller
Properties:
- compatible : Should be "calxeda,hb-ddr-ctrl"
- reg : Address and size for DDR controller registers.
- interrupts : Interrupt for DDR controller.
Example:
memory-controller@fff00000 {
compatible = "calxeda,hb-ddr-ctrl";
reg = <0xfff00000 0x1000>;
interrupts = <0 91 4>;
};

30
Documentation/devicetree/bindings/ata/cavium-compact-flash.txt Normal file
View File

@ -0,0 +1,30 @@
* Compact Flash
The Cavium Compact Flash device is connected to the Octeon Boot Bus,
and is thus a child of the Boot Bus device. It can read and write
industry standard compact flash devices.
Properties:
- compatible: "cavium,ebt3000-compact-flash";
Compatibility with many Cavium evaluation boards.
- reg: The base address of the the CF chip select banks. Depending on
the device configuration, there may be one or two banks.
- cavium,bus-width: The width of the connection to the CF devices. Valid
values are 8 and 16.
- cavium,true-ide: Optional, if present the CF connection is in True IDE mode.
- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected
to this device.
Example:
compact-flash@5,0 {
compatible = "cavium,ebt3000-compact-flash";
reg = <5 0 0x10000>, <6 0 0x10000>;
cavium,bus-width = <16>;
cavium,true-ide;
cavium,dma-engine-handle = <&dma0>;
};

49
Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt Normal file
View File

@ -0,0 +1,49 @@
* General Purpose Input Output (GPIO) bus.
Properties:
- compatible: "cavium,octeon-3860-gpio"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the GPIO unit's register bank.
- gpio-controller: This is a GPIO controller.
- #gpio-cells: Must be <2>. The first cell is the GPIO pin.
- interrupt-controller: The GPIO controller is also an interrupt
controller, many of its pins may be configured as an interrupt
source.
- #interrupt-cells: Must be <2>. The first cell is the GPIO pin
connected to the interrupt source. The second cell is the interrupt
triggering protocol and may have one of four values:
1 - edge triggered on the rising edge.
2 - edge triggered on the falling edge
4 - level triggered active high.
8 - level triggered active low.
- interrupts: Interrupt routing for each pin.
Example:
gpio-controller@1070000000800 {
#gpio-cells = <2>;
compatible = "cavium,octeon-3860-gpio";
reg = <0x10700 0x00000800 0x0 0x100>;
gpio-controller;
/* Interrupts are specified by two parts:
* 1) GPIO pin number (0..15)
* 2) Triggering (1 - edge rising
* 2 - edge falling
* 4 - level active high
* 8 - level active low)
*/
interrupt-controller;
#interrupt-cells = <2>;
/* The GPIO pin connect to 16 consecutive CUI bits */
interrupts = <0 16>, <0 17>, <0 18>, <0 19>,
<0 20>, <0 21>, <0 22>, <0 23>,
<0 24>, <0 25>, <0 26>, <0 27>,
<0 28>, <0 29>, <0 30>, <0 31>;
};

2
Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt
View File

@ -22,7 +22,7 @@ Required properties:
Example:
gpio0: gpio@73f84000 {
compatible = "fsl,imx51-gpio", "fsl,imx31-gpio";
compatible = "fsl,imx51-gpio", "fsl,imx35-gpio";
reg = <0x73f84000 0x4000>;
interrupts = <50 51>;
gpio-controller;

9
Documentation/devicetree/bindings/gpio/gpio-samsung.txt
View File

@ -11,14 +11,15 @@ Required properties:
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[pull up/down]
[flags and 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.
- Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
Bit 16 (0x00010000) - Input is active low.
- Drive Strength: 0 - 1x,
1 - 3x,
2 - 2x,

34
Documentation/devicetree/bindings/i2c/cavium-i2c.txt Normal file
View File

@ -0,0 +1,34 @@
* Two Wire Serial Interface (TWSI) / I2C
- compatible: "cavium,octeon-3860-twsi"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the TWSI/I2C bus controller register bank.
- #address-cells: Must be <1>.
- #size-cells: Must be <0>. I2C addresses have no size component.
- interrupts: A single interrupt specifier.
- clock-frequency: The I2C bus clock rate in Hz.
Example:
twsi0: i2c@1180000001000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "cavium,octeon-3860-twsi";
reg = <0x11800 0x00001000 0x0 0x200>;
interrupts = <0 45>;
clock-frequency = <100000>;
rtc@68 {
compatible = "dallas,ds1337";
reg = <0x68>;
};
tmp@4c {
compatible = "ti,tmp421";
reg = <0x4c>;
};
};

0
Documentation/devicetree/bindings/gpio/gpio_i2c.txt → Documentation/devicetree/bindings/i2c/gpio-i2c.txt
View File

3
Documentation/devicetree/bindings/i2c/i2c-mxs.txt
View File

@ -4,6 +4,8 @@ Required properties:
- compatible: Should be "fsl,<chip>-i2c"
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
- clock-frequency: Desired I2C bus clock frequency in Hz.
Only 100000Hz and 400000Hz modes are supported.
Examples:
@ -13,4 +15,5 @@ i2c0: i2c@80058000 {
compatible = "fsl,imx28-i2c";
reg = <0x80058000 2000>;
interrupts = <111 68>;
clock-frequency = <100000>;
};

33
Documentation/devicetree/bindings/i2c/i2c-ocores.txt Normal file
View File

@ -0,0 +1,33 @@
Device tree configuration for i2c-ocores
Required properties:
- compatible : "opencores,i2c-ocores"
- reg : bus address start and address range size of device
- interrupts : interrupt number
- clock-frequency : frequency of bus clock in Hz
- #address-cells : should be <1>
- #size-cells : should be <0>
Optional properties:
- reg-shift : device register offsets are shifted by this value
- reg-io-width : io register width in bytes (1, 2 or 4)
- regstep : deprecated, use reg-shift above
Example:
i2c0: ocores@a0000000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "opencores,i2c-ocores";
reg = <0xa0000000 0x8>;
interrupts = <10>;
clock-frequency = <20000000>;
reg-shift = <0>; /* 8 bit registers */
reg-io-width = <1>; /* 8 bit read/write */
dummy@60 {
compatible = "dummy";
reg = <0x60>;
};
};

19
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
View File

@ -1,4 +1,4 @@
* I2C
* Marvell MMP I2C controller
Required properties :
@ -32,3 +32,20 @@ Examples:
interrupts = <58>;
};
* Marvell MV64XXX I2C controller
Required properties :
- reg : Offset and length of the register set for the device
- compatible : Should be "marvell,mv64xxx-i2c"
- interrupts : The interrupt number
- clock-frequency : Desired I2C bus clock frequency in Hz.
Examples:
i2c@11000 {
compatible = "marvell,mv64xxx-i2c";
reg = <0x11000 0x20>;
interrupts = <29>;
clock-frequency = <100000>;
};

28
Documentation/devicetree/bindings/input/lpc32xx-key.txt Normal file
View File

@ -0,0 +1,28 @@
NXP LPC32xx Key Scan Interface
Required Properties:
- compatible: Should be "nxp,lpc3220-key"
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
supports square matrices
- nxp,debounce-delay-ms: Debounce delay in ms
- nxp,scan-delay-ms: Repeated scan period in ms
- linux,keymap: the key-code to be reported when the key is pressed
and released, see also
Documentation/devicetree/bindings/input/matrix-keymap.txt
Example:
key@40050000 {
compatible = "nxp,lpc3220-key";
reg = <0x40050000 0x1000>;
interrupts = <54 0>;
keypad,num-rows = <1>;
keypad,num-columns = <1>;
nxp,debounce-delay-ms = <3>;
nxp,scan-delay-ms = <34>;
linux,keymap = <0x00000002>;
};

31
Documentation/devicetree/bindings/input/omap-keypad.txt Normal file
View File

@ -0,0 +1,31 @@
* TI's Keypad Controller device tree bindings
TI'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
- "ti,omap4-keypad": For controllers compatible with omap4 keypad
controller.
Required Board Specific Properties, in addition to those specified by
the shared matrix-keyboard bindings:
- keypad,num-rows: Number of row lines connected to the keypad
controller.
- keypad,num-columns: Number of column lines connected to the
keypad controller.
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
Example:
keypad@4ae1c000{
compatible = "ti,omap4-keypad";
keypad,num-rows = <2>;
keypad,num-columns = <8>;
linux,keypad-no-autorepeat;
};

37
Documentation/devicetree/bindings/input/twl6040-vibra.txt
View File

@ -1,37 +0,0 @@
Vibra driver for the twl6040 family
The vibra driver is a child of the twl6040 MFD dirver.
Documentation/devicetree/bindings/mfd/twl6040.txt
Required properties:
- compatible : Must be "ti,twl6040-vibra";
- interrupts: 4, Vibra overcurrent interrupt
- vddvibl-supply: Regulator supplying the left vibra motor
- vddvibr-supply: Regulator supplying the right vibra motor
- vibldrv_res: Board specific left driver resistance
- vibrdrv_res: Board specific right driver resistance
- viblmotor_res: Board specific left motor resistance
- vibrmotor_res: Board specific right motor resistance
Optional properties:
- vddvibl_uV: If the vddvibl default voltage need to be changed
- vddvibr_uV: If the vddvibr default voltage need to be changed
Example:
/*
* 8-channel high quality low-power audio codec
* http://www.ti.com/lit/ds/symlink/twl6040.pdf
*/
twl6040: twl6040@4b {
...
twl6040_vibra: twl6040@1 {
compatible = "ti,twl6040-vibra";
interrupts = <4>;
vddvibl-supply = <&vbat>;
vddvibr-supply = <&vbat>;
vibldrv_res = <8>;
vibrdrv_res = <3>;
viblmotor_res = <10>;
vibrmotor_res = <10>;
};
};

123
Documentation/devicetree/bindings/mfd/ab8500.txt Normal file
View File

@ -0,0 +1,123 @@
* AB8500 Multi-Functional Device (MFD)
Required parent device properties:
- compatible : contains "stericsson,ab8500";
- interrupts : contains the IRQ line for the AB8500
- interrupt-controller : describes the AB8500 as an Interrupt Controller (has its own domain)
- #interrupt-cells : should be 2, for 2-cell format
- The first cell is the AB8500 local IRQ number
- The second cell is used to specify optional parameters
- bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Optional parent device properties:
- reg : contains the PRCMU mailbox address for the AB8500 i2c port
The AB8500 consists of a large and varied group of sub-devices:
Device IRQ Names Supply Names Description
------ --------- ------------ -----------
ab8500-bm : : : Battery Manager
ab8500-btemp : : : Battery Temperature
ab8500-charger : : : Battery Charger
ab8500-fg : : : Fuel Gauge
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter
SW_CONV_END : :
ab8500-gpio : : : GPIO Controller
ab8500-ponkey : ONKEY_DBF : : Power-on Key
ONKEY_DBR : :
ab8500-pwm : : : Pulse Width Modulator
ab8500-regulator : : : Regulators
ab8500-rtc : 60S : : Real Time Clock
: ALARM : :
ab8500-sysctrl : : : System Control
ab8500-usb : ID_WAKEUP_R : vddulpivio18 : Universal Serial Bus
: ID_WAKEUP_F : v-ape :
: VBUS_DET_F : musb_1v8 :
: VBUS_DET_R : :
: USB_LINK_STATUS : :
: USB_ADP_PROBE_PLUG : :
: USB_ADP_PROBE_UNPLUG : :
Required child device properties:
- compatible : "stericsson,ab8500-[bm|btemp|charger|fg|gpadc|gpio|ponkey|
pwm|regulator|rtc|sysctrl|usb]";
Optional child device properties:
- interrupts : contains the device IRQ(s) using the 2-cell format (see above)
- interrupt-names : contains names of IRQ resource in the order in which they were
supplied in the interrupts property
- <supply_name>-supply : contains a phandle to the regulator supply node in Device Tree
ab8500@5 {
compatible = "stericsson,ab8500";
reg = <5>; /* mailbox 5 is i2c */
interrupts = <0 40 0x4>;
interrupt-controller;
#interrupt-cells = <2>;
ab8500-rtc {
compatible = "stericsson,ab8500-rtc";
interrupts = <17 0x4
18 0x4>;
interrupt-names = "60S", "ALARM";
};
ab8500-gpadc {
compatible = "stericsson,ab8500-gpadc";
interrupts = <32 0x4
39 0x4>;
interrupt-names = "HW_CONV_END", "SW_CONV_END";
vddadc-supply = <&ab8500_ldo_tvout_reg>;
};
ab8500-usb {
compatible = "stericsson,ab8500-usb";
interrupts = < 90 0x4
96 0x4
14 0x4
15 0x4
79 0x4
74 0x4
75 0x4>;
interrupt-names = "ID_WAKEUP_R",
"ID_WAKEUP_F",
"VBUS_DET_F",
"VBUS_DET_R",
"USB_LINK_STATUS",
"USB_ADP_PROBE_PLUG",
"USB_ADP_PROBE_UNPLUG";
vddulpivio18-supply = <&ab8500_ldo_initcore_reg>;
v-ape-supply = <&db8500_vape_reg>;
musb_1v8-supply = <&db8500_vsmps2_reg>;
};
ab8500-ponkey {
compatible = "stericsson,ab8500-ponkey";
interrupts = <6 0x4
7 0x4>;
interrupt-names = "ONKEY_DBF", "ONKEY_DBR";
};
ab8500-sysctrl {
compatible = "stericsson,ab8500-sysctrl";
};
ab8500-pwm {
compatible = "stericsson,ab8500-pwm";
};
ab8500-regulators {
compatible = "stericsson,ab8500-regulator";
ab8500_ldo_aux1_reg: ab8500_ldo_aux1 {
/*
* See: Documentation/devicetree/bindings/regulator/regulator.txt
* for more information on regulators
*/
};
};
};

59
Documentation/devicetree/bindings/mfd/max77686.txt Normal file
View File

@ -0,0 +1,59 @@
Maxim MAX77686 multi-function device
MAX77686 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is
interfaced to host controller using i2c interface. PMIC and Charger submodules
are addressed using same i2c slave address whereas RTC submodule uses
different i2c slave address,presently for which we are statically creating i2c
client while probing.This document describes the binding for mfd device and
PMIC submodule.
Required properties:
- compatible : Must be "maxim,max77686";
- reg : Specifies the i2c slave address of PMIC block.
- interrupts : This i2c device has an IRQ line connected to the main SoC.
- interrupt-parent : The parent interrupt controller.
Optional node:
- voltage-regulators : The regulators of max77686 have to be instantiated
under subnode named "voltage-regulators" using the following format.
regulator_name {
regulator-compatible = LDOn/BUCKn
standard regulator constraints....
};
refer Documentation/devicetree/bindings/regulator/regulator.txt
The regulator-compatible property of regulator should initialized with string
to get matched with their hardware counterparts as follow:
-LDOn : for LDOs, where n can lie in range 1 to 26.
example: LDO1, LDO2, LDO26.
-BUCKn : for BUCKs, where n can lie in range 1 to 9.
example: BUCK1, BUCK5, BUCK9.
Example:
max77686@09 {
compatible = "maxim,max77686";
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
reg = <0x09>;
voltage-regulators {
ldo11_reg {
regulator-compatible = "LDO11";
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <1900000>;
regulator-max-microvolt = <1900000>;
regulator-always-on;
};
buck1_reg {
regulator-compatible = "BUCK1";
regulator-name = "vdd_mif";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
};
}

2
Documentation/devicetree/bindings/mfd/tps65910.txt
View File

@ -81,7 +81,7 @@ Example:
ti,vmbch-threshold = 0;
ti,vmbch2-threshold = 0;
ti,en-ck32k-xtal;
ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
vcc1-supply = <&reg_parent>;

2
Documentation/devicetree/bindings/mfd/twl6040.txt
View File

@ -6,7 +6,7 @@ They are connected ot the host processor via i2c for commands, McPDM for audio
data and commands.
Required properties:
- compatible : Must be "ti,twl6040";
- compatible : "ti,twl6040" for twl6040, "ti,twl6041" for twl6041
- reg: must be 0x4b for i2c address
- interrupts: twl6040 has one interrupt line connecteded to the main SoC
- interrupt-parent: The parent interrupt controller

126
Documentation/devicetree/bindings/mips/cavium/bootbus.txt Normal file
View File

@ -0,0 +1,126 @@
* Boot Bus
The Octeon Boot Bus is a configurable parallel bus with 8 chip
selects. Each chip select is independently configurable.
Properties:
- compatible: "cavium,octeon-3860-bootbus"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the Boot Bus' register bank.
- #address-cells: Must be <2>. The first cell is the chip select
within the bootbus. The second cell is the offset from the chip select.
- #size-cells: Must be <1>.
- ranges: There must be one one triplet of (child-bus-address,
parent-bus-address, length) for each active chip select. If the
length element for any triplet is zero, the chip select is disabled,
making it inactive.
The configuration parameters for each chip select are stored in child
nodes.
Configuration Properties:
- compatible: "cavium,octeon-3860-bootbus-config"
- cavium,cs-index: A single cell indicating the chip select that
corresponds to this configuration.
- cavium,t-adr: A cell specifying the ADR timing (in nS).
- cavium,t-ce: A cell specifying the CE timing (in nS).
- cavium,t-oe: A cell specifying the OE timing (in nS).
- cavium,t-we: A cell specifying the WE timing (in nS).
- cavium,t-rd-hld: A cell specifying the RD_HLD timing (in nS).
- cavium,t-wr-hld: A cell specifying the WR_HLD timing (in nS).
- cavium,t-pause: A cell specifying the PAUSE timing (in nS).
- cavium,t-wait: A cell specifying the WAIT timing (in nS).
- cavium,t-page: A cell specifying the PAGE timing (in nS).
- cavium,t-rd-dly: A cell specifying the RD_DLY timing (in nS).
- cavium,pages: A cell specifying the PAGES parameter (0 = 8 bytes, 1
= 2 bytes, 2 = 4 bytes, 3 = 8 bytes).
- cavium,wait-mode: Optional. If present, wait mode (WAITM) is selected.
- cavium,page-mode: Optional. If present, page mode (PAGEM) is selected.
- cavium,bus-width: A cell specifying the WIDTH parameter (in bits) of
the bus for this chip select.
- cavium,ale-mode: Optional. If present, ALE mode is selected.
- cavium,sam-mode: Optional. If present, SAM mode is selected.
- cavium,or-mode: Optional. If present, OR mode is selected.
Example:
bootbus: bootbus@1180000000000 {
compatible = "cavium,octeon-3860-bootbus";
reg = <0x11800 0x00000000 0x0 0x200>;
/* The chip select number and offset */
#address-cells = <2>;
/* The size of the chip select region */
#size-cells = <1>;
ranges = <0 0 0x0 0x1f400000 0xc00000>,
<1 0 0x10000 0x30000000 0>,
<2 0 0x10000 0x40000000 0>,
<3 0 0x10000 0x50000000 0>,
<4 0 0x0 0x1d020000 0x10000>,
<5 0 0x0 0x1d040000 0x10000>,
<6 0 0x0 0x1d050000 0x10000>,
<7 0 0x10000 0x90000000 0>;
cavium,cs-config@0 {
compatible = "cavium,octeon-3860-bootbus-config";
cavium,cs-index = <0>;
cavium,t-adr = <20>;
cavium,t-ce = <60>;
cavium,t-oe = <60>;
cavium,t-we = <45>;
cavium,t-rd-hld = <35>;
cavium,t-wr-hld = <45>;
cavium,t-pause = <0>;
cavium,t-wait = <0>;
cavium,t-page = <35>;
cavium,t-rd-dly = <0>;
cavium,pages = <0>;
cavium,bus-width = <8>;
};
.
.
.
cavium,cs-config@6 {
compatible = "cavium,octeon-3860-bootbus-config";
cavium,cs-index = <6>;
cavium,t-adr = <5>;
cavium,t-ce = <300>;
cavium,t-oe = <270>;
cavium,t-we = <150>;
cavium,t-rd-hld = <100>;
cavium,t-wr-hld = <70>;
cavium,t-pause = <0>;
cavium,t-wait = <0>;
cavium,t-page = <320>;
cavium,t-rd-dly = <0>;
cavium,pages = <0>;
cavium,wait-mode;
cavium,bus-width = <16>;
};
.
.
.
};

26
Documentation/devicetree/bindings/mips/cavium/ciu.txt Normal file
View File

@ -0,0 +1,26 @@
* Central Interrupt Unit
Properties:
- compatible: "cavium,octeon-3860-ciu"
Compatibility with all cn3XXX, cn5XXX and cn63XX SOCs.
- interrupt-controller: This is an interrupt controller.
- reg: The base address of the CIU's register bank.
- #interrupt-cells: Must be <2>. The first cell is the bank within
the CIU and may have a value of 0 or 1. The second cell is the bit
within the bank and may have a value between 0 and 63.
Example:
interrupt-controller@1070000000000 {
compatible = "cavium,octeon-3860-ciu";
interrupt-controller;
/* Interrupts are specified by two parts:
* 1) Controller register (0 or 1)
* 2) Bit within the register (0..63)
*/
#interrupt-cells = <2>;
reg = <0x10700 0x00000000 0x0 0x7000>;
};

27
Documentation/devicetree/bindings/mips/cavium/ciu2.txt Normal file
View File

@ -0,0 +1,27 @@
* Central Interrupt Unit
Properties:
- compatible: "cavium,octeon-6880-ciu2"
Compatibility with 68XX SOCs.
- interrupt-controller: This is an interrupt controller.
- reg: The base address of the CIU's register bank.
- #interrupt-cells: Must be <2>. The first cell is the bank within
the CIU and may have a value between 0 and 63. The second cell is
the bit within the bank and may also have a value between 0 and 63.
Example:
interrupt-controller@1070100000000 {
compatible = "cavium,octeon-6880-ciu2";
interrupt-controller;
/* Interrupts are specified by two parts:
* 1) Controller register (0..63)
* 2) Bit within the register (0..63)
*/
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x10701 0x00000000 0x0 0x4000000>;
};

21
Documentation/devicetree/bindings/mips/cavium/dma-engine.txt Normal file
View File

@ -0,0 +1,21 @@
* DMA Engine.
The Octeon DMA Engine transfers between the Boot Bus and main memory.
The DMA Engine will be refered to by phandle by any device that is
connected to it.
Properties:
- compatible: "cavium,octeon-5750-bootbus-dma"
Compatibility with all cn52XX, cn56XX and cn6XXX SOCs.
- reg: The base address of the DMA Engine's register bank.
- interrupts: A single interrupt specifier.
Example:
dma0: dma-engine@1180000000100 {
compatible = "cavium,octeon-5750-bootbus-dma";
reg = <0x11800 0x00000100 0x0 0x8>;
interrupts = <0 63>;
};

46
Documentation/devicetree/bindings/mips/cavium/uctl.txt Normal file
View File

@ -0,0 +1,46 @@
* UCTL USB controller glue
Properties:
- compatible: "cavium,octeon-6335-uctl"
Compatibility with all cn6XXX SOCs.
- reg: The base address of the UCTL register bank.
- #address-cells: Must be <2>.
- #size-cells: Must be <2>.
- ranges: Empty to signify direct mapping of the children.
- refclk-frequency: A single cell containing the reference clock
frequency in Hz.
- refclk-type: A string describing the reference clock connection
either "crystal" or "external".
Example:
uctl@118006f000000 {
compatible = "cavium,octeon-6335-uctl";
reg = <0x11800 0x6f000000 0x0 0x100>;
ranges; /* Direct mapping */
#address-cells = <2>;
#size-cells = <2>;
/* 12MHz, 24MHz and 48MHz allowed */
refclk-frequency = <24000000>;
/* Either "crystal" or "external" */
refclk-type = "crystal";
ehci@16f0000000000 {
compatible = "cavium,octeon-6335-ehci","usb-ehci";
reg = <0x16f00 0x00000000 0x0 0x100>;
interrupts = <0 56>;
big-endian-regs;
};
ohci@16f0000000400 {
compatible = "cavium,octeon-6335-ohci","usb-ohci";
reg = <0x16f00 0x00000400 0x0 0x100>;
interrupts = <0 56>;
big-endian-regs;
};
};

21
Documentation/devicetree/bindings/misc/at25.txt Normal file
View File

@ -0,0 +1,21 @@
Atmel AT25 eeprom
Required properties:
- compatible : "atmel,at25".
- reg : chip select number
- spi-max-frequency : max spi frequency to use
- at25,byte-len : total eeprom size in bytes
- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h
- at25,page-size : size of the eeprom page
Examples:
at25@0 {
compatible = "atmel,at25";
reg = <0>
spi-max-frequency = <5000000>;
at25,byte-len = <0x8000>;
at25,addr-mode = <2>;
at25,page-size = <64>;
};

4
Documentation/devicetree/bindings/mtd/orion-nand.txt
View File

@ -1,7 +1,7 @@
NAND support for Marvell Orion SoC platforms
Required properties:
- compatible : "mrvl,orion-nand".
- compatible : "marvell,orion-nand".
- reg : Base physical address of the NAND and length of memory mapped
region
@ -24,7 +24,7 @@ nand@f4000000 {
ale = <1>;
bank-width = <1>;
chip-delay = <25>;
compatible = "mrvl,orion-nand";
compatible = "marvell,orion-nand";
reg = <0xf4000000 0x400>;
partition@0 {

27
Documentation/devicetree/bindings/net/cavium-mdio.txt Normal file
View File

@ -0,0 +1,27 @@
* System Management Interface (SMI) / MDIO
Properties:
- compatible: "cavium,octeon-3860-mdio"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the MDIO bus controller register bank.
- #address-cells: Must be <1>.
- #size-cells: Must be <0>. MDIO addresses have no size component.
Typically an MDIO bus might have several children.
Example:
mdio@1180000001800 {
compatible = "cavium,octeon-3860-mdio";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x11800 0x00001800 0x0 0x40>;
ethernet-phy@0 {
...
reg = <0>;
};
};

39
Documentation/devicetree/bindings/net/cavium-mix.txt Normal file
View File

@ -0,0 +1,39 @@
* MIX Ethernet controller.
Properties:
- compatible: "cavium,octeon-5750-mix"
Compatibility with all cn5XXX and cn6XXX SOCs populated with MIX
devices.
- reg: The base addresses of four separate register banks. The first
bank contains the MIX registers. The second bank the corresponding
AGL registers. The third bank are the AGL registers shared by all
MIX devices present. The fourth bank is the AGL_PRT_CTL shared by
all MIX devices present.
- cell-index: A single cell specifying which portion of the shared
register banks corresponds to this MIX device.
- interrupts: Two interrupt specifiers. The first is the MIX
interrupt routing and the second the routing for the AGL interrupts.
- mac-address: Optional, the MAC address to assign to the device.
- local-mac-address: Optional, the MAC address to assign to the device
if mac-address is not specified.
- phy-handle: Optional, a phandle for the PHY device connected to this device.
Example:
ethernet@1070000100800 {
compatible = "cavium,octeon-5750-mix";
reg = <0x10700 0x00100800 0x0 0x100>, /* MIX */
<0x11800 0xE0000800 0x0 0x300>, /* AGL */
<0x11800 0xE0000400 0x0 0x400>, /* AGL_SHARED */
<0x11800 0xE0002008 0x0 0x8>; /* AGL_PRT_CTL */
cell-index = <1>;
interrupts = <1 18>, < 1 46>;
local-mac-address = [ 00 0f b7 10 63 54 ];
phy-handle = <&phy1>;
};

98
Documentation/devicetree/bindings/net/cavium-pip.txt Normal file
View File

@ -0,0 +1,98 @@
* PIP Ethernet nexus.
The PIP Ethernet nexus can control several data packet input/output
devices. The devices have a two level grouping scheme. There may be
several interfaces, and each interface may have several ports. These
ports might be an individual Ethernet PHY.
Properties for the PIP nexus:
- compatible: "cavium,octeon-3860-pip"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the PIP's register bank.
- #address-cells: Must be <1>.
- #size-cells: Must be <0>.
Properties for PIP interfaces which is a child the PIP nexus:
- compatible: "cavium,octeon-3860-pip-interface"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The interface number.
- #address-cells: Must be <1>.
- #size-cells: Must be <0>.
Properties for PIP port which is a child the PIP interface:
- compatible: "cavium,octeon-3860-pip-port"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The port number within the interface group.
- mac-address: Optional, the MAC address to assign to the device.
- local-mac-address: Optional, the MAC address to assign to the device
if mac-address is not specified.
- phy-handle: Optional, a phandle for the PHY device connected to this device.
Example:
pip@11800a0000000 {
compatible = "cavium,octeon-3860-pip";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x11800 0xa0000000 0x0 0x2000>;
interface@0 {
compatible = "cavium,octeon-3860-pip-interface";
#address-cells = <1>;
#size-cells = <0>;
reg = <0>; /* interface */
ethernet@0 {
compatible = "cavium,octeon-3860-pip-port";
reg = <0x0>; /* Port */
local-mac-address = [ 00 0f b7 10 63 60 ];
phy-handle = <&phy2>;
};
ethernet@1 {
compatible = "cavium,octeon-3860-pip-port";
reg = <0x1>; /* Port */
local-mac-address = [ 00 0f b7 10 63 61 ];
phy-handle = <&phy3>;
};
ethernet@2 {
compatible = "cavium,octeon-3860-pip-port";
reg = <0x2>; /* Port */
local-mac-address = [ 00 0f b7 10 63 62 ];
phy-handle = <&phy4>;
};
ethernet@3 {
compatible = "cavium,octeon-3860-pip-port";
reg = <0x3>; /* Port */
local-mac-address = [ 00 0f b7 10 63 63 ];
phy-handle = <&phy5>;
};
};
interface@1 {
compatible = "cavium,octeon-3860-pip-interface";
#address-cells = <1>;
#size-cells = <0>;
reg = <1>; /* interface */
ethernet@0 {
compatible = "cavium,octeon-3860-pip-port";
reg = <0x0>; /* Port */
local-mac-address = [ 00 0f b7 10 63 64 ];
phy-handle = <&phy6>;
};
};
};

12
Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt Normal file
View File

@ -0,0 +1,12 @@
LPC32XX PWM controller
Required properties:
- compatible: should be "nxp,lpc3220-pwm"
- reg: physical base address and length of the controller's registers
Examples:
pwm@0x4005C000 {
compatible = "nxp,lpc3220-pwm";
reg = <0x4005C000 0x8>;
};

17
Documentation/devicetree/bindings/pwm/mxs-pwm.txt Normal file
View File

@ -0,0 +1,17 @@
Freescale MXS PWM controller
Required properties:
- compatible: should be "fsl,imx23-pwm"
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. The first cell specifies the per-chip index
of the PWM to use and the second cell is the duty cycle in nanoseconds.
- fsl,pwm-number: the number of PWM devices
Example:
pwm: pwm@80064000 {
compatible = "fsl,imx28-pwm", "fsl,imx23-pwm";
reg = <0x80064000 2000>;
#pwm-cells = <2>;
fsl,pwm-number = <8>;
};

18
Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt Normal file
View File

@ -0,0 +1,18 @@
Tegra SoC PWFM controller
Required properties:
- compatible: should be one of:
- "nvidia,tegra20-pwm"
- "nvidia,tegra30-pwm"
- reg: physical base address and length of the controller's registers
- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
first cell specifies the per-chip index of the PWM to use and the second
cell is the duty cycle in nanoseconds.
Example:
pwm: pwm@7000a000 {
compatible = "nvidia,tegra20-pwm";
reg = <0x7000a000 0x100>;
#pwm-cells = <2>;
};

57
Documentation/devicetree/bindings/pwm/pwm.txt Normal file
View File

@ -0,0 +1,57 @@
Specifying PWM information for devices
======================================
1) PWM user nodes
-----------------
PWM users should specify a list of PWM devices that they want to use
with a property containing a 'pwm-list':
pwm-list ::= <single-pwm> [pwm-list]
single-pwm ::= <pwm-phandle> <pwm-specifier>
pwm-phandle : phandle to PWM controller node
pwm-specifier : array of #pwm-cells specifying the given PWM
(controller specific)
PWM properties should be named "pwms". The exact meaning of each pwms
property must be documented in the device tree binding for each device.
An optional property "pwm-names" may contain a list of strings to label
each of the PWM devices listed in the "pwms" property. If no "pwm-names"
property is given, the name of the user node will be used as fallback.
Drivers for devices that use more than a single PWM device can use the
"pwm-names" property to map the name of the PWM device requested by the
pwm_get() call to an index into the list given by the "pwms" property.
The following example could be used to describe a PWM-based backlight
device:
pwm: pwm {
#pwm-cells = <2>;
};
[...]
bl: backlight {
pwms = <&pwm 0 5000000>;
pwm-names = "backlight";
};
pwm-specifier typically encodes the chip-relative PWM number and the PWM
period in nanoseconds. Note that in the example above, specifying the
"pwm-names" is redundant because the name "backlight" would be used as
fallback anyway.
2) PWM controller nodes
-----------------------
PWM controller nodes must specify the number of cells used for the
specifier using the '#pwm-cells' property.
An example PWM controller might look like this:
pwm: pwm@7000a000 {
compatible = "nvidia,tegra20-pwm";
reg = <0x7000a000 0x100>;
#pwm-cells = <2>;
};

19
Documentation/devicetree/bindings/serial/cavium-uart.txt Normal file
View File

@ -0,0 +1,19 @@
* Universal Asynchronous Receiver/Transmitter (UART)
- compatible: "cavium,octeon-3860-uart"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the UART register bank.
- interrupts: A single interrupt specifier.
- current-speed: Optional, the current bit rate in bits per second.
Example:
uart1: serial@1180000000c00 {
compatible = "cavium,octeon-3860-uart","ns16550";
reg = <0x11800 0x00000c00 0x0 0x400>;
current-speed = <115200>;
interrupts = <0 35>;
};

19
Documentation/devicetree/bindings/spi/spi-orion.txt Normal file
View File

@ -0,0 +1,19 @@
Marvell Orion SPI device
Required properties:
- compatible : should be "marvell,orion-spi".
- reg : offset and length of the register set for the device
- cell-index : Which of multiple SPI controllers is this.
Optional properties:
- interrupts : Is currently not used.
Example:
spi@10600 {
compatible = "marvell,orion-spi";
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
reg = <0x10600 0x28>;
interrupts = <23>;
status = "disabled";
};

14
Documentation/devicetree/bindings/thermal/spear-thermal.txt Normal file
View File

@ -0,0 +1,14 @@
* SPEAr Thermal
Required properties:
- compatible : "st,thermal-spear1340"
- reg : Address range of the thermal registers
- st,thermal-flags: flags used to enable thermal sensor
Example:
thermal@fc000000 {
compatible = "st,thermal-spear1340";
reg = <0xfc000000 0x1000>;
st,thermal-flags = <0x7000>;
};

1
Documentation/devicetree/bindings/tty/serial/of-serial.txt
View File

@ -9,6 +9,7 @@ Required properties:
- "ns16750"
- "ns16850"
- "nvidia,tegra20-uart"
- "nxp,lpc3220-uart"
- "ibm,qpace-nwp-serial"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.

18
Documentation/devicetree/bindings/usb/ci13xxx-imx.txt Normal file
View File

@ -0,0 +1,18 @@
* Freescale i.MX ci13xxx usb controllers
Required properties:
- compatible: Should be "fsl,imx27-usb"
- reg: Should contain registers location and length
- interrupts: Should contain controller interrupt
Optional properties:
- fsl,usbphy: phandler of usb phy that connects to the only one port
- vbus-supply: regulator for vbus
Examples:
usb@02184000 { /* USB OTG */
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
reg = <0x02184000 0x200>;
interrupts = <0 43 0x04>;
fsl,usbphy = <&usbphy1>;
};

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

@ -0,0 +1,13 @@
* Freescale MXS USB Phy Device
Required properties:
- compatible: Should be "fsl,imx23-usbphy"
- reg: Should contain registers location and length
- interrupts: Should contain phy interrupt
Example:
usbphy1: usbphy@020c9000 {
compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
reg = <0x020c9000 0x1000>;
interrupts = <0 44 0x04>;
};

28
Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt Normal file
View File

@ -0,0 +1,28 @@
pwm-backlight bindings
Required properties:
- compatible: "pwm-backlight"
- pwms: OF device-tree PWM specification (see PWM binding[0])
- brightness-levels: Array of distinct brightness levels. Typically these
are in the range from 0 to 255, but any range starting at 0 will do.
The actual brightness level (PWM duty cycle) will be interpolated
from these values. 0 means a 0% duty cycle (darkest/off), while the
last value in the array represents a 100% duty cycle (brightest).
- default-brightness-level: the default brightness level (index into the
array defined by the "brightness-levels" property)
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
"pwms" property (see PWM binding[0])
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
Example:
backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 5000000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
};

1
Documentation/dontdiff
View File

@ -150,7 +150,6 @@ keywords.c
ksym.c*
ksym.h*
kxgettext
lkc_defs.h
lex.c
lex.*.c
linux

42
Documentation/dvb/get_dvb_firmware
View File

@ -29,7 +29,7 @@ use IO::Handle;
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5",
"drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137",
"drxk_pctv");
"drxk_pctv", "drxk_terratec_htc_stick", "sms1xxx_hcw");
# Check args
syntax() if (scalar(@ARGV) != 1);
@ -676,6 +676,24 @@ sub drxk_terratec_h5 {
"$fwfile"
}
sub drxk_terratec_htc_stick {
my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/";
my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe";
my $hash = "6722a2442a05423b781721fbc069ed5e";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
my $drvfile = "Cinergy HTC Stick/BDA Driver 5.09.1202.00/Windows 32 Bit/emOEM.sys";
my $fwfile = "dvb-usb-terratec-htc-stick-drxk.fw";
checkstandard();
wgetfile($zipfile, $url . $zipfile);
verify($zipfile, $hash);
unzip($zipfile, $tmpdir);
extract("$tmpdir/$drvfile", 0x4e5c0, 42692, "$fwfile");
"$fwfile"
}
sub it9135 {
my $sourcefile = "dvb-usb-it9135.zip";
my $url = "http://www.ite.com.tw/uploads/firmware/v3.6.0.0/$sourcefile";
@ -748,6 +766,28 @@ sub drxk_pctv {
"$fwfile";
}
sub sms1xxx_hcw {
my $url = "http://steventoth.net/linux/sms1xxx/";
my %files = (
'sms1xxx-hcw-55xxx-dvbt-01.fw' => "afb6f9fb9a71d64392e8564ef9577e5a",
'sms1xxx-hcw-55xxx-dvbt-02.fw' => "b44807098ba26e52cbedeadc052ba58f",
'sms1xxx-hcw-55xxx-isdbt-02.fw' => "dae934eeea85225acbd63ce6cfe1c9e4",
);
checkstandard();
my $allfiles;
foreach my $fwfile (keys %files) {
wgetfile($fwfile, "$url/$fwfile");
verify($fwfile, $files{$fwfile});
$allfiles .= " $fwfile";
}
$allfiles =~ s/^\s//;
$allfiles;
}
# ---------------------------------------------------------------
# Utilities

112
Documentation/edac.txt
View File

@ -232,116 +232,20 @@ EDAC control and attribute files.
In 'mcX' directories are EDAC control and attribute files for
this 'X' instance of the memory controllers:
Counter reset control file:
'reset_counters'
This write-only control file will zero all the statistical counters
for UE and CE errors. Zeroing the counters will also reset the timer
indicating how long since the last counter zero. This is useful
for computing errors/time. Since the counters are always reset at
driver initialization time, no module/kernel parameter is available.
RUN TIME: echo "anything" >/sys/devices/system/edac/mc/mc0/counter_reset
This resets the counters on memory controller 0
Seconds since last counter reset control file:
'seconds_since_reset'
This attribute file displays how many seconds have elapsed since the
last counter reset. This can be used with the error counters to
measure error rates.
Memory Controller name attribute file:
'mc_name'
This attribute file displays the type of memory controller
that is being utilized.
Total memory managed by this memory controller attribute file:
'size_mb'
This attribute file displays, in count of megabytes, of memory
that this instance of memory controller manages.
Total Uncorrectable Errors count attribute file:
'ue_count'
This attribute file displays the total count of uncorrectable
errors that have occurred on this memory controller. If panic_on_ue
is set this counter will not have a chance to increment,
since EDAC will panic the system.
Total UE count that had no information attribute fileY:
'ue_noinfo_count'
This attribute file displays the number of UEs that have occurred
with no information as to which DIMM slot is having errors.
Total Correctable Errors count attribute file:
'ce_count'
This attribute file displays the total count of correctable
errors that have occurred on this memory controller. This
count is very important to examine. CEs provide early
indications that a DIMM is beginning to fail. This count
field should be monitored for non-zero values and report
such information to the system administrator.
Total Correctable Errors count attribute file:
'ce_noinfo_count'
This attribute file displays the number of CEs that
have occurred wherewith no information as to which DIMM slot
is having errors. Memory is handicapped, but operational,
yet no information is available to indicate which slot
the failing memory is in. This count field should be also
be monitored for non-zero values.
Device Symlink:
'device'
Symlink to the memory controller device.
Sdram memory scrubbing rate:
'sdram_scrub_rate'
Read/Write attribute file that controls memory scrubbing. The scrubbing
rate is set by writing a minimum bandwidth in bytes/sec to the attribute
file. The rate will be translated to an internal value that gives at
least the specified rate.
Reading the file will return the actual scrubbing rate employed.
If configuration fails or memory scrubbing is not implemented, accessing
that attribute will fail.
this 'X' instance of the memory controllers.
For a description of the sysfs API, please see:
Documentation/ABI/testing/sysfs/devices-edac
============================================================================
'csrowX' DIRECTORIES
When CONFIG_EDAC_LEGACY_SYSFS is enabled, the sysfs will contain the
csrowX directories. As this API doesn't work properly for Rambus, FB-DIMMs
and modern Intel Memory Controllers, this is being deprecated in favor
of dimmX directories.
In the 'csrowX' directories are EDAC control and attribute files for
this 'X' instance of csrow:

27
Documentation/fault-injection/fault-injection.txt
View File

@ -240,3 +240,30 @@ trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT
echo "Injecting errors into the module $module... (interrupt to stop)"
sleep 1000000
Tool to run command with failslab or fail_page_alloc
----------------------------------------------------
In order to make it easier to accomplish the tasks mentioned above, we can use
tools/testing/fault-injection/failcmd.sh. Please run a command
"./tools/testing/fault-injection/failcmd.sh --help" for more information and
see the following examples.
Examples:
Run a command "make -C tools/testing/selftests/ run_tests" with injecting slab
allocation failure.
# ./tools/testing/fault-injection/failcmd.sh \
-- make -C tools/testing/selftests/ run_tests
Same as above except to specify 100 times failures at most instead of one time
at most by default.
# ./tools/testing/fault-injection/failcmd.sh --times=100 \
-- make -C tools/testing/selftests/ run_tests
Same as above except to inject page allocation failure instead of slab
allocation failure.
# env FAILCMD_TYPE=fail_page_alloc \
./tools/testing/fault-injection/failcmd.sh --times=100 \
-- make -C tools/testing/selftests/ run_tests

99
Documentation/fault-injection/notifier-error-inject.txt Normal file
View File

@ -0,0 +1,99 @@
Notifier error injection
========================
Notifier error injection provides the ability to inject artifical errors to
specified notifier chain callbacks. It is useful to test the error handling of
notifier call chain failures which is rarely executed. There are kernel
modules that can be used to test the following notifiers.
* CPU notifier
* PM notifier
* Memory hotplug notifier
* powerpc pSeries reconfig notifier
CPU notifier error injection module
-----------------------------------
This feature can be used to test the error handling of the CPU notifiers by
injecting artifical errors to CPU notifier chain callbacks.
If the notifier call chain should be failed with some events notified, write
the error code to debugfs interface
/sys/kernel/debug/notifier-error-inject/cpu/actions/<notifier event>/error
Possible CPU notifier events to be failed are:
* CPU_UP_PREPARE
* CPU_UP_PREPARE_FROZEN
* CPU_DOWN_PREPARE
* CPU_DOWN_PREPARE_FROZEN
Example1: Inject CPU offline error (-1 == -EPERM)
# cd /sys/kernel/debug/notifier-error-inject/cpu
# echo -1 > actions/CPU_DOWN_PREPARE/error
# echo 0 > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: Operation not permitted
Example2: inject CPU online error (-2 == -ENOENT)
# echo -2 > actions/CPU_UP_PREPARE/error
# echo 1 > /sys/devices/system/cpu/cpu1/online
bash: echo: write error: No such file or directory
PM notifier error injection module
----------------------------------
This feature is controlled through debugfs interface
/sys/kernel/debug/notifier-error-inject/pm/actions/<notifier event>/error
Possible PM notifier events to be failed are:
* PM_HIBERNATION_PREPARE
* PM_SUSPEND_PREPARE
* PM_RESTORE_PREPARE
Example: Inject PM suspend error (-12 = -ENOMEM)
# cd /sys/kernel/debug/notifier-error-inject/pm/
# echo -12 > actions/PM_SUSPEND_PREPARE/error
# echo mem > /sys/power/state
bash: echo: write error: Cannot allocate memory
Memory hotplug notifier error injection module
----------------------------------------------
This feature is controlled through debugfs interface
/sys/kernel/debug/notifier-error-inject/memory/actions/<notifier event>/error
Possible memory notifier events to be failed are:
* MEM_GOING_ONLINE
* MEM_GOING_OFFLINE
Example: Inject memory hotplug offline error (-12 == -ENOMEM)
# cd /sys/kernel/debug/notifier-error-inject/memory
# echo -12 > actions/MEM_GOING_OFFLINE/error
# echo offline > /sys/devices/system/memory/memoryXXX/state
bash: echo: write error: Cannot allocate memory
powerpc pSeries reconfig notifier error injection module
--------------------------------------------------------
This feature is controlled through debugfs interface
/sys/kernel/debug/notifier-error-inject/pSeries-reconfig/actions/<notifier event>/error
Possible pSeries reconfig notifier events to be failed are:
* PSERIES_RECONFIG_ADD
* PSERIES_RECONFIG_REMOVE
* PSERIES_DRCONF_MEM_ADD
* PSERIES_DRCONF_MEM_REMOVE
For more usage examples
-----------------------
There are tools/testing/selftests using the notifier error injection features
for CPU and memory notifiers.
* tools/testing/selftests/cpu-hotplug/on-off-test.sh
* tools/testing/selftests/memory-hotplug/on-off-test.sh
These scripts first do simple online and offline tests and then do fault
injection tests if notifier error injection module is available.

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

@ -13,6 +13,14 @@ Who: Jim Cromie <jim.cromie@gmail.com>, Jason Baron <jbaron@redhat.com>
---------------------------
What: /proc/sys/vm/nr_pdflush_threads
When: 2012
Why: Since pdflush is deprecated, the interface exported in /proc/sys/vm/
should be removed.
Who: Wanpeng Li <liwp@linux.vnet.ibm.com>
---------------------------
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
When: 2012
Why: This optional sub-feature of APM is of dubious reliability,
@ -70,20 +78,6 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com>
---------------------------
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy
sources in the kernel's current entropy model. To resolve this, every
input point to the kernel's entropy pool needs to better document the
type of entropy source it actually is. This will be replaced with
additional add_*_randomness functions in drivers/char/random.c
Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
---------------------------
What: The ieee80211_regdom module parameter
When: March 2010 / desktop catchup
@ -512,14 +506,6 @@ Who: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
----------------------------
What: kmap_atomic(page, km_type)
When: 3.5
Why: The old kmap_atomic() with two arguments is deprecated, we only
keep it for backward compatibility for few cycles and then drop it.
Who: Cong Wang <amwang@redhat.com>
----------------------------
What: get_robust_list syscall
When: 2013
Why: There appear to be no production users of the get_robust_list syscall,
@ -608,3 +594,35 @@ When: June 2013
Why: Unsupported/unmaintained/unused since 2.6
----------------------------
What: V4L2 selections API target rectangle and flags unification, the
following definitions will be removed: V4L2_SEL_TGT_CROP_ACTIVE,
V4L2_SEL_TGT_COMPOSE_ACTIVE, V4L2_SUBDEV_SEL_*, V4L2_SUBDEV_SEL_FLAG_*
in favor of common V4L2_SEL_TGT_* and V4L2_SEL_FLAG_* definitions.
For more details see include/linux/v4l2-common.h.
When: 3.8
Why: The regular V4L2 selections and the subdev selection API originally
defined distinct names for the target rectangles and flags - V4L2_SEL_*
and V4L2_SUBDEV_SEL_*. Although, it turned out that the meaning of these
target rectangles is virtually identical and the APIs were consolidated
to use single set of names - V4L2_SEL_*. This didn't involve any ABI
changes. Alias definitions were created for the original ones to avoid
any instabilities in the user space interface. After few cycles these
backward compatibility definitions will be removed.
Who: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
----------------------------
What: Using V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags
to indicate a V4L2 memory-to-memory device capability
When: 3.8
Why: New drivers should use new V4L2_CAP_VIDEO_M2M capability flag
to indicate a V4L2 video memory-to-memory (M2M) device and
applications can now identify a M2M video device by checking
for V4L2_CAP_VIDEO_M2M, with VIDIOC_QUERYCAP ioctl. Using ORed
V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags for M2M
devices is ambiguous and may lead, for example, to identifying
a M2M device as a video capture or output device.
Who: Sylwester Nawrocki <s.nawrocki@samsung.com>
----------------------------

13
Documentation/filesystems/Locking
View File

@ -206,6 +206,8 @@ prototypes:
int (*launder_page)(struct page *);
int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long);
int (*error_remove_page)(struct address_space *, struct page *);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
locking rules:
All except set_page_dirty and freepage may block
@ -229,6 +231,8 @@ migratepage: yes (both)
launder_page: yes
is_partially_uptodate: yes
error_remove_page: yes
swap_activate: no
swap_deactivate: no
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
may be called from the request handler (/dev/loop).
@ -330,6 +334,15 @@ cleaned, or an error value if not. Note that in order to prevent the page
getting mapped back in and redirtied, it needs to be kept locked
across the entire operation.
->swap_activate will be called with a non-zero argument on
files backing (non block device backed) swapfiles. A return value
of zero indicates success, in which case this file can be used for
backing swapspace. The swapspace operations will be proxied to the
address space operations.
->swap_deactivate() will be called in the sys_swapoff()
path after ->swap_activate() returned success.
----------------------- file_lock_operations ------------------------------
prototypes:
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);

12
Documentation/filesystems/vfs.txt
View File

@ -592,6 +592,8 @@ struct address_space_operations {
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
int (*error_remove_page) (struct mapping *mapping, struct page *page);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
};
writepage: called by the VM to write a dirty page to backing store.
@ -760,6 +762,16 @@ struct address_space_operations {
Setting this implies you deal with pages going away under you,
unless you have them locked or reference counts increased.
swap_activate: Called when swapon is used on a file to allocate
space if necessary and pin the block lookup information in
memory. A return value of zero indicates success,
in which case this file can be used to back swapspace. The
swapspace operations will be proxied to this address space's
->swap_{out,in} methods.
swap_deactivate: Called during swapoff on files where swap_activate
was successful.
The File Object
===============

54
Documentation/input/edt-ft5x06.txt Normal file
View File

@ -0,0 +1,54 @@
EDT ft5x06 based Polytouch devices
----------------------------------
The edt-ft5x06 driver is useful for the EDT "Polytouch" family of capacitive
touch screens. Note that it is *not* suitable for other devices based on the
focaltec ft5x06 devices, since they contain vendor-specific firmware. In
particular this driver is not suitable for the Nook tablet.
It has been tested with the following devices:
* EP0350M06
* EP0430M06
* EP0570M06
* EP0700M06
The driver allows configuration of the touch screen via a set of sysfs files:
/sys/class/input/eventX/device/device/threshold:
allows setting the "click"-threshold in the range from 20 to 80.
/sys/class/input/eventX/device/device/gain:
allows setting the sensitivity in the range from 0 to 31. Note that
lower values indicate higher sensitivity.
/sys/class/input/eventX/device/device/offset:
allows setting the edge compensation in the range from 0 to 31.
/sys/class/input/eventX/device/device/report_rate:
allows setting the report rate in the range from 3 to 14.
For debugging purposes the driver provides a few files in the debug
filesystem (if available in the kernel). In /sys/kernel/debug/edt_ft5x06
you'll find the following files:
num_x, num_y:
(readonly) contains the number of sensor fields in X- and
Y-direction.
mode:
allows switching the sensor between "factory mode" and "operation
mode" by writing "1" or "0" to it. In factory mode (1) it is
possible to get the raw data from the sensor. Note that in factory
mode regular events don't get delivered and the options described
above are unavailable.
raw_data:
contains num_x * num_y big endian 16 bit values describing the raw
values for each sensor field. Note that each read() call on this
files triggers a new readout. It is recommended to provide a buffer
big enough to contain num_x * num_y * 2 bytes.
Note that reading raw_data gives a I/O error when the device is not in factory
mode. The same happens when reading/writing to the parameter files when the
device is not in regular operation mode.

118
Documentation/input/multi-touch-protocol.txt
View File

@ -162,26 +162,48 @@ are divided into categories, to allow for partial implementation. The
minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
allows for multiple contacts to be tracked. If the device supports it, the
ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
of the contact area and approaching contact, respectively.
of the contact area and approaching tool, respectively.
The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
looking through a window at someone gently holding a finger against the
glass. You will see two regions, one inner region consisting of the part
of the finger actually touching the glass, and one outer region formed by
the perimeter of the finger. The diameter of the inner region is the
ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
against the glass. The inner region will increase, and in general, the
ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
unity, is related to the contact pressure. For pressure-based devices,
the perimeter of the finger. The center of the touching region (a) is
ABS_MT_POSITION_X/Y and the center of the approaching finger (b) is
ABS_MT_TOOL_X/Y. The touch diameter is ABS_MT_TOUCH_MAJOR and the finger
diameter is ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger
harder against the glass. The touch region will increase, and in general,
the ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller
than unity, is related to the contact pressure. For pressure-based devices,
ABS_MT_PRESSURE may be used to provide the pressure on the contact area
instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to
indicate the distance between the contact and the surface.
In addition to the MAJOR parameters, the oval shape of the contact can be
described by adding the MINOR parameters, such that MAJOR and MINOR are the
major and minor axis of an ellipse. Finally, the orientation of the oval
shape can be describe with the ORIENTATION parameter.
Linux MT Win8
__________ _______________________
/ \ | |
/ \ | |
/ ____ \ | |
/ / \ \ | |
\ \ a \ \ | a |
\ \____/ \ | |
\ \ | |
\ b \ | b |
\ \ | |
\ \ | |
\ \ | |
\ / | |
\ / | |
\ / | |
\__________/ |_______________________|
In addition to the MAJOR parameters, the oval shape of the touch and finger
regions can be described by adding the MINOR parameters, such that MAJOR
and MINOR are the major and minor axis of an ellipse. The orientation of
the touch ellipse can be described with the ORIENTATION parameter, and the
direction of the finger ellipse is given by the vector (a - b).
For type A devices, further specification of the touch shape is possible
via ABS_MT_BLOB_ID.
@ -224,7 +246,7 @@ tool. Omit if circular [4].
The above four values can be used to derive additional information about
the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates
the notion of pressure. The fingers of the hand and the palm all have
different characteristic widths [1].
different characteristic widths.
ABS_MT_PRESSURE
@ -240,17 +262,24 @@ the contact is hovering above the surface.
ABS_MT_ORIENTATION
The orientation of the ellipse. The value should describe a signed quarter
of a revolution clockwise around the touch center. The signed value range
is arbitrary, but zero should be returned for a finger aligned along the Y
axis of the surface, a negative value when finger is turned to the left, and
a positive value when finger turned to the right. When completely aligned with
the X axis, the range max should be returned. Orientation can be omitted
if the touching object is circular, or if the information is not available
in the kernel driver. Partial orientation support is possible if the device
can distinguish between the two axis, but not (uniquely) any values in
between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
[4].
The orientation of the touching ellipse. The value should describe a signed
quarter of a revolution clockwise around the touch center. The signed value
range is arbitrary, but zero should be returned for an ellipse aligned with
the Y axis of the surface, a negative value when the ellipse is turned to
the left, and a positive value when the ellipse is turned to the
right. When completely aligned with the X axis, the range max should be
returned.
Touch ellipsis are symmetrical by default. For devices capable of true 360
degree orientation, the reported orientation must exceed the range max to
indicate more than a quarter of a revolution. For an upside-down finger,
range max * 2 should be returned.
Orientation can be omitted if the touch area is circular, or if the
information is not available in the kernel driver. Partial orientation
support is possible if the device can distinguish between the two axis, but
not (uniquely) any values in between. In such cases, the range of
ABS_MT_ORIENTATION should be [0, 1] [4].
ABS_MT_POSITION_X
@ -260,6 +289,23 @@ ABS_MT_POSITION_Y
The surface Y coordinate of the center of the touching ellipse.
ABS_MT_TOOL_X
The surface X coordinate of the center of the approaching tool. Omit if
the device cannot distinguish between the intended touch point and the
tool itself.
ABS_MT_TOOL_Y
The surface Y coordinate of the center of the approaching tool. Omit if the
device cannot distinguish between the intended touch point and the tool
itself.
The four position values can be used to separate the position of the touch
from the position of the tool. If both positions are present, the major
tool axis points towards the touch point [1]. Otherwise, the tool axes are
aligned with the touch axes.
ABS_MT_TOOL_TYPE
The type of approaching tool. A lot of kernel drivers cannot distinguish
@ -305,6 +351,28 @@ The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that
the device can distinguish between a finger along the Y axis (0) and a
finger along the X axis (1).
For win8 devices with both T and C coordinates, the position mapping is
ABS_MT_POSITION_X := T_X
ABS_MT_POSITION_Y := T_Y
ABS_MT_TOOL_X := C_X
ABS_MT_TOOL_X := C_Y
Unfortunately, there is not enough information to specify both the touching
ellipse and the tool ellipse, so one has to resort to approximations. One
simple scheme, which is compatible with earlier usage, is:
ABS_MT_TOUCH_MAJOR := min(X, Y)
ABS_MT_TOUCH_MINOR := <not used>
ABS_MT_ORIENTATION := <not used>
ABS_MT_WIDTH_MAJOR := min(X, Y) + distance(T, C)
ABS_MT_WIDTH_MINOR := min(X, Y)
Rationale: We have no information about the orientation of the touching
ellipse, so approximate it with an inscribed circle instead. The tool
ellipse should align with the the vector (T - C), so the diameter must
increase with distance(T, C). Finally, assume that the touch diameter is
equal to the tool thickness, and we arrive at the formulas above.
Finger Tracking
---------------
@ -338,9 +406,7 @@ subsequent events of the same type refer to different fingers.
For example usage of the type A protocol, see the bcm5974 driver. For
example usage of the type B protocol, see the hid-egalax driver.
[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the
difference between the contact position and the approaching tool position
could be used to derive tilt.
[1] Also, the difference (TOOL_X - POSITION_X) can be used to model tilt.
[2] The list can of course be extended.
[3] The mtdev project: http://bitmath.org/code/mtdev/.
[4] See the section on event computation.

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

@ -88,6 +88,7 @@ Code Seq#(hex) Include File Comments
and kernel/power/user.c
'8' all SNP8023 advanced NIC card
<mailto:mcr@solidum.com>
';' 64-7F linux/vfio.h
'@' 00-0F linux/radeonfb.h conflict!
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
'A' 00-1F linux/apm_bios.h conflict!

2
Documentation/kernel-parameters.txt
View File

@ -526,7 +526,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
coherent_pool=nn[KMG] [ARM,KNL]
Sets the size of memory pool for coherent, atomic dma
allocations if Contiguous Memory Allocator (CMA) is used.
allocations, by default set to 256K.
code_bytes [X86] How many bytes of object code to print
in an oops report.

2
Documentation/leds/00-INDEX
View File

@ -6,3 +6,5 @@ leds-lp5521.txt
- notes on how to use the leds-lp5521 driver.
leds-lp5523.txt
- notes on how to use the leds-lp5523 driver.
leds-lm3556.txt
- notes on how to use the leds-lm3556 driver.

80
Documentation/leds/leds-blinkm.txt Normal file
View File

@ -0,0 +1,80 @@
The leds-blinkm driver supports the devices of the BlinkM family.
They are RGB-LED modules driven by a (AT)tiny microcontroller and
communicate through I2C. The default address of these modules is
0x09 but this can be changed through a command. By this you could
dasy-chain up to 127 BlinkMs on an I2C bus.
The device accepts RGB and HSB color values through separate commands.
Also you can store blinking sequences as "scripts" in
the controller and run them. Also fading is an option.
The interface this driver provides is 2-fold:
a) LED class interface for use with triggers
############################################
The registration follows the scheme:
blinkm-<i2c-bus-nr>-<i2c-device-nr>-<color>
$ ls -h /sys/class/leds/blinkm-6-*
/sys/class/leds/blinkm-6-9-blue:
brightness device max_brightness power subsystem trigger uevent
/sys/class/leds/blinkm-6-9-green:
brightness device max_brightness power subsystem trigger uevent
/sys/class/leds/blinkm-6-9-red:
brightness device max_brightness power subsystem trigger uevent
(same is /sys/bus/i2c/devices/6-0009/leds)
We can control the colors separated into red, green and blue and
assign triggers on each color.
E.g.:
$ cat blinkm-6-9-blue/brightness
05
$ echo 200 > blinkm-6-9-blue/brightness
$
$ modprobe ledtrig-heartbeat
$ echo heartbeat > blinkm-6-9-green/trigger
$
b) Sysfs group to control rgb, fade, hsb, scripts ...
#####################################################
This extended interface is available as folder blinkm
in the sysfs folder of the I2C device.
E.g. below /sys/bus/i2c/devices/6-0009/blinkm
$ ls -h /sys/bus/i2c/devices/6-0009/blinkm/
blue green red test
Currently supported is just setting red, green, blue
and a test sequence.
E.g.:
$ cat *
00
00
00
#Write into test to start test sequence!#
$ echo 1 > test
$
$ echo 255 > red
$
as of 6/2012
dl9pf <at> gmx <dot> de

85
Documentation/leds/leds-lm3556.txt Normal file
View File

@ -0,0 +1,85 @@
Kernel driver for lm3556
========================
*Texas Instrument:
1.5 A Synchronous Boost LED Flash Driver w/ High-Side Current Source
* Datasheet: http://www.national.com/ds/LM/LM3556.pdf
Authors:
Daniel Jeong
Contact:Daniel Jeong(daniel.jeong-at-ti.com, gshark.jeong-at-gmail.com)
Description
-----------
There are 3 functions in LM3556, Flash, Torch and Indicator.
FLASH MODE
In Flash Mode, the LED current source(LED) provides 16 target current levels
from 93.75 mA to 1500 mA.The Flash currents are adjusted via the CURRENT
CONTROL REGISTER(0x09).Flash mode is activated by the ENABLE REGISTER(0x0A),
or by pulling the STROBE pin HIGH.
LM3556 Flash can be controlled through sys/class/leds/flash/brightness file
* if STROBE pin is enabled, below example control brightness only, and
ON / OFF will be controlled by STROBE pin.
Flash Example:
OFF : #echo 0 > sys/class/leds/flash/brightness
93.75 mA: #echo 1 > sys/class/leds/flash/brightness
... .....
1500 mA: #echo 16 > sys/class/leds/flash/brightness
TORCH MODE
In Torch Mode, the current source(LED) is programmed via the CURRENT CONTROL
REGISTER(0x09).Torch Mode is activated by the ENABLE REGISTER(0x0A) or by the
hardware TORCH input.
LM3556 torch can be controlled through sys/class/leds/torch/brightness file.
* if TORCH pin is enabled, below example control brightness only,
and ON / OFF will be controlled by TORCH pin.
Torch Example:
OFF : #echo 0 > sys/class/leds/torch/brightness
46.88 mA: #echo 1 > sys/class/leds/torch/brightness
... .....
375 mA : #echo 8 > sys/class/leds/torch/brightness
INDICATOR MODE
Indicator pattern can be set through sys/class/leds/indicator/pattern file,
and 4 patterns are pre-defined in indicator_pattern array.
According to N-lank, Pulse time and N Period values, different pattern wiill
be generated.If you want new patterns for your own device, change
indicator_pattern array with your own values and INDIC_PATTERN_SIZE.
Please refer datasheet for more detail about N-Blank, Pulse time and N Period.
Indicator pattern example:
pattern 0: #echo 0 > sys/class/leds/indicator/pattern
....
pattern 3: #echo 3 > sys/class/leds/indicator/pattern
Indicator brightness can be controlled through
sys/class/leds/indicator/brightness file.
Example:
OFF : #echo 0 > sys/class/leds/indicator/brightness
5.86 mA : #echo 1 > sys/class/leds/indicator/brightness
........
46.875mA : #echo 8 > sys/class/leds/indicator/brightness
Notes
-----
Driver expects it is registered using the i2c_board_info mechanism.
To register the chip at address 0x63 on specific adapter, set the platform data
according to include/linux/platform_data/leds-lm3556.h, set the i2c board info
Example:
static struct i2c_board_info __initdata board_i2c_ch4[] = {
{
I2C_BOARD_INFO(LM3556_NAME, 0x63),
.platform_data = &lm3556_pdata,
},
};
and register it in the platform init function
Example:
board_register_i2c_bus(4, 400,
board_i2c_ch4, ARRAY_SIZE(board_i2c_ch4));

59
Documentation/leds/ledtrig-oneshot.txt Normal file
View File

@ -0,0 +1,59 @@
One-shot LED Trigger
====================
This is a LED trigger useful for signaling the user of an event where there are
no clear trap points to put standard led-on and led-off settings. Using this
trigger, the application needs only to signal the trigger when an event has
happened, than the trigger turns the LED on and than keeps it off for a
specified amount of time.
This trigger is meant to be usable both for sporadic and dense events. In the
first case, the trigger produces a clear single controlled blink for each
event, while in the latter it keeps blinking at constant rate, as to signal
that the events are arriving continuously.
A one-shot LED only stays in a constant state when there are no events. An
additional "invert" property specifies if the LED has to stay off (normal) or
on (inverted) when not rearmed.
The trigger can be activated from user space on led class devices as shown
below:
echo oneshot > trigger
This adds the following sysfs attributes to the LED:
delay_on - specifies for how many milliseconds the LED has to stay at
LED_FULL brightness after it has been armed.
Default to 100 ms.
delay_off - specifies for how many milliseconds the LED has to stay at
LED_OFF brightness after it has been armed.
Default to 100 ms.
invert - reverse the blink logic. If set to 0 (default) blink on for delay_on
ms, then blink off for delay_off ms, leaving the LED normally off. If
set to 1, blink off for delay_off ms, then blink on for delay_on ms,
leaving the LED normally on.
Setting this value also immediately change the LED state.
shot - write any non-empty string to signal an events, this starts a blink
sequence if not already running.
Example use-case: network devices, initialization:
echo oneshot > trigger # set trigger for this led
echo 33 > delay_on # blink at 1 / (33 + 33) Hz on continuous traffic
echo 33 > delay_off
interface goes up:
echo 1 > invert # set led as normally-on, turn the led on
packet received/transmitted:
echo 1 > shot # led starts blinking, ignored if already blinking
interface goes down
echo 0 > invert # set led as normally-off, turn the led off

14
Documentation/misc-devices/mei/mei.txt
View File

@ -50,25 +50,25 @@ Intel MEI Driver
The driver exposes a misc device called /dev/mei.
An application maintains communication with an Intel ME feature while
/dev/mei is open. The binding to a specific features is performed by calling
/dev/mei is open. The binding to a specific feature is performed by calling
MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID.
The number of instances of an Intel ME feature that can be opened
at the same time depends on the Intel ME feature, but most of the
features allow only a single instance.
The Intel AMT Host Interface (Intel AMTHI) feature supports multiple
simultaneous user applications. Therefore, the Intel MEI driver handles
this internally by maintaining request queues for the applications.
simultaneous user connected applications. The Intel MEI driver
handles this internally by maintaining request queues for the applications.
The driver is oblivious to data that is passed between firmware feature
The driver is transparent to data that are passed between firmware feature
and host application.
Because some of the Intel ME features can change the system
configuration, the driver by default allows only a privileged
user to access it.
A code snippet for an application communicating with
Intel AMTHI client:
A code snippet for an application communicating with Intel AMTHI client:
struct mei_connect_client_data data;
fd = open(MEI_DEVICE);
@ -185,7 +185,7 @@ The Intel AMT Watchdog is composed of two parts:
2) Intel MEI driver - connects to the watchdog feature, configures the
watchdog and sends the heartbeats.
The Intel MEI driver uses the kernel watchdog to configure the Intel AMT
The Intel MEI driver uses the kernel watchdog API to configure the Intel AMT
Watchdog and to send heartbeats to it. The default timeout of the
watchdog is 120 seconds.

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

@ -48,12 +48,6 @@ min_adv_mss - INTEGER
The advertised MSS depends on the first hop route MTU, but will
never be lower than this setting.
rt_cache_rebuild_count - INTEGER
The per net-namespace route cache emergency rebuild threshold.
Any net-namespace having its route cache rebuilt due to
a hash bucket chain being too long more than this many times
will have its route caching disabled
IP Fragmentation:
ipfrag_high_thresh - INTEGER

10
Documentation/power/power_supply_class.txt
View File

@ -112,14 +112,24 @@ CHARGE_COUNTER - the current charge counter (in µAh). This could easily
be negative; there is no empty or full value. It is only useful for
relative, time-based measurements.
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
CAPACITY - capacity in percents.
CAPACITY_ALERT_MIN - minimum capacity alert value in percents.
CAPACITY_ALERT_MAX - maximum capacity alert value in percents.
CAPACITY_LEVEL - capacity level. This corresponds to
POWER_SUPPLY_CAPACITY_LEVEL_*.
TEMP - temperature of the power supply.
TEMP_ALERT_MIN - minimum battery temperature alert value in milli centigrade.
TEMP_ALERT_MAX - maximum battery temperature alert value in milli centigrade.
TEMP_AMBIENT - ambient temperature.
TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert value in milli centigrade.
TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert value in milli centigrade.
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
while battery powers a load)

15
Documentation/printk-formats.txt
View File

@ -53,9 +53,20 @@ Struct Resources:
For printing struct resources. The 'R' and 'r' specifiers result in a
printed resource with ('R') or without ('r') a decoded flags member.
Raw buffer as a hex string:
%*ph 00 01 02 ... 3f
%*phC 00:01:02: ... :3f
%*phD 00-01-02- ... -3f
%*phN 000102 ... 3f
For printing a small buffers (up to 64 bytes long) as a hex string with
certain separator. For the larger buffers consider to use
print_hex_dump().
MAC/FDDI addresses:
%pM 00:01:02:03:04:05
%pMR 05:04:03:02:01:00
%pMF 00-01-02-03-04-05
%pm 000102030405
@ -67,6 +78,10 @@ MAC/FDDI addresses:
the 'M' specifier to use dash ('-') separators instead of the default
separator.
For Bluetooth addresses the 'R' specifier shall be used after the 'M'
specifier to use reversed byte order suitable for visual interpretation
of Bluetooth addresses which are in the little endian order.
IPv4 addresses:
%pI4 1.2.3.4

76
Documentation/pwm.txt Normal file
View File

@ -0,0 +1,76 @@
Pulse Width Modulation (PWM) interface
This provides an overview about the Linux PWM interface
PWMs are commonly used for controlling LEDs, fans or vibrators in
cell phones. PWMs with a fixed purpose have no need implementing
the Linux PWM API (although they could). However, PWMs are often
found as discrete devices on SoCs which have no fixed purpose. It's
up to the board designer to connect them to LEDs or fans. To provide
this kind of flexibility the generic PWM API exists.
Identifying PWMs
----------------
Users of the legacy PWM API use unique IDs to refer to PWM devices.
Instead of referring to a PWM device via its unique ID, board setup code
should instead register a static mapping that can be used to match PWM
consumers to providers, as given in the following example:
static struct pwm_lookup board_pwm_lookup[] = {
PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
};
static void __init board_init(void)
{
...
pwm_add_table(board_pwm_lookup, ARRAY_SIZE(board_pwm_lookup));
...
}
Using PWMs
----------
Legacy users can request a PWM device using pwm_request() and free it
after usage with pwm_free().
New users should use the pwm_get() function and pass to it the consumer
device or a consumer name. pwm_put() is used to free the PWM device.
After being requested a PWM has to be configured using:
int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
Implementing a PWM driver
-------------------------
Currently there are two ways to implement pwm drivers. Traditionally
there only has been the barebone API meaning that each driver has
to implement the pwm_*() functions itself. This means that it's impossible
to have multiple PWM drivers in the system. For this reason it's mandatory
for new drivers to use the generic PWM framework.
A new PWM controller/chip can be added using pwmchip_add() and removed
again with pwmchip_remove(). pwmchip_add() takes a filled in struct
pwm_chip as argument which provides a description of the PWM chip, the
number of PWM devices provider by the chip and the chip-specific
implementation of the supported PWM operations to the framework.
Locking
-------
The PWM core list manipulations are protected by a mutex, so pwm_request()
and pwm_free() may not be called from an atomic context. Currently the
PWM core does not enforce any locking to pwm_enable(), pwm_disable() and
pwm_config(), so the calling context is currently driver specific. This
is an issue derived from the former barebone API and should be fixed soon.
Helpers
-------
Currently a PWM can only be configured with period_ns and duty_ns. For several
use cases freq_hz and duty_percent might be better. Instead of calculating
this in your driver please consider adding appropriate helpers to the framework.

39
Documentation/ramoops.txt
View File

@ -40,6 +40,12 @@ corrupt, but usually it is restorable.
Setting the ramoops parameters can be done in 2 different manners:
1. Use the module parameters (which have the names of the variables described
as before).
For quick debugging, you can also reserve parts of memory during boot
and then use the reserved memory for ramoops. For example, assuming a machine
with > 128 MB of memory, the following kernel command line will tell the
kernel to use only the first 128 MB of memory, and place ECC-protected ramoops
region at 128 MB boundary:
"mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1"
2. Use a platform device and set the platform data. The parameters can then
be set through that platform data. An example of doing that is:
@ -70,6 +76,14 @@ if (ret) {
return ret;
}
You can specify either RAM memory or peripheral devices' memory. However, when
specifying RAM, be sure to reserve the memory by issuing memblock_reserve()
very early in the architecture code, e.g.:
#include <linux/memblock.h>
memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size);
3. Dump format
The data dump begins with a header, currently defined as "====" followed by a
@ -80,3 +94,28 @@ timestamp and a new line. The dump then continues with the actual data.
The dump data can be read from the pstore filesystem. The format for these
files is "dmesg-ramoops-N", where N is the record number in memory. To delete
a stored record from RAM, simply unlink the respective pstore file.
5. Persistent function tracing
Persistent function tracing might be useful for debugging software or hardware
related hangs. The functions call chain log is stored in a "ftrace-ramoops"
file. Here is an example of usage:
# mount -t debugfs debugfs /sys/kernel/debug/
# cd /sys/kernel/debug/tracing
# echo function > current_tracer
# echo 1 > options/func_pstore
# reboot -f
[...]
# mount -t pstore pstore /mnt/
# tail /mnt/ftrace-ramoops
0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0
0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0
0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90
0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90
0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40
0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0
0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0
0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0
0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40
0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20

58
Documentation/remoteproc.txt
View File

@ -36,8 +36,7 @@ cost.
Note: to use this function you should already have a valid rproc
handle. There are several ways to achieve that cleanly (devres, pdata,
the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we
might also consider using dev_archdata for this). See also
rproc_get_by_name() below.
might also consider using dev_archdata for this).
void rproc_shutdown(struct rproc *rproc)
- Power off a remote processor (previously booted with rproc_boot()).
@ -51,30 +50,6 @@ cost.
which means that the @rproc handle stays valid even after
rproc_shutdown() returns, and users can still use it with a subsequent
rproc_boot(), if needed.
- don't call rproc_shutdown() to unroll rproc_get_by_name(), exactly
because rproc_shutdown() _does not_ decrement the refcount of @rproc.
To decrement the refcount of @rproc, use rproc_put() (but _only_ if
you acquired @rproc using rproc_get_by_name()).
struct rproc *rproc_get_by_name(const char *name)
- Find an rproc handle using the remote processor's name, and then
boot it. If it's already powered on, then just immediately return
(successfully). Returns the rproc handle on success, and NULL on failure.
This function increments the remote processor's refcount, so always
use rproc_put() to decrement it back once rproc isn't needed anymore.
Note: currently rproc_get_by_name() and rproc_put() are not used anymore
by the rpmsg bus and its drivers. We need to scrutinize the use cases
that still need them, and see if we can migrate them to use the non
name-based boot/shutdown interface.
void rproc_put(struct rproc *rproc)
- Decrement @rproc's power refcount and shut it down if it reaches zero
(essentially by just calling rproc_shutdown), and then decrement @rproc's
validity refcount too.
After this function returns, @rproc may _not_ be used anymore, and its
handle should be considered invalid.
This function should be called _iff_ the @rproc handle was grabbed by
calling rproc_get_by_name().
3. Typical usage
@ -115,21 +90,21 @@ int dummy_rproc_example(struct rproc *my_rproc)
This function should be used by rproc implementations during
initialization of the remote processor.
After creating an rproc handle using this function, and when ready,
implementations should then call rproc_register() to complete
implementations should then call rproc_add() to complete
the registration of the remote processor.
On success, the new rproc is returned, and on failure, NULL.
Note: _never_ directly deallocate @rproc, even if it was not registered
yet. Instead, if you just need to unroll rproc_alloc(), use rproc_free().
yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
void rproc_free(struct rproc *rproc)
void rproc_put(struct rproc *rproc)
- Free an rproc handle that was allocated by rproc_alloc.
This function should _only_ be used if @rproc was only allocated,
but not registered yet.
If @rproc was already successfully registered (by calling
rproc_register()), then use rproc_unregister() instead.
This function essentially unrolls rproc_alloc(), by decrementing the
rproc's refcount. It doesn't directly free rproc; that would happen
only if there are no other references to rproc and its refcount now
dropped to zero.
int rproc_register(struct rproc *rproc)
int rproc_add(struct rproc *rproc)
- Register @rproc with the remoteproc framework, after it has been
allocated with rproc_alloc().
This is called by the platform-specific rproc implementation, whenever
@ -142,20 +117,15 @@ int dummy_rproc_example(struct rproc *my_rproc)
of registering this remote processor, additional virtio drivers might get
probed.
int rproc_unregister(struct rproc *rproc)
- Unregister a remote processor, and decrement its refcount.
If its refcount drops to zero, then @rproc will be freed. If not,
it will be freed later once the last reference is dropped.
int rproc_del(struct rproc *rproc)
- Unroll rproc_add().
This function should be called when the platform specific rproc
implementation decides to remove the rproc device. it should
_only_ be called if a previous invocation of rproc_register()
_only_ be called if a previous invocation of rproc_add()
has completed successfully.
After rproc_unregister() returns, @rproc is _not_ valid anymore and
it shouldn't be used. More specifically, don't call rproc_free()
or try to directly free @rproc after rproc_unregister() returns;
none of these are needed, and calling them is a bug.
After rproc_del() returns, @rproc is still valid, and its
last refcount should be decremented by calling rproc_put().
Returns 0 on success and -EINVAL if @rproc isn't valid.

19
Documentation/stable_kernel_rules.txt
View File

@ -1,4 +1,4 @@
Everything you ever wanted to know about Linux 2.6 -stable releases.
Everything you ever wanted to know about Linux -stable releases.
Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:
@ -42,10 +42,10 @@ Procedure for submitting patches to the -stable tree:
cherry-picked than this can be specified in the following format in
the sign-off area:
Cc: <stable@vger.kernel.org> # .32.x: a1f84a3: sched: Check for idle
Cc: <stable@vger.kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@vger.kernel.org> # .32.x: fd21073: sched: Fix affinity logic
Cc: <stable@vger.kernel.org> # .32.x
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <stable@vger.kernel.org> # 3.3.x
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The tag sequence has the meaning of:
@ -79,6 +79,15 @@ Review cycle:
security kernel team, and not go through the normal review cycle.
Contact the kernel security team for more details on this procedure.
Trees:
- The queues of patches, for both completed versions and in progress
versions can be found at:
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git
- The finalized and tagged releases of all stable kernels can be found
in separate branches per version at:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git
Review committee:

18
Documentation/sysctl/fs.txt
View File

@ -163,16 +163,22 @@ This value can be used to query and set the core dump mode for setuid
or otherwise protected/tainted binaries. The modes are
0 - (default) - traditional behaviour. Any process which has changed
privilege levels or is execute only will not be dumped
privilege levels or is execute only will not be dumped.
1 - (debug) - all processes dump core when possible. The core dump is
owned by the current user and no security is applied. This is
intended for system debugging situations only. Ptrace is unchecked.
This is insecure as it allows regular users to examine the memory
contents of privileged processes.
2 - (suidsafe) - any binary which normally would not be dumped is dumped
readable by root only. This allows the end user to remove
such a dump but not access it directly. For security reasons
core dumps in this mode will not overwrite one another or
other files. This mode is appropriate when administrators are
attempting to debug problems in a normal environment.
anyway, but only if the "core_pattern" kernel sysctl is set to
either a pipe handler or a fully qualified path. (For more details
on this limitation, see CVE-2006-2451.) This mode is appropriate
when administrators are attempting to debug problems in a normal
environment, and either have a core dump pipe handler that knows
to treat privileged core dumps with care, or specific directory
defined for catching core dumps. If a core dump happens without
a pipe handler or fully qualifid path, a message will be emitted
to syslog warning about the lack of a correct setting.
==============================================================

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