mirror of
https://github.com/Fishwaldo/Star64_linux.git
synced 2025-03-16 12:14:06 +00:00
perf/core improvements and fixes:
. Fix include order for bison/flex-generated C files, from Ben Hutchings . Build fixes and documentation corrections from David Ahern . Group parsing support, from Jiri Olsa . UI/gtk refactorings and improvements from Namhyung Kim . NULL deref fix for perf script, from Namhyung Kim . Assorted cleanups from Robert Richter . Let O= makes handle relative paths, from Steven Rostedt Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAABAgAGBQJQMkGhAAoJENZQFvNTUqpAqjsQAJE5iD1LFogC8o/WjvRHz0TY Y0x+sR/XfW61KYpeq5g+UaKuFU3P44ijCoyks3y5sza97DkYgUwMpEHlLXFSM8Pp sNOapqY57s24nq3MLrhH1V9w+cSE+m2u/Gi5fGLCQekio9gkOBwYxNGk7vpKri/n LBRsMozBu/mZjMy20uWOb7Uk8xsAToh+TFaAtjyQ9Snn9nNJj49NUAp37uN888H/ ducMLq32HN5v/6Zd3q6IWdDWgZsHLkIa3R5FIs/GNe3Dih07gtYLmDol4ktPbTFm yoaWpP5wbtu/62EZlJwE393vMuoeqN/96394ZZQGFafhHVxN4+rcBhXbejBs0T2b wk/0CzntW8bbUAI/cl3SB9aui//FWOxcjG9aDQ7PsmHzPw1Q4VD0F9Mcod4p+dRX PsA9q/tST1eAiwzWYthDtj81U7iChINcXKhoZn2xn6+0+aMH+6FFNBmCH8MR5aCU BvrXhTJjvau/Ym/sILl4Tf4wfssTq49yMsn/YKCwLJ0hg0XlTObWfQRy2MOayXH9 NJvUE+9GSXoTEKhmr1AfTYEG9vObaXZyFwAI74xvPPwUYojCb4ZjEKmG0egW+VGk IJKFCaJZwwVsGau4aIbFAMP12/L8Qs/Ox91ddCJ0j5TIlSGMaqW5lbV1N1crzlTT a0GsN49NvhbFttBXrcNX =0a2X -----END PGP SIGNATURE----- Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: * Fix include order for bison/flex-generated C files, from Ben Hutchings * Build fixes and documentation corrections from David Ahern * Group parsing support, from Jiri Olsa * UI/gtk refactorings and improvements from Namhyung Kim * NULL deref fix for perf script, from Namhyung Kim * Assorted cleanups from Robert Richter * Let O= makes handle relative paths, from Steven Rostedt * perf script python fixes, from Feng Tang. * Improve 'perf lock' error message when the needed tracepoints are not present, from David Ahern. * Initial bash completion support, from Frederic Weisbecker * Allow building without libelf, from Namhyung Kim. * Support DWARF CFI based unwind to have callchains when %bp based unwinding is not possible, from Jiri Olsa. * Symbol resolution fixes, while fixing support PPC64 files with an .opt ELF section was the end goal, several fixes for code that handles all architectures and cleanups are included, from Cody Schafer. * Add a description for the JIT interface, from Andi Kleen. * Assorted fixes for Documentation and build in 32 bit, from Robert Richter * Add support for non-tracepoint events in perf script python, from Feng Tang * Cache the libtraceevent event_format associated to each evsel early, so that we avoid relookups, i.e. calling pevent_find_event repeatedly when processing tracepoint events. [ This is to reduce the surface contact with libtraceevents and make clear what is that the perf tools needs from that lib: so far parsing the common and per event fields. ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
commit
bcada3d4b8
7542 changed files with 455755 additions and 194393 deletions
|
@ -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.
|
|
@ -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
15
Documentation/ABI/stable/sysfs-driver-w1_ds28e04
Normal 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
|
|
@ -24,4 +24,4 @@ though.
|
|||
|
||||
(As of this writing, this ABI documentation as been confirmed for x86_64.
|
||||
The maintainers of the other vDSO-using architectures should confirm
|
||||
that it is correct for their architecture.)
|
||||
that it is correct for their architecture.)
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -96,4 +96,4 @@ Description:
|
|||
overhead, allocated for this disk. So, allocator space
|
||||
efficiency can be calculated using compr_data_size and this
|
||||
statistic.
|
||||
Unit: bytes
|
||||
Unit: bytes
|
||||
|
|
|
@ -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
37
Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523
Normal 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
21
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350
Normal 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
61
Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als
Normal 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.
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -40,4 +40,4 @@ Description: Controls the decimal places on the device.
|
|||
the value of 10 ** n. Assume this field has
|
||||
the value k and has 1 or more decimal places set,
|
||||
to set the mth place (where m is not already set),
|
||||
change this fields value to k + 10 ** m.
|
||||
change this fields value to k + 10 ** m.
|
||||
|
|
|
@ -53,4 +53,4 @@ Description:
|
|||
Documentation/ABI/stable/sysfs-class-backlight.
|
||||
It can be enabled by writing the value stored in
|
||||
/sys/class/backlight/<backlight>/max_brightness to
|
||||
/sys/class/backlight/<backlight>/brightness.
|
||||
/sys/class/backlight/<backlight>/brightness.
|
||||
|
|
140
Documentation/ABI/testing/sysfs-devices-edac
Normal file
140
Documentation/ABI/testing/sysfs-devices-edac
Normal 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).
|
|
@ -0,0 +1,44 @@
|
|||
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_alpha
|
||||
Date: May 2012
|
||||
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
Description:
|
||||
This file is only available on fb[0-9] devices corresponding
|
||||
to overlay planes.
|
||||
|
||||
Stores the alpha blending value for the overlay. Values range
|
||||
from 0 (transparent) to 255 (opaque). The value is ignored if
|
||||
the mode is not set to Alpha Blending.
|
||||
|
||||
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_mode
|
||||
Date: May 2012
|
||||
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
Description:
|
||||
This file is only available on fb[0-9] devices corresponding
|
||||
to overlay planes.
|
||||
|
||||
Selects the composition mode for the overlay. Possible values
|
||||
are
|
||||
|
||||
0 - Alpha Blending
|
||||
1 - ROP3
|
||||
|
||||
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_position
|
||||
Date: May 2012
|
||||
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
Description:
|
||||
This file is only available on fb[0-9] devices corresponding
|
||||
to overlay planes.
|
||||
|
||||
Stores the x,y overlay position on the display in pixels. The
|
||||
position format is `[0-9]+,[0-9]+'.
|
||||
|
||||
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_rop3
|
||||
Date: May 2012
|
||||
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
Description:
|
||||
This file is only available on fb[0-9] devices corresponding
|
||||
to overlay planes.
|
||||
|
||||
Stores the raster operation (ROP3) for the overlay. Values
|
||||
range from 0 to 255. The value is ignored if the mode is not
|
||||
set to ROP3.
|
20
Documentation/ABI/testing/sysfs-devices-system-xen_cpu
Normal file
20
Documentation/ABI/testing/sysfs-devices-system-xen_cpu
Normal file
|
@ -0,0 +1,20 @@
|
|||
What: /sys/devices/system/xen_cpu/
|
||||
Date: May 2012
|
||||
Contact: Liu, Jinsong <jinsong.liu@intel.com>
|
||||
Description:
|
||||
A collection of global/individual Xen physical cpu attributes
|
||||
|
||||
Individual physical cpu attributes are contained in
|
||||
subdirectories named by the Xen's logical cpu number, e.g.:
|
||||
/sys/devices/system/xen_cpu/xen_cpu#/
|
||||
|
||||
|
||||
What: /sys/devices/system/xen_cpu/xen_cpu#/online
|
||||
Date: May 2012
|
||||
Contact: Liu, Jinsong <jinsong.liu@intel.com>
|
||||
Description:
|
||||
Interface to online/offline Xen physical cpus
|
||||
|
||||
When running under Xen platform, it provide user interface
|
||||
to online/offline physical cpus, except cpu0 due to several
|
||||
logic restrictions and assumptions.
|
38
Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd
Normal file
38
Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd
Normal file
|
@ -0,0 +1,38 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_to_select
|
||||
Date: July 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be
|
||||
is being controlled by press_speed.
|
||||
Values are 0 or 1.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging
|
||||
Date: July 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled.
|
||||
Values are 0 or 1.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select
|
||||
Date: July 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html
|
||||
Values are 0 or 1.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right
|
||||
Date: July 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate
|
||||
a left or right mouse button click.
|
||||
Values are 0 or 1.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity
|
||||
Date: July 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: This file contains the trackpoint sensitivity.
|
||||
Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity).
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed
|
||||
Date: July 2011
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled.
|
||||
Values are decimal integers from 1 (slowest) to 255 (fastest).
|
||||
|
77
Documentation/ABI/testing/sysfs-driver-hid-roccat-savu
Normal file
77
Documentation/ABI/testing/sysfs-driver-hid-roccat-savu
Normal file
|
@ -0,0 +1,77 @@
|
|||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/buttons
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. buttons holds informations about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons to the mouse. The data has to be 47 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/control
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/general
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. profile holds informations like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 43 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/info
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
The data is 8 bytes long.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 500
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile numbers are included in written data.
|
||||
The data has to be 2083 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/profile
|
||||
Date: Mai 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. profile holds number of actual profile.
|
||||
This value is persistent, so its value determines the profile
|
||||
that's active when the mouse is powered on next time.
|
||||
When written, the mouse activates the set profile immediately.
|
||||
The data has to be 3 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/sensor
|
||||
Date: July 2012
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a Avago ADNS-3090 sensor.
|
||||
This file allows reading and writing of the mouse sensors registers.
|
||||
The data has to be 4 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
14
Documentation/ABI/testing/sysfs-kernel-iommu_groups
Normal file
14
Documentation/ABI/testing/sysfs-kernel-iommu_groups
Normal file
|
@ -0,0 +1,14 @@
|
|||
What: /sys/kernel/iommu_groups/
|
||||
Date: May 2012
|
||||
KernelVersion: v3.5
|
||||
Contact: Alex Williamson <alex.williamson@redhat.com>
|
||||
Description: /sys/kernel/iommu_groups/ contains a number of sub-
|
||||
directories, each representing an IOMMU group. The
|
||||
name of the sub-directory matches the iommu_group_id()
|
||||
for the group, which is an integer value. Within each
|
||||
subdirectory is another directory named "devices" with
|
||||
links to the sysfs devices contained in this group.
|
||||
The group directory also optionally contains a "name"
|
||||
file if the IOMMU driver has chosen to register a more
|
||||
common name for the group.
|
||||
Users:
|
|
@ -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.
|
||||
|
|
|
@ -231,3 +231,16 @@ Description:
|
|||
Reads from this file return a string consisting of the names of
|
||||
wakeup sources created with the help of /sys/power/wake_lock
|
||||
that are inactive at the moment, separated with spaces.
|
||||
|
||||
What: /sys/power/pm_print_times
|
||||
Date: May 2012
|
||||
Contact: Sameer Nanda <snanda@chromium.org>
|
||||
Description:
|
||||
The /sys/power/pm_print_times file allows user space to
|
||||
control whether the time taken by devices to suspend and
|
||||
resume is printed. These prints are useful for hunting down
|
||||
devices that take too long to suspend or resume.
|
||||
|
||||
Writing a "1" enables this printing while writing a "0"
|
||||
disables it. The default value is "0". Reading from this file
|
||||
will display the current value.
|
||||
|
|
|
@ -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!
|
||||
|
|
|
@ -404,7 +404,6 @@
|
|||
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k
|
||||
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv
|
||||
!Finclude/net/mac80211.h ieee80211_get_tkip_p2k
|
||||
!Finclude/net/mac80211.h ieee80211_key_removed
|
||||
</chapter>
|
||||
|
||||
<chapter id="powersave">
|
||||
|
|
|
@ -224,8 +224,8 @@ all your transactions.
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Then at umount time , in your put_super() (2.4) or write_super() (2.5)
|
||||
you can then call journal_destroy() to clean up your in-core journal object.
|
||||
Then at umount time , in your put_super() you can then call journal_destroy()
|
||||
to clean up your in-core journal object.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -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">
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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;, &sel);
|
||||
if (ret)
|
||||
exit(-1);
|
||||
sel.target = V4L2_SEL_TGT_CROP_ACTIVE;
|
||||
sel.target = V4L2_SEL_TGT_CROP;
|
||||
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &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;, &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
164
Documentation/DocBook/media/v4l/selections-common.xml
Normal 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 << 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 << 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 << 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>
|
|
@ -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;
|
||||
|
|
|
@ -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 v4l2_format</entry>
|
||||
<entry>&v4l2-format;</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Filled in by the application, preserved by the driver.</entry>
|
||||
</row>
|
||||
|
|
|
@ -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
179
Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
Normal 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>
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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 << 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 << 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 << 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>
|
||||
|
|
|
@ -93,6 +93,7 @@ Linux IRQ number into the hardware.
|
|||
Most drivers cannot use this mapping.
|
||||
|
||||
==== Legacy ====
|
||||
irq_domain_add_simple()
|
||||
irq_domain_add_legacy()
|
||||
irq_domain_add_legacy_isa()
|
||||
|
||||
|
@ -115,3 +116,7 @@ The legacy map should only be used if fixed IRQ mappings must be
|
|||
supported. For example, ISA controllers would use the legacy map for
|
||||
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
|
||||
numbers.
|
||||
|
||||
Most users of legacy mappings should use irq_domain_add_simple() which
|
||||
will use a legacy domain only if an IRQ range is supplied by the
|
||||
system and will otherwise use a linear domain mapping.
|
||||
|
|
|
@ -178,7 +178,7 @@ sadly that you are one too, and that while we can all bask in the secure
|
|||
knowledge that we're better than the average person (let's face it,
|
||||
nobody ever believes that they're average or below-average), we should
|
||||
also admit that we're not the sharpest knife around, and there will be
|
||||
other people that are less of an idiot that you are.
|
||||
other people that are less of an idiot than you are.
|
||||
|
||||
Some people react badly to smart people. Others take advantage of them.
|
||||
|
||||
|
|
|
@ -37,4 +37,4 @@ Maintainers
|
|||
Thanks to the many others who have also provided support.
|
||||
|
||||
|
||||
(c) 2005 Ben Dooks
|
||||
(c) 2005 Ben Dooks
|
||||
|
|
|
@ -53,4 +53,4 @@ Maintainers
|
|||
and to Simtec Electronics for allowing me time to work on this.
|
||||
|
||||
|
||||
(c) 2004 Ben Dooks
|
||||
(c) 2004 Ben Dooks
|
||||
|
|
|
@ -38,6 +38,13 @@ read or write requests. Note that the total allocated number may be twice
|
|||
this amount, since it applies only to reads or writes (not the accumulated
|
||||
sum).
|
||||
|
||||
To avoid priority inversion through request starvation, a request
|
||||
queue maintains a separate request pool per each cgroup when
|
||||
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
|
||||
per-block-cgroup request pool. IOW, if there are N block cgroups,
|
||||
each request queue may have upto N request pools, each independently
|
||||
regulated by nr_requests.
|
||||
|
||||
read_ahead_kb (RW)
|
||||
------------------
|
||||
Maximum number of kilobytes to read-ahead for filesystems on this block
|
||||
|
|
|
@ -370,15 +370,12 @@ To mount a cgroup hierarchy with just the cpuset and memory
|
|||
subsystems, type:
|
||||
# mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
|
||||
|
||||
To change the set of subsystems bound to a mounted hierarchy, just
|
||||
remount with different options:
|
||||
# mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1
|
||||
|
||||
Now memory is removed from the hierarchy and blkio is added.
|
||||
|
||||
Note this will add blkio to the hierarchy but won't remove memory or
|
||||
cpuset, because the new options are appended to the old ones:
|
||||
# mount -o remount,blkio /sys/fs/cgroup/rg1
|
||||
While remounting cgroups is currently supported, it is not recommend
|
||||
to use it. Remounting allows changing bound subsystems and
|
||||
release_agent. Rebinding is hardly useful as it only works when the
|
||||
hierarchy is empty and release_agent itself should be replaced with
|
||||
conventional fsnotify. The support for remounting will be removed in
|
||||
the future.
|
||||
|
||||
To Specify a hierarchy's release_agent:
|
||||
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
|
||||
|
@ -637,16 +634,6 @@ void exit(struct task_struct *task)
|
|||
|
||||
Called during task exit.
|
||||
|
||||
int populate(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after creation of a cgroup to allow a subsystem to populate
|
||||
the cgroup directory with file entries. The subsystem should make
|
||||
calls to cgroup_add_file() with objects of type cftype (see
|
||||
include/linux/cgroup.h for details). Note that although this
|
||||
method can return an error code, the error code is currently not
|
||||
always handled well.
|
||||
|
||||
void post_clone(struct cgroup *cgrp)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
|
@ -656,7 +643,7 @@ example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
|||
up.
|
||||
|
||||
void bind(struct cgroup *root)
|
||||
(cgroup_mutex and ss->hierarchy_mutex held by caller)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called when a cgroup subsystem is rebound to a different hierarchy
|
||||
and root cgroup. Currently this will only involve movement between
|
||||
|
|
45
Documentation/cgroups/hugetlb.txt
Normal file
45
Documentation/cgroups/hugetlb.txt
Normal 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
|
|
@ -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
|
||||
|
|
|
@ -69,9 +69,13 @@ static int cn_test_want_notify(void)
|
|||
return -ENOMEM;
|
||||
}
|
||||
|
||||
nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh));
|
||||
nlh = nlmsg_put(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh), 0);
|
||||
if (!nlh) {
|
||||
kfree_skb(skb);
|
||||
return -EMSGSIZE;
|
||||
}
|
||||
|
||||
msg = (struct cn_msg *)NLMSG_DATA(nlh);
|
||||
msg = nlmsg_data(nlh);
|
||||
|
||||
memset(msg, 0, size0);
|
||||
|
||||
|
@ -117,11 +121,6 @@ static int cn_test_want_notify(void)
|
|||
pr_info("request was sent: group=0x%x\n", ctl->group);
|
||||
|
||||
return 0;
|
||||
|
||||
nlmsg_failure:
|
||||
pr_err("failed to send %u.%u\n", msg->seq, msg->ack);
|
||||
kfree_skb(skb);
|
||||
return -EINVAL;
|
||||
}
|
||||
#endif
|
||||
|
||||
|
|
|
@ -27,6 +27,10 @@ The target is named "raid" and it accepts the following parameters:
|
|||
- rotating parity N (right-to-left) with data restart
|
||||
raid6_nc RAID6 N continue
|
||||
- rotating parity N (right-to-left) with data continuation
|
||||
raid10 Various RAID10 inspired algorithms chosen by additional params
|
||||
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
|
||||
- RAID1E: Integrated Adjacent Stripe Mirroring
|
||||
- and other similar RAID10 variants
|
||||
|
||||
Reference: Chapter 4 of
|
||||
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
|
||||
|
@ -59,6 +63,28 @@ The target is named "raid" and it accepts the following parameters:
|
|||
logical size of the array. The bitmap records the device
|
||||
synchronisation state for each region.
|
||||
|
||||
[raid10_copies <# copies>]
|
||||
[raid10_format near]
|
||||
These two options are used to alter the default layout of
|
||||
a RAID10 configuration. The number of copies is can be
|
||||
specified, but the default is 2. There are other variations
|
||||
to how the copies are laid down - the default and only current
|
||||
option is "near". Near copies are what most people think of
|
||||
with respect to mirroring. If these options are left
|
||||
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
|
||||
are given, then the layouts for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- ---------- --------------
|
||||
A1 A1 A1 A1 A2 A1 A1 A2 A2
|
||||
A2 A2 A2 A3 A3 A3 A3 A4 A4
|
||||
A3 A3 A4 A4 A5 A5 A5 A6 A6
|
||||
A4 A4 A5 A6 A6 A7 A7 A8 A8
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
The 2-device layout is equivalent 2-way RAID1. The 4-device
|
||||
layout is what a traditional RAID10 would look like. The
|
||||
3-device layout is what might be called a 'RAID1E - Integrated
|
||||
Adjacent Stripe Mirroring'.
|
||||
|
||||
<#raid_devs>: The number of devices composing the array.
|
||||
Each device consists of two entries. The first is the device
|
||||
containing the metadata (if any); the second is the one containing the
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -2416,6 +2416,8 @@ Your cooperation is appreciated.
|
|||
1 = /dev/raw/raw1 First raw I/O device
|
||||
2 = /dev/raw/raw2 Second raw I/O device
|
||||
...
|
||||
max minor number of raw device is set by kernel config
|
||||
MAX_RAW_DEVS or raw module parameter 'max_raw_devs'
|
||||
|
||||
163 char
|
||||
|
||||
|
|
23
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
Normal file
23
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
Normal file
|
@ -0,0 +1,23 @@
|
|||
Marvell Armada 370 and Armada XP Interrupt Controller
|
||||
-----------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "marvell,mpic"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
|
||||
The cell is the IRQ number
|
||||
- reg: Should contain PMIC registers location and length. First pair
|
||||
for the main interrupt registers, second pair for the per-CPU
|
||||
interrupt registers
|
||||
|
||||
Example:
|
||||
|
||||
mpic: interrupt-controller@d0020000 {
|
||||
compatible = "marvell,mpic";
|
||||
#interrupt-cells = <1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
interrupt-controller;
|
||||
reg = <0xd0020000 0x1000>,
|
||||
<0xd0021000 0x1000>;
|
||||
};
|
|
@ -0,0 +1,11 @@
|
|||
Marvell Armada 370 and Armada XP Global Timers
|
||||
----------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "marvell,armada-370-xp-timer"
|
||||
- interrupts: Should contain the list of Global Timer interrupts
|
||||
- reg: Should contain the base address of the Global Timer registers
|
||||
|
||||
Optional properties:
|
||||
- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
|
||||
Mhz fixed mode (available on Armada XP and not on Armada 370)
|
24
Documentation/devicetree/bindings/arm/armada-370-xp.txt
Normal file
24
Documentation/devicetree/bindings/arm/armada-370-xp.txt
Normal file
|
@ -0,0 +1,24 @@
|
|||
Marvell Armada 370 and Armada XP Platforms Device Tree Bindings
|
||||
---------------------------------------------------------------
|
||||
|
||||
Boards with a SoC of the Marvell Armada 370 and Armada XP families
|
||||
shall have the following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: must contain "marvell,armada-370-xp"
|
||||
|
||||
In addition, boards using the Marvell Armada 370 SoC shall have the
|
||||
following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: must contain "marvell,armada370"
|
||||
|
||||
In addition, boards using the Marvell Armada XP SoC shall have the
|
||||
following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: must contain "marvell,armadaxp"
|
||||
|
|
@ -4,7 +4,7 @@ Required properties:
|
|||
- compatible: Should be "atmel,<chip>-aic"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- interrupt-parent: For single AIC system, it is an empty property.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
|
||||
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||
The second cell is used to specify flags:
|
||||
bits[3:0] trigger type and level flags:
|
||||
|
@ -14,7 +14,10 @@ Required properties:
|
|||
8 = active low level-sensitive.
|
||||
Valid combinations are 1, 2, 3, 4, 8.
|
||||
Default flag for internal sources should be set to 4 (active high).
|
||||
The third cell is used to specify the irq priority from 0 (lowest) to 7
|
||||
(highest).
|
||||
- reg: Should contain AIC registers location and length
|
||||
- atmel,external-irqs: u32 array of external irqs.
|
||||
|
||||
Examples:
|
||||
/*
|
||||
|
@ -24,7 +27,7 @@ Examples:
|
|||
compatible = "atmel,at91rm9200-aic";
|
||||
interrupt-controller;
|
||||
interrupt-parent;
|
||||
#interrupt-cells = <2>;
|
||||
#interrupt-cells = <3>;
|
||||
reg = <0xfffff000 0x200>;
|
||||
};
|
||||
|
||||
|
@ -34,5 +37,5 @@ Examples:
|
|||
dma: dma-controller@ffffec00 {
|
||||
compatible = "atmel,at91sam9g45-dma";
|
||||
reg = <0xffffec00 0x200>;
|
||||
interrupts = <21 4>;
|
||||
interrupts = <21 4 5>;
|
||||
};
|
||||
|
|
15
Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt
Normal file
15
Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt
Normal 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
14
Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
Normal 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>;
|
||||
};
|
27
Documentation/devicetree/bindings/arm/davinci/cp-intc.txt
Normal file
27
Documentation/devicetree/bindings/arm/davinci/cp-intc.txt
Normal file
|
@ -0,0 +1,27 @@
|
|||
* TI Common Platform Interrupt Controller
|
||||
|
||||
Common Platform Interrupt Controller (cp_intc) is used on
|
||||
OMAP-L1x SoCs and can support several configurable number
|
||||
of interrupts.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be:
|
||||
"ti,cp-intc"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 1.
|
||||
|
||||
The cell contains the interrupt number in the range [0-128].
|
||||
- ti,intc-size: Number of interrupts handled by the interrupt controller.
|
||||
- reg: physical base address and size of the intc registers map.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@1 {
|
||||
compatible = "ti,cp-intc";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
ti,intc-size = <101>;
|
||||
reg = <0xfffee000 0x2000>;
|
||||
};
|
|
@ -38,3 +38,23 @@ Example:
|
|||
reg-names = "mux status", "mux mask";
|
||||
mrvl,intc-nr-irqs = <2>;
|
||||
};
|
||||
|
||||
* Marvell Orion Interrupt controller
|
||||
|
||||
Required properties
|
||||
- compatible : Should be "marvell,orion-intc".
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source. Supported value is <1>.
|
||||
- interrupt-controller : Declare this node to be an interrupt controller.
|
||||
- reg : Interrupt mask address. A list of 4 byte ranges, one per controller.
|
||||
One entry in the list represents 32 interrupts.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller {
|
||||
compatible = "marvell,orion-intc", "marvell,intc";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0xfed20204 0x04>,
|
||||
<0xfed20214 0x04>;
|
||||
};
|
||||
|
|
|
@ -0,0 +1,17 @@
|
|||
MVEBU System Controller
|
||||
-----------------------
|
||||
MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: one of:
|
||||
- "marvell,orion-system-controller"
|
||||
- "marvell,armada-370-xp-system-controller"
|
||||
- reg: Should contain system controller registers location and length.
|
||||
|
||||
Example:
|
||||
|
||||
system-controller@d0018200 {
|
||||
compatible = "marvell,armada-370-xp-system-controller";
|
||||
reg = <0xd0018200 0x500>;
|
||||
};
|
6
Documentation/devicetree/bindings/arm/olimex.txt
Normal file
6
Documentation/devicetree/bindings/arm/olimex.txt
Normal file
|
@ -0,0 +1,6 @@
|
|||
Olimex i.MX Platforms Device Tree Bindings
|
||||
------------------------------------------
|
||||
|
||||
i.MX23 Olinuxino Low Cost Board
|
||||
Required root node properties:
|
||||
- compatible = "olimex,imx23-olinuxino", "fsl,imx23";
|
|
@ -47,3 +47,9 @@ Boards:
|
|||
|
||||
- AM335X EVM : Software Developement Board for AM335x
|
||||
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
|
||||
|
||||
- AM335X Bone : Low cost community board
|
||||
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
|
||||
|
||||
- OMAP5 EVM : Evaluation Module
|
||||
compatible = "ti,omap5-evm", "ti,omap5"
|
||||
|
|
|
@ -13,11 +13,17 @@ Required properties:
|
|||
Optional properties:
|
||||
|
||||
- arm,primecell-periphid : Value to override the h/w value with
|
||||
- clocks : From common clock binding. First clock is phandle to clock for apb
|
||||
pclk. Additional clocks are optional and specific to those peripherals.
|
||||
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
|
||||
|
||||
Example:
|
||||
|
||||
serial@fff36000 {
|
||||
compatible = "arm,pl011", "arm,primecell";
|
||||
arm,primecell-periphid = <0x00341011>;
|
||||
clocks = <&pclk>;
|
||||
clock-names = "apb_pclk";
|
||||
|
||||
};
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ Child device nodes describe the memory settings for different configurations and
|
|||
|
||||
Example:
|
||||
|
||||
emc@7000f400 {
|
||||
memory-controller@7000f400 {
|
||||
#address-cells = < 1 >;
|
||||
#size-cells = < 0 >;
|
||||
compatible = "nvidia,tegra20-emc";
|
|
@ -8,7 +8,7 @@ Required properties:
|
|||
- interrupts : Should contain MC General interrupt.
|
||||
|
||||
Example:
|
||||
mc {
|
||||
memory-controller@0x7000f000 {
|
||||
compatible = "nvidia,tegra20-mc";
|
||||
reg = <0x7000f000 0x024
|
||||
0x7000f03c 0x3c4>;
|
||||
|
|
|
@ -8,7 +8,7 @@ Required properties:
|
|||
- interrupts : Should contain MC General interrupt.
|
||||
|
||||
Example:
|
||||
mc {
|
||||
memory-controller {
|
||||
compatible = "nvidia,tegra30-mc";
|
||||
reg = <0x7000f000 0x010
|
||||
0x7000f03c 0x1b4
|
||||
|
|
|
@ -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>;
|
||||
};
|
16
Documentation/devicetree/bindings/ata/marvell.txt
Normal file
16
Documentation/devicetree/bindings/ata/marvell.txt
Normal file
|
@ -0,0 +1,16 @@
|
|||
* Marvell Orion SATA
|
||||
|
||||
Required Properties:
|
||||
- compatibility : "marvell,orion-sata"
|
||||
- reg : Address range of controller
|
||||
- interrupts : Interrupt controller is using
|
||||
- nr-ports : Number of SATA ports in use.
|
||||
|
||||
Example:
|
||||
|
||||
sata@80000 {
|
||||
compatible = "marvell,orion-sata";
|
||||
reg = <0x80000 0x5000>;
|
||||
interrupts = <21>;
|
||||
nr-ports = <2>;
|
||||
}
|
17
Documentation/devicetree/bindings/clock/calxeda.txt
Normal file
17
Documentation/devicetree/bindings/clock/calxeda.txt
Normal file
|
@ -0,0 +1,17 @@
|
|||
Device Tree Clock bindings for Calxeda highbank platform
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"calxeda,hb-pll-clock" - for a PLL clock
|
||||
"calxeda,hb-a9periph-clock" - The A9 peripheral clock divided from the
|
||||
A9 clock.
|
||||
"calxeda,hb-a9bus-clock" - The A9 bus clock divided from the A9 clock.
|
||||
"calxeda,hb-emmc-clock" - Divided clock for MMC/SD controller.
|
||||
- reg : shall be the control register offset from SYSREGs base for the clock.
|
||||
- clocks : shall be the input parent clock phandle for the clock. This is
|
||||
either an oscillator or a pll output.
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
117
Documentation/devicetree/bindings/clock/clock-bindings.txt
Normal file
117
Documentation/devicetree/bindings/clock/clock-bindings.txt
Normal file
|
@ -0,0 +1,117 @@
|
|||
This binding is a work-in-progress, and are based on some experimental
|
||||
work by benh[1].
|
||||
|
||||
Sources of clock signal can be represented by any node in the device
|
||||
tree. Those nodes are designated as clock providers. Clock consumer
|
||||
nodes use a phandle and clock specifier pair to connect clock provider
|
||||
outputs to clock inputs. Similar to the gpio specifiers, a clock
|
||||
specifier is an array of one more more cells identifying the clock
|
||||
output on a device. The length of a clock specifier is defined by the
|
||||
value of a #clock-cells property in the clock provider node.
|
||||
|
||||
[1] http://patchwork.ozlabs.org/patch/31551/
|
||||
|
||||
==Clock providers==
|
||||
|
||||
Required properties:
|
||||
#clock-cells: Number of cells in a clock specifier; Typically 0 for nodes
|
||||
with a single clock output and 1 for nodes with multiple
|
||||
clock outputs.
|
||||
|
||||
Optional properties:
|
||||
clock-output-names: Recommended to be a list of strings of clock output signal
|
||||
names indexed by the first cell in the clock specifier.
|
||||
However, the meaning of clock-output-names is domain
|
||||
specific to the clock provider, and is only provided to
|
||||
encourage using the same meaning for the majority of clock
|
||||
providers. This format may not work for clock providers
|
||||
using a complex clock specifier format. In those cases it
|
||||
is recommended to omit this property and create a binding
|
||||
specific names property.
|
||||
|
||||
Clock consumer nodes must never directly reference
|
||||
the provider's clock-output-names property.
|
||||
|
||||
For example:
|
||||
|
||||
oscillator {
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "ckil", "ckih";
|
||||
};
|
||||
|
||||
- this node defines a device with two clock outputs, the first named
|
||||
"ckil" and the second named "ckih". Consumer nodes always reference
|
||||
clocks by index. The names should reflect the clock output signal
|
||||
names for the device.
|
||||
|
||||
==Clock consumers==
|
||||
|
||||
Required properties:
|
||||
clocks: List of phandle and clock specifier pairs, one pair
|
||||
for each clock input to the device. Note: if the
|
||||
clock provider specifies '0' for #clock-cells, then
|
||||
only the phandle portion of the pair will appear.
|
||||
|
||||
Optional properties:
|
||||
clock-names: List of clock input name strings sorted in the same
|
||||
order as the clocks property. Consumers drivers
|
||||
will use clock-names to match clock input names
|
||||
with clocks specifiers.
|
||||
clock-ranges: Empty property indicating that child nodes can inherit named
|
||||
clocks from this node. Useful for bus nodes to provide a
|
||||
clock to their children.
|
||||
|
||||
For example:
|
||||
|
||||
device {
|
||||
clocks = <&osc 1>, <&ref 0>;
|
||||
clock-names = "baud", "register";
|
||||
};
|
||||
|
||||
|
||||
This represents a device with two clock inputs, named "baud" and "register".
|
||||
The baud clock is connected to output 1 of the &osc device, and the register
|
||||
clock is connected to output 0 of the &ref.
|
||||
|
||||
==Example==
|
||||
|
||||
/* external oscillator */
|
||||
osc: oscillator {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <1>;
|
||||
clock-frequency = <32678>;
|
||||
clock-output-names = "osc";
|
||||
};
|
||||
|
||||
/* phase-locked-loop device, generates a higher frequency clock
|
||||
* from the external oscillator reference */
|
||||
pll: pll@4c000 {
|
||||
compatible = "vendor,some-pll-interface"
|
||||
#clock-cells = <1>;
|
||||
clocks = <&osc 0>;
|
||||
clock-names = "ref";
|
||||
reg = <0x4c000 0x1000>;
|
||||
clock-output-names = "pll", "pll-switched";
|
||||
};
|
||||
|
||||
/* UART, using the low frequency oscillator for the baud clock,
|
||||
* and the high frequency switched PLL output for register
|
||||
* clocking */
|
||||
uart@a000 {
|
||||
compatible = "fsl,imx-uart";
|
||||
reg = <0xa000 0x1000>;
|
||||
interrupts = <33>;
|
||||
clocks = <&osc 0>, <&pll 1>;
|
||||
clock-names = "baud", "register";
|
||||
};
|
||||
|
||||
This DT fragment defines three devices: an external oscillator to provide a
|
||||
low-frequency reference clock, a PLL device to generate a higher frequency
|
||||
clock signal, and a UART.
|
||||
|
||||
* The oscillator is fixed-frequency, and provides one clock output, named "osc".
|
||||
* The PLL is both a clock provider and a clock consumer. It uses the clock
|
||||
signal generated by the external oscillator, and provides two output signals
|
||||
("pll" and "pll-switched").
|
||||
* The UART has its baud clock connected the external oscillator and its
|
||||
register clock connected to the PLL clock (the "pll-switched" signal)
|
21
Documentation/devicetree/bindings/clock/fixed-clock.txt
Normal file
21
Documentation/devicetree/bindings/clock/fixed-clock.txt
Normal file
|
@ -0,0 +1,21 @@
|
|||
Binding for simple fixed-rate clock sources.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "fixed-clock".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clock-frequency : frequency of clock in Hz. Should be a single cell.
|
||||
|
||||
Optional properties:
|
||||
- gpios : From common gpio binding; gpio connection to clock enable pin.
|
||||
- clock-output-names : From common clock binding.
|
||||
|
||||
Example:
|
||||
clock {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <1000000000>;
|
||||
};
|
19
Documentation/devicetree/bindings/fb/mxsfb.txt
Normal file
19
Documentation/devicetree/bindings/fb/mxsfb.txt
Normal file
|
@ -0,0 +1,19 @@
|
|||
* Freescale MXS LCD Interface (LCDIF)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,<chip>-lcdif". Supported chips include
|
||||
imx23 and imx28.
|
||||
- reg: Address and length of the register set for lcdif
|
||||
- interrupts: Should contain lcdif interrupts
|
||||
|
||||
Optional properties:
|
||||
- panel-enable-gpios : Should specify the gpio for panel enable
|
||||
|
||||
Examples:
|
||||
|
||||
lcdif@80030000 {
|
||||
compatible = "fsl,imx28-lcdif";
|
||||
reg = <0x80030000 2000>;
|
||||
interrupts = <38 86>;
|
||||
panel-enable-gpios = <&gpio3 30 0>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -8,15 +8,25 @@ Required properties:
|
|||
by low 16 pins and the second one is for high 16 pins.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
the second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
- interrupt-controller: Marks the device node as an interrupt controller.
|
||||
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
|
||||
The second cell bits[3:0] is used to specify 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.
|
||||
|
||||
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;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
|
|
@ -13,8 +13,9 @@ Required properties for GPIO node:
|
|||
- interrupts : Should be the port interrupt shared by all 32 pins.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
the second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
- interrupt-controller: Marks the device node as an interrupt controller.
|
||||
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
|
||||
The second cell bits[3:0] is used to specify trigger type and level flags:
|
||||
|
|
|
@ -26,6 +26,6 @@ Example:
|
|||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
interrupt-controller;
|
||||
supports-sleepmode;
|
||||
st,supports-sleepmode;
|
||||
gpio-bank = <1>;
|
||||
};
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -55,4 +55,4 @@ run-control {
|
|||
gpios = <&mpc8572 7 0>;
|
||||
default-state = "on";
|
||||
};
|
||||
}
|
||||
};
|
||||
|
|
|
@ -27,3 +27,26 @@ Example:
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
||||
* Marvell Orion GPIO Controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "marvell,orion-gpio"
|
||||
- reg : Address and length of the register set for controller.
|
||||
- gpio-controller : So we know this is a gpio controller.
|
||||
- ngpio : How many gpios this controller has.
|
||||
- interrupts : Up to 4 Interrupts for the controller.
|
||||
|
||||
Optional properties:
|
||||
- mask-offset : For SMP Orions, offset for Nth CPU
|
||||
|
||||
Example:
|
||||
|
||||
gpio0: gpio@10100 {
|
||||
compatible = "marvell,orion-gpio";
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
reg = <0x10100 0x40>;
|
||||
ngpio = <32>;
|
||||
interrupts = <35>, <36>, <37>, <38>;
|
||||
};
|
||||
|
|
34
Documentation/devicetree/bindings/i2c/cavium-i2c.txt
Normal file
34
Documentation/devicetree/bindings/i2c/cavium-i2c.txt
Normal 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>;
|
||||
};
|
||||
};
|
|
@ -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
33
Documentation/devicetree/bindings/i2c/i2c-ocores.txt
Normal 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>;
|
||||
};
|
||||
};
|
|
@ -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
28
Documentation/devicetree/bindings/input/lpc32xx-key.txt
Normal 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
31
Documentation/devicetree/bindings/input/omap-keypad.txt
Normal 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;
|
||||
};
|
|
@ -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>;
|
||||
};
|
||||
};
|
|
@ -0,0 +1,21 @@
|
|||
NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit)
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra30-smmu"
|
||||
- reg : Should contain 3 register banks(address and length) for each
|
||||
of the SMMU register blocks.
|
||||
- interrupts : Should contain MC General interrupt.
|
||||
- nvidia,#asids : # of ASIDs
|
||||
- dma-window : IOVA start address and length.
|
||||
- nvidia,ahb : phandle to the ahb bus connected to SMMU.
|
||||
|
||||
Example:
|
||||
smmu {
|
||||
compatible = "nvidia,tegra30-smmu";
|
||||
reg = <0x7000f010 0x02c
|
||||
0x7000f1f0 0x010
|
||||
0x7000f228 0x05c>;
|
||||
nvidia,#asids = <4>; /* # of ASIDs */
|
||||
dma-window = <0 0x40000000>; /* IOVA start & length */
|
||||
nvidia,ahb = <&ahb>;
|
||||
};
|
123
Documentation/devicetree/bindings/mfd/ab8500.txt
Normal file
123
Documentation/devicetree/bindings/mfd/ab8500.txt
Normal 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
59
Documentation/devicetree/bindings/mfd/max77686.txt
Normal 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;
|
||||
};
|
||||
}
|
|
@ -17,18 +17,46 @@ Required properties:
|
|||
device need to be present. The definition for each of these nodes is defined
|
||||
using the standard binding for regulators found at
|
||||
Documentation/devicetree/bindings/regulator/regulator.txt.
|
||||
The regulator is matched with the regulator-compatible.
|
||||
|
||||
The valid names for regulators are:
|
||||
The valid regulator-compatible values are:
|
||||
tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1,
|
||||
vaux2, vaux33, vmmc
|
||||
tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
|
||||
ldo6, ldo7, ldo8
|
||||
|
||||
- xxx-supply: Input voltage supply regulator.
|
||||
These entries are require if regulators are enabled for a device. Missing of these
|
||||
properties can cause the regulator registration fails.
|
||||
If some of input supply is powered through battery or always-on supply then
|
||||
also it is require to have these parameters with proper node handle of always
|
||||
on power supply.
|
||||
tps65910:
|
||||
vcc1-supply: VDD1 input.
|
||||
vcc2-supply: VDD2 input.
|
||||
vcc3-supply: VAUX33 and VMMC input.
|
||||
vcc4-supply: VAUX1 and VAUX2 input.
|
||||
vcc5-supply: VPLL and VDAC input.
|
||||
vcc6-supply: VDIG1 and VDIG2 input.
|
||||
vcc7-supply: VRTC input.
|
||||
vccio-supply: VIO input.
|
||||
tps65911:
|
||||
vcc1-supply: VDD1 input.
|
||||
vcc2-supply: VDD2 input.
|
||||
vcc3-supply: LDO6, LDO7 and LDO8 input.
|
||||
vcc4-supply: LDO5 input.
|
||||
vcc5-supply: LDO3 and LDO4 input.
|
||||
vcc6-supply: LDO1 and LDO2 input.
|
||||
vcc7-supply: VRTC input.
|
||||
vccio-supply: VIO input.
|
||||
|
||||
Optional properties:
|
||||
- ti,vmbch-threshold: (tps65911) main battery charged threshold
|
||||
comparator. (see VMBCH_VSEL in TPS65910 datasheet)
|
||||
- ti,vmbch2-threshold: (tps65911) main battery discharged threshold
|
||||
comparator. (see VMBCH_VSEL in TPS65910 datasheet)
|
||||
- ti,en-ck32k-xtal: enable external 32-kHz crystal oscillator (see CK32K_CTRL
|
||||
in TPS6591X datasheet)
|
||||
- ti,en-gpio-sleep: enable sleep control for gpios
|
||||
There should be 9 entries here, one for each gpio.
|
||||
|
||||
|
@ -53,77 +81,113 @@ 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 = <®_parent>;
|
||||
vcc2-supply = <&some_reg>;
|
||||
vcc3-supply = <...>;
|
||||
vcc4-supply = <...>;
|
||||
vcc5-supply = <...>;
|
||||
vcc6-supply = <...>;
|
||||
vcc7-supply = <...>;
|
||||
vccio-supply = <...>;
|
||||
|
||||
regulators {
|
||||
vdd1_reg: vdd1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
vdd1_reg: regulator@0 {
|
||||
regulator-compatible = "vdd1";
|
||||
reg = <0>;
|
||||
regulator-min-microvolt = < 600000>;
|
||||
regulator-max-microvolt = <1500000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
vdd2_reg: vdd2 {
|
||||
vdd2_reg: regulator@1 {
|
||||
regulator-compatible = "vdd2";
|
||||
reg = <1>;
|
||||
regulator-min-microvolt = < 600000>;
|
||||
regulator-max-microvolt = <1500000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
ti,regulator-ext-sleep-control = <4>;
|
||||
};
|
||||
vddctrl_reg: vddctrl {
|
||||
vddctrl_reg: regulator@2 {
|
||||
regulator-compatible = "vddctrl";
|
||||
reg = <2>;
|
||||
regulator-min-microvolt = < 600000>;
|
||||
regulator-max-microvolt = <1400000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
vio_reg: vio {
|
||||
vio_reg: regulator@3 {
|
||||
regulator-compatible = "vio";
|
||||
reg = <3>;
|
||||
regulator-min-microvolt = <1500000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
ti,regulator-ext-sleep-control = <1>;
|
||||
};
|
||||
ldo1_reg: ldo1 {
|
||||
ldo1_reg: regulator@4 {
|
||||
regulator-compatible = "ldo1";
|
||||
reg = <4>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
ldo2_reg: ldo2 {
|
||||
ldo2_reg: regulator@5 {
|
||||
regulator-compatible = "ldo2";
|
||||
reg = <5>;
|
||||
regulator-min-microvolt = <1050000>;
|
||||
regulator-max-microvolt = <1050000>;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
ldo3_reg: ldo3 {
|
||||
ldo3_reg: regulator@6 {
|
||||
regulator-compatible = "ldo3";
|
||||
reg = <6>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
ldo4_reg: ldo4 {
|
||||
ldo4_reg: regulator@7 {
|
||||
regulator-compatible = "ldo4";
|
||||
reg = <7>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-always-on;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
ldo5_reg: ldo5 {
|
||||
ldo5_reg: regulator@8 {
|
||||
regulator-compatible = "ldo5";
|
||||
reg = <8>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
ldo6_reg: ldo6 {
|
||||
ldo6_reg: regulator@9 {
|
||||
regulator-compatible = "ldo6";
|
||||
reg = <9>;
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <1200000>;
|
||||
ti,regulator-ext-sleep-control = <0>;
|
||||
};
|
||||
ldo7_reg: ldo7 {
|
||||
ldo7_reg: regulator@10 {
|
||||
regulator-compatible = "ldo7";
|
||||
reg = <10>;
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <1200000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
ti,regulator-ext-sleep-control = <1>;
|
||||
};
|
||||
ldo8_reg: ldo8 {
|
||||
ldo8_reg: regulator@11 {
|
||||
regulator-compatible = "ldo8";
|
||||
reg = <11>;
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-always-on;
|
||||
|
|
|
@ -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
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue