Linux 3.6-rc4
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iQEcBAABAgAGBQJQQkiRAAoJEHm+PkMAQRiGk64H/Rp67mBWom2xMmU8gul3gr7d MFq7dQOShoHZVyuCtKFNF+RTFkHDT2mw0ZkdszHdMkPEznIVRNklieN6GayOwj7C XcRb50z/C0CTvEskLOzWsaC+Rok6doOi5VCgkkZ+6N4CvWQNEqWLfWW5H6wZ7juo ME1xx/59GDm/4TYMUXzPI9UygptGGXvH/18n/z47FQpvL5EbAECTVt1nPX1uvn/S ZzdSLG8MrbK+IX+62JZqRG5M6TUC2b8ggog2cFfP20JNK0TwU9dMQPtbk2Y+LZRg JiUqyRUOuQJFbCgE+b1JuleJHAlsAgqIs7tkY9VfdFYfh+NQcaccWjDjdeB7Hjo= =Ooia -----END PGP SIGNATURE----- Merge tag 'v3.6-rc4' into next Linux 3.6-rc4 # gpg: Signature made Sat 01 Sep 2012 10:40:33 AM PDT using RSA key ID 00411886 # gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>"
This commit is contained in:
commit
e6c340171f
|
@ -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
|
||||
|
|
|
@ -1,26 +1,5 @@
|
|||
What: /sys/block/rssd*/registers
|
||||
Date: March 2012
|
||||
KernelVersion: 3.3
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Dumps below driver information and
|
||||
hardware registers.
|
||||
- S ACTive
|
||||
- Command Issue
|
||||
- Completed
|
||||
- PORT IRQ STAT
|
||||
- HOST IRQ STAT
|
||||
- Allocated
|
||||
- Commands in Q
|
||||
|
||||
What: /sys/block/rssd*/status
|
||||
Date: April 2012
|
||||
KernelVersion: 3.4
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Indicates the status of the device.
|
||||
|
||||
What: /sys/block/rssd*/flags
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Dumps the flags in port and driver
|
||||
data structure
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -142,13 +142,14 @@ KernelVersion: 3.4
|
|||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
This allows the user to examine and adjust the criteria by which
|
||||
mtd returns -EUCLEAN from mtd_read(). If the maximum number of
|
||||
bit errors that were corrected on any single region comprising
|
||||
an ecc step (as reported by the driver) equals or exceeds this
|
||||
value, -EUCLEAN is returned. Otherwise, absent an error, 0 is
|
||||
returned. Higher layers (e.g., UBI) use this return code as an
|
||||
indication that an erase block may be degrading and should be
|
||||
scrutinized as a candidate for being marked as bad.
|
||||
mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the
|
||||
maximum number of bit errors that were corrected on any single
|
||||
region comprising an ecc step (as reported by the driver) equals
|
||||
or exceeds this value, -EUCLEAN is returned. Otherwise, absent
|
||||
an error, 0 is returned. Higher layers (e.g., UBI) use this
|
||||
return code as an indication that an erase block may be
|
||||
degrading and should be scrutinized as a candidate for being
|
||||
marked as bad.
|
||||
|
||||
The initial value may be specified by the flash device driver.
|
||||
If not, then the default value is ecc_strength.
|
||||
|
@ -167,7 +168,7 @@ Description:
|
|||
block degradation, but high enough to avoid the consequences of
|
||||
a persistent return value of -EUCLEAN on devices where sticky
|
||||
bitflips occur. Note that if bitflip_threshold exceeds
|
||||
ecc_strength, -EUCLEAN is never returned by mtd_read().
|
||||
ecc_strength, -EUCLEAN is never returned by the read operations.
|
||||
Conversely, if bitflip_threshold is zero, -EUCLEAN is always
|
||||
returned, absent a hard error.
|
||||
|
||||
|
|
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.
|
||||
|
|
|
@ -5,4 +5,15 @@ Contact: "Ike Panhc <ike.pan@canonical.com>"
|
|||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/ideapad/fan_mode
|
||||
Date: June 2012
|
||||
KernelVersion: 3.6
|
||||
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
|
||||
Description:
|
||||
Change fan mode
|
||||
There are four available modes:
|
||||
* 0 -> Super Silent Mode
|
||||
* 1 -> Standard Mode
|
||||
* 2 -> Dust Cleaning
|
||||
* 4 -> Efficient Thermal Dissipation Mode
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
@ -3988,7 +3993,7 @@ interface and may change in the future.</para>
|
|||
from RGB to Y'CbCr color space.
|
||||
</entry>
|
||||
</row>
|
||||
<row id = "v4l2-jpeg-chroma-subsampling">
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
|
|
|
@ -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>
|
|
@ -284,13 +284,6 @@ These controls are described in <xref
|
|||
processing controls. These controls are described in <xref
|
||||
linkend="image-process-controls" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_CLASS_JPEG</constant></entry>
|
||||
<entry>0x9d0000</entry>
|
||||
<entry>The class containing JPEG compression controls.
|
||||
These controls are described in <xref
|
||||
linkend="jpeg-controls" />.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -162,9 +162,9 @@ over a rather long period of time, but improvements are always welcome!
|
|||
when publicizing a pointer to a structure that can
|
||||
be traversed by an RCU read-side critical section.
|
||||
|
||||
5. If call_rcu(), or a related primitive such as call_rcu_bh() or
|
||||
call_rcu_sched(), is used, the callback function must be
|
||||
written to be called from softirq context. In particular,
|
||||
5. If call_rcu(), or a related primitive such as call_rcu_bh(),
|
||||
call_rcu_sched(), or call_srcu() is used, the callback function
|
||||
must be written to be called from softirq context. In particular,
|
||||
it cannot block.
|
||||
|
||||
6. Since synchronize_rcu() can block, it cannot be called from
|
||||
|
@ -202,11 +202,12 @@ over a rather long period of time, but improvements are always welcome!
|
|||
updater uses call_rcu_sched() or synchronize_sched(), then
|
||||
the corresponding readers must disable preemption, possibly
|
||||
by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
|
||||
If the updater uses synchronize_srcu(), the the corresponding
|
||||
readers must use srcu_read_lock() and srcu_read_unlock(),
|
||||
and with the same srcu_struct. The rules for the expedited
|
||||
primitives are the same as for their non-expedited counterparts.
|
||||
Mixing things up will result in confusion and broken kernels.
|
||||
If the updater uses synchronize_srcu() or call_srcu(),
|
||||
the the corresponding readers must use srcu_read_lock() and
|
||||
srcu_read_unlock(), and with the same srcu_struct. The rules for
|
||||
the expedited primitives are the same as for their non-expedited
|
||||
counterparts. Mixing things up will result in confusion and
|
||||
broken kernels.
|
||||
|
||||
One exception to this rule: rcu_read_lock() and rcu_read_unlock()
|
||||
may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()
|
||||
|
@ -333,14 +334,14 @@ over a rather long period of time, but improvements are always welcome!
|
|||
victim CPU from ever going offline.)
|
||||
|
||||
14. SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),
|
||||
synchronize_srcu(), and synchronize_srcu_expedited()) may only
|
||||
be invoked from process context. Unlike other forms of RCU, it
|
||||
-is- permissible to block in an SRCU read-side critical section
|
||||
(demarked by srcu_read_lock() and srcu_read_unlock()), hence the
|
||||
"SRCU": "sleepable RCU". Please note that if you don't need
|
||||
to sleep in read-side critical sections, you should be using
|
||||
RCU rather than SRCU, because RCU is almost always faster and
|
||||
easier to use than is SRCU.
|
||||
synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())
|
||||
may only be invoked from process context. Unlike other forms of
|
||||
RCU, it -is- permissible to block in an SRCU read-side critical
|
||||
section (demarked by srcu_read_lock() and srcu_read_unlock()),
|
||||
hence the "SRCU": "sleepable RCU". Please note that if you
|
||||
don't need to sleep in read-side critical sections, you should be
|
||||
using RCU rather than SRCU, because RCU is almost always faster
|
||||
and easier to use than is SRCU.
|
||||
|
||||
If you need to enter your read-side critical section in a
|
||||
hardirq or exception handler, and then exit that same read-side
|
||||
|
@ -353,8 +354,8 @@ over a rather long period of time, but improvements are always welcome!
|
|||
cleanup_srcu_struct(). These are passed a "struct srcu_struct"
|
||||
that defines the scope of a given SRCU domain. Once initialized,
|
||||
the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()
|
||||
synchronize_srcu(), and synchronize_srcu_expedited(). A given
|
||||
synchronize_srcu() waits only for SRCU read-side critical
|
||||
synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().
|
||||
A given synchronize_srcu() waits only for SRCU read-side critical
|
||||
sections governed by srcu_read_lock() and srcu_read_unlock()
|
||||
calls that have been passed the same srcu_struct. This property
|
||||
is what makes sleeping read-side critical sections tolerable --
|
||||
|
@ -374,7 +375,7 @@ over a rather long period of time, but improvements are always welcome!
|
|||
requiring SRCU's read-side deadlock immunity or low read-side
|
||||
realtime latency.
|
||||
|
||||
Note that, rcu_assign_pointer() relates to SRCU just as they do
|
||||
Note that, rcu_assign_pointer() relates to SRCU just as it does
|
||||
to other forms of RCU.
|
||||
|
||||
15. The whole point of call_rcu(), synchronize_rcu(), and friends
|
||||
|
|
|
@ -79,8 +79,6 @@ complete. Pseudo-code using rcu_barrier() is as follows:
|
|||
2. Execute rcu_barrier().
|
||||
3. Allow the module to be unloaded.
|
||||
|
||||
Quick Quiz #1: Why is there no srcu_barrier()?
|
||||
|
||||
The rcutorture module makes use of rcu_barrier in its exit function
|
||||
as follows:
|
||||
|
||||
|
@ -162,7 +160,7 @@ for any pre-existing callbacks to complete.
|
|||
Then lines 55-62 print status and do operation-specific cleanup, and
|
||||
then return, permitting the module-unload operation to be completed.
|
||||
|
||||
Quick Quiz #2: Is there any other situation where rcu_barrier() might
|
||||
Quick Quiz #1: Is there any other situation where rcu_barrier() might
|
||||
be required?
|
||||
|
||||
Your module might have additional complications. For example, if your
|
||||
|
@ -242,7 +240,7 @@ reaches zero, as follows:
|
|||
4 complete(&rcu_barrier_completion);
|
||||
5 }
|
||||
|
||||
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
|
||||
Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
|
||||
immediately (thus incrementing rcu_barrier_cpu_count to the
|
||||
value one), but the other CPU's rcu_barrier_func() invocations
|
||||
are delayed for a full grace period? Couldn't this result in
|
||||
|
@ -259,12 +257,7 @@ so that your module may be safely unloaded.
|
|||
|
||||
Answers to Quick Quizzes
|
||||
|
||||
Quick Quiz #1: Why is there no srcu_barrier()?
|
||||
|
||||
Answer: Since there is no call_srcu(), there can be no outstanding SRCU
|
||||
callbacks. Therefore, there is no need to wait for them.
|
||||
|
||||
Quick Quiz #2: Is there any other situation where rcu_barrier() might
|
||||
Quick Quiz #1: Is there any other situation where rcu_barrier() might
|
||||
be required?
|
||||
|
||||
Answer: Interestingly enough, rcu_barrier() was not originally
|
||||
|
@ -278,7 +271,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally
|
|||
implementing rcutorture, and found that rcu_barrier() solves
|
||||
this problem as well.
|
||||
|
||||
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
|
||||
Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
|
||||
immediately (thus incrementing rcu_barrier_cpu_count to the
|
||||
value one), but the other CPU's rcu_barrier_func() invocations
|
||||
are delayed for a full grace period? Couldn't this result in
|
||||
|
|
|
@ -174,11 +174,20 @@ torture_type The type of RCU to test, with string values as follows:
|
|||
and synchronize_rcu_bh_expedited().
|
||||
|
||||
"srcu": srcu_read_lock(), srcu_read_unlock() and
|
||||
call_srcu().
|
||||
|
||||
"srcu_sync": srcu_read_lock(), srcu_read_unlock() and
|
||||
synchronize_srcu().
|
||||
|
||||
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
|
||||
synchronize_srcu_expedited().
|
||||
|
||||
"srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
|
||||
and call_srcu().
|
||||
|
||||
"srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
|
||||
and synchronize_srcu().
|
||||
|
||||
"sched": preempt_disable(), preempt_enable(), and
|
||||
call_rcu_sched().
|
||||
|
||||
|
|
|
@ -833,9 +833,9 @@ sched: Critical sections Grace period Barrier
|
|||
|
||||
SRCU: Critical sections Grace period Barrier
|
||||
|
||||
srcu_read_lock synchronize_srcu N/A
|
||||
srcu_read_unlock synchronize_srcu_expedited
|
||||
srcu_read_lock_raw
|
||||
srcu_read_lock synchronize_srcu srcu_barrier
|
||||
srcu_read_unlock call_srcu
|
||||
srcu_read_lock_raw synchronize_srcu_expedited
|
||||
srcu_read_unlock_raw
|
||||
srcu_dereference
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -3,15 +3,21 @@
|
|||
biodoc.txt
|
||||
- Notes on the Generic Block Layer Rewrite in Linux 2.5
|
||||
capability.txt
|
||||
- Generic Block Device Capability (/sys/block/<disk>/capability)
|
||||
- Generic Block Device Capability (/sys/block/<device>/capability)
|
||||
cfq-iosched.txt
|
||||
- CFQ IO scheduler tunables
|
||||
data-integrity.txt
|
||||
- Block data integrity
|
||||
deadline-iosched.txt
|
||||
- Deadline IO scheduler tunables
|
||||
ioprio.txt
|
||||
- Block io priorities (in CFQ scheduler)
|
||||
queue-sysfs.txt
|
||||
- Queue's sysfs entries
|
||||
request.txt
|
||||
- The members of struct request (in include/linux/blkdev.h)
|
||||
stat.txt
|
||||
- Block layer statistics in /sys/block/<dev>/stat
|
||||
- Block layer statistics in /sys/block/<device>/stat
|
||||
switching-sched.txt
|
||||
- Switching I/O schedulers at runtime
|
||||
writeback_cache_control.txt
|
||||
|
|
|
@ -1,3 +1,14 @@
|
|||
CFQ (Complete Fairness Queueing)
|
||||
===============================
|
||||
|
||||
The main aim of CFQ scheduler is to provide a fair allocation of the disk
|
||||
I/O bandwidth for all the processes which requests an I/O operation.
|
||||
|
||||
CFQ maintains the per process queue for the processes which request I/O
|
||||
operation(syncronous requests). In case of asynchronous requests, all the
|
||||
requests from all the processes are batched together according to their
|
||||
process's I/O priority.
|
||||
|
||||
CFQ ioscheduler tunables
|
||||
========================
|
||||
|
||||
|
@ -25,6 +36,72 @@ there are multiple spindles behind single LUN (Host based hardware RAID
|
|||
controller or for storage arrays), setting slice_idle=0 might end up in better
|
||||
throughput and acceptable latencies.
|
||||
|
||||
back_seek_max
|
||||
-------------
|
||||
This specifies, given in Kbytes, the maximum "distance" for backward seeking.
|
||||
The distance is the amount of space from the current head location to the
|
||||
sectors that are backward in terms of distance.
|
||||
|
||||
This parameter allows the scheduler to anticipate requests in the "backward"
|
||||
direction and consider them as being the "next" if they are within this
|
||||
distance from the current head location.
|
||||
|
||||
back_seek_penalty
|
||||
-----------------
|
||||
This parameter is used to compute the cost of backward seeking. If the
|
||||
backward distance of request is just 1/back_seek_penalty from a "front"
|
||||
request, then the seeking cost of two requests is considered equivalent.
|
||||
|
||||
So scheduler will not bias toward one or the other request (otherwise scheduler
|
||||
will bias toward front request). Default value of back_seek_penalty is 2.
|
||||
|
||||
fifo_expire_async
|
||||
-----------------
|
||||
This parameter is used to set the timeout of asynchronous requests. Default
|
||||
value of this is 248ms.
|
||||
|
||||
fifo_expire_sync
|
||||
----------------
|
||||
This parameter is used to set the timeout of synchronous requests. Default
|
||||
value of this is 124ms. In case to favor synchronous requests over asynchronous
|
||||
one, this value should be decreased relative to fifo_expire_async.
|
||||
|
||||
slice_async
|
||||
-----------
|
||||
This parameter is same as of slice_sync but for asynchronous queue. The
|
||||
default value is 40ms.
|
||||
|
||||
slice_async_rq
|
||||
--------------
|
||||
This parameter is used to limit the dispatching of asynchronous request to
|
||||
device request queue in queue's slice time. The maximum number of request that
|
||||
are allowed to be dispatched also depends upon the io priority. Default value
|
||||
for this is 2.
|
||||
|
||||
slice_sync
|
||||
----------
|
||||
When a queue is selected for execution, the queues IO requests are only
|
||||
executed for a certain amount of time(time_slice) before switching to another
|
||||
queue. This parameter is used to calculate the time slice of synchronous
|
||||
queue.
|
||||
|
||||
time_slice is computed using the below equation:-
|
||||
time_slice = slice_sync + (slice_sync/5 * (4 - prio)). To increase the
|
||||
time_slice of synchronous queue, increase the value of slice_sync. Default
|
||||
value is 100ms.
|
||||
|
||||
quantum
|
||||
-------
|
||||
This specifies the number of request dispatched to the device queue. In a
|
||||
queue's time slice, a request will not be dispatched if the number of request
|
||||
in the device exceeds this parameter. This parameter is used for synchronous
|
||||
request.
|
||||
|
||||
In case of storage with several disk, this setting can limit the parallel
|
||||
processing of request. Therefore, increasing the value can imporve the
|
||||
performace although this can cause the latency of some I/O to increase due
|
||||
to more number of requests.
|
||||
|
||||
CFQ IOPS Mode for group scheduling
|
||||
===================================
|
||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||
|
|
|
@ -9,20 +9,71 @@ These files are the ones found in the /sys/block/xxx/queue/ directory.
|
|||
Files denoted with a RO postfix are readonly and the RW postfix means
|
||||
read-write.
|
||||
|
||||
add_random (RW)
|
||||
----------------
|
||||
This file allows to trun off the disk entropy contribution. Default
|
||||
value of this file is '1'(on).
|
||||
|
||||
discard_granularity (RO)
|
||||
-----------------------
|
||||
This shows the size of internal allocation of the device in bytes, if
|
||||
reported by the device. A value of '0' means device does not support
|
||||
the discard functionality.
|
||||
|
||||
discard_max_bytes (RO)
|
||||
----------------------
|
||||
Devices that support discard functionality may have internal limits on
|
||||
the number of bytes that can be trimmed or unmapped in a single operation.
|
||||
The discard_max_bytes parameter is set by the device driver to the maximum
|
||||
number of bytes that can be discarded in a single operation. Discard
|
||||
requests issued to the device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support discard functionality.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
device or not. If its value is '1' the blocks are zeroed otherwise not.
|
||||
|
||||
hw_sector_size (RO)
|
||||
-------------------
|
||||
This is the hardware sector size of the device, in bytes.
|
||||
|
||||
iostats (RW)
|
||||
-------------
|
||||
This file is used to control (on/off) the iostats accounting of the
|
||||
disk.
|
||||
|
||||
logical_block_size (RO)
|
||||
-----------------------
|
||||
This is the logcal block size of the device, in bytes.
|
||||
|
||||
max_hw_sectors_kb (RO)
|
||||
----------------------
|
||||
This is the maximum number of kilobytes supported in a single data transfer.
|
||||
|
||||
max_integrity_segments (RO)
|
||||
---------------------------
|
||||
When read, this file shows the max limit of integrity segments as
|
||||
set by block layer which a hardware controller can handle.
|
||||
|
||||
max_sectors_kb (RW)
|
||||
-------------------
|
||||
This is the maximum number of kilobytes that the block layer will allow
|
||||
for a filesystem request. Must be smaller than or equal to the maximum
|
||||
size allowed by the hardware.
|
||||
|
||||
max_segments (RO)
|
||||
-----------------
|
||||
Maximum number of segments of the device.
|
||||
|
||||
max_segment_size (RO)
|
||||
---------------------
|
||||
Maximum segment size of the device.
|
||||
|
||||
minimum_io_size (RO)
|
||||
--------------------
|
||||
This is the smallest preferred io size reported by the device.
|
||||
|
||||
nomerges (RW)
|
||||
-------------
|
||||
This enables the user to disable the lookup logic involved with IO
|
||||
|
@ -38,11 +89,31 @@ 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.
|
||||
|
||||
optimal_io_size (RO)
|
||||
--------------------
|
||||
This is the optimal io size reported by the device.
|
||||
|
||||
physical_block_size (RO)
|
||||
------------------------
|
||||
This is the physical block size of device, in bytes.
|
||||
|
||||
read_ahead_kb (RW)
|
||||
------------------
|
||||
Maximum number of kilobytes to read-ahead for filesystems on this block
|
||||
device.
|
||||
|
||||
rotational (RW)
|
||||
---------------
|
||||
This file is used to stat if the device is of rotational type or
|
||||
non-rotational type.
|
||||
|
||||
rq_affinity (RW)
|
||||
----------------
|
||||
If this option is '1', the block layer will migrate request completions to the
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -7,39 +7,39 @@ This target is read-only.
|
|||
|
||||
Construction Parameters
|
||||
=======================
|
||||
<version> <dev> <hash_dev> <hash_start>
|
||||
<version> <dev> <hash_dev>
|
||||
<data_block_size> <hash_block_size>
|
||||
<num_data_blocks> <hash_start_block>
|
||||
<algorithm> <digest> <salt>
|
||||
|
||||
<version>
|
||||
This is the version number of the on-disk format.
|
||||
This is the type of the on-disk hash format.
|
||||
|
||||
0 is the original format used in the Chromium OS.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
|
||||
1 is the current format that should be used for new devices.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
|
||||
<dev>
|
||||
This is the device containing the data the integrity of which needs to be
|
||||
This is the device containing data, the integrity of which needs to be
|
||||
checked. It may be specified as a path, like /dev/sdaX, or a device number,
|
||||
<major>:<minor>.
|
||||
|
||||
<hash_dev>
|
||||
This is the device that that supplies the hash tree data. It may be
|
||||
This is the device that supplies the hash tree data. It may be
|
||||
specified similarly to the device path and may be the same device. If the
|
||||
same device is used, the hash_start should be outside of the dm-verity
|
||||
configured device size.
|
||||
same device is used, the hash_start should be outside the configured
|
||||
dm-verity device.
|
||||
|
||||
<data_block_size>
|
||||
The block size on a data device. Each block corresponds to one digest on
|
||||
the hash device.
|
||||
The block size on a data device in bytes.
|
||||
Each block corresponds to one digest on the hash device.
|
||||
|
||||
<hash_block_size>
|
||||
The size of a hash block.
|
||||
The size of a hash block in bytes.
|
||||
|
||||
<num_data_blocks>
|
||||
The number of data blocks on the data device. Additional blocks are
|
||||
|
@ -65,7 +65,7 @@ Construction Parameters
|
|||
Theory of operation
|
||||
===================
|
||||
|
||||
dm-verity is meant to be setup as part of a verified boot path. This
|
||||
dm-verity is meant to be set up as part of a verified boot path. This
|
||||
may be anything ranging from a boot using tboot or trustedgrub to just
|
||||
booting from a known-good device (like a USB drive or CD).
|
||||
|
||||
|
@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller
|
|||
has been authenticated in some way (cryptographic signatures, etc).
|
||||
After instantiation, all hashes will be verified on-demand during
|
||||
disk access. If they cannot be verified up to the root node of the
|
||||
tree, the root hash, then the I/O will fail. This should identify
|
||||
tree, the root hash, then the I/O will fail. This should detect
|
||||
tampering with any data on the device and the hash data.
|
||||
|
||||
Cryptographic hashes are used to assert the integrity of the device on a
|
||||
per-block basis. This allows for a lightweight hash computation on first read
|
||||
into the page cache. Block hashes are stored linearly-aligned to the nearest
|
||||
block the size of a page.
|
||||
per-block basis. This allows for a lightweight hash computation on first read
|
||||
into the page cache. Block hashes are stored linearly, aligned to the nearest
|
||||
block size.
|
||||
|
||||
Hash Tree
|
||||
---------
|
||||
|
||||
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
|
||||
is of some block data on disk. If it is an intermediary node, then the hash is
|
||||
of a number of child nodes.
|
||||
of some data block on disk is calculated. If it is an intermediary node,
|
||||
the hash of a number of child nodes is calculated.
|
||||
|
||||
Each entry in the tree is a collection of neighboring nodes that fit in one
|
||||
block. The number is determined based on block_size and the size of the
|
||||
|
@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096
|
|||
On-disk format
|
||||
==============
|
||||
|
||||
Below is the recommended on-disk format. The verity kernel code does not
|
||||
read the on-disk header. It only reads the hash blocks which directly
|
||||
follow the header. It is expected that a user-space tool will verify the
|
||||
integrity of the verity_header and then call dmsetup with the correct
|
||||
parameters. Alternatively, the header can be omitted and the dmsetup
|
||||
parameters can be passed via the kernel command-line in a rooted chain
|
||||
of trust where the command-line is verified.
|
||||
The verity kernel code does not read the verity metadata on-disk header.
|
||||
It only reads the hash blocks which directly follow the header.
|
||||
It is expected that a user-space tool will verify the integrity of the
|
||||
verity header.
|
||||
|
||||
The on-disk format is especially useful in cases where the hash blocks
|
||||
are on a separate partition. The magic number allows easy identification
|
||||
of the partition contents. Alternatively, the hash blocks can be stored
|
||||
in the same partition as the data to be verified. In such a configuration
|
||||
the filesystem on the partition would be sized a little smaller than
|
||||
the full-partition, leaving room for the hash blocks.
|
||||
|
||||
struct superblock {
|
||||
uint8_t signature[8]
|
||||
"verity\0\0";
|
||||
|
||||
uint8_t version;
|
||||
1 - current format
|
||||
|
||||
uint8_t data_block_bits;
|
||||
log2(data block size)
|
||||
|
||||
uint8_t hash_block_bits;
|
||||
log2(hash block size)
|
||||
|
||||
uint8_t pad1[1];
|
||||
zero padding
|
||||
|
||||
uint16_t salt_size;
|
||||
big-endian salt size
|
||||
|
||||
uint8_t pad2[2];
|
||||
zero padding
|
||||
|
||||
uint32_t data_blocks_hi;
|
||||
big-endian high 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint32_t data_blocks_lo;
|
||||
big-endian low 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint8_t algorithm[16];
|
||||
cryptographic algorithm
|
||||
|
||||
uint8_t salt[384];
|
||||
salt (the salt size is specified above)
|
||||
|
||||
uint8_t pad3[88];
|
||||
zero padding to 512-byte boundary
|
||||
}
|
||||
Alternatively, the header can be omitted and the dmsetup parameters can
|
||||
be passed via the kernel command-line in a rooted chain of trust where
|
||||
the command-line is verified.
|
||||
|
||||
Directly following the header (and with sector number padded to the next hash
|
||||
block boundary) are the hash blocks which are stored a depth at a time
|
||||
(starting from the root), sorted in order of increasing index.
|
||||
|
||||
The full specification of kernel parameters and on-disk metadata format
|
||||
is available at the cryptsetup project's wiki page
|
||||
http://code.google.com/p/cryptsetup/wiki/DMVerity
|
||||
|
||||
Status
|
||||
======
|
||||
V (for Valid) is returned if every check performed so far was valid.
|
||||
|
@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned.
|
|||
|
||||
Example
|
||||
=======
|
||||
|
||||
Setup a device:
|
||||
dmsetup create vroot --table \
|
||||
"0 2097152 "\
|
||||
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
|
||||
Set up a device:
|
||||
# dmsetup create vroot --readonly --table \
|
||||
"0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
|
||||
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
|
||||
"1234000000000000000000000000000000000000000000000000000000000000"
|
||||
|
||||
A command line tool veritysetup is available to compute or verify
|
||||
the hash tree or activate the kernel driver. This is available from
|
||||
the LVM2 upstream repository and may be supplied as a package called
|
||||
device-mapper-verity-tools:
|
||||
git://sources.redhat.com/git/lvm2
|
||||
http://sourceware.org/git/?p=lvm2.git
|
||||
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
|
||||
the hash tree or activate the kernel device. This is available from
|
||||
the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
|
||||
(as a libcryptsetup extension).
|
||||
|
||||
veritysetup -a vroot /dev/sda1 /dev/sda2 \
|
||||
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
Create hash on the device:
|
||||
# veritysetup format /dev/sda1 /dev/sda2
|
||||
...
|
||||
Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
|
||||
Activate the device:
|
||||
# veritysetup create vroot /dev/sda1 /dev/sda2 \
|
||||
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
|
|
|
@ -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>;
|
||||
};
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue