Merge branch 'sh/dmaengine' into sh-latest
This commit is contained in:
Paul Mundt
Коммит
91ba548cfd
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ in the frequency range from 87,5 to 108,0 MHz</title>
|
|||
<corpauthor>National Radio Systems Committee
|
||||
(<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor>
|
||||
</authorgroup>
|
||||
<title>NTSC-4: United States RBDS Standard</title>
|
||||
<title>NRSC-4: United States RBDS Standard</title>
|
||||
</biblioentry>
|
||||
|
||||
<biblioentry id="iso12232">
|
||||
|
|
|
|||
|
|
@ -464,14 +464,14 @@ The <structfield>type</structfield> field of the respective
|
|||
<structfield>tuner</structfield> field contains the index number of
|
||||
the tuner.</para>
|
||||
|
||||
<para>Radio devices have exactly one tuner with index zero, no
|
||||
<para>Radio input devices have exactly one tuner with index zero, no
|
||||
video inputs.</para>
|
||||
|
||||
<para>To query and change tuner properties applications use the
|
||||
&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The
|
||||
&v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also
|
||||
contains signal status information applicable when the tuner of the
|
||||
current video input, or a radio tuner is queried. Note that
|
||||
current video or radio input is queried. Note that
|
||||
<constant>VIDIOC_S_TUNER</constant> does not switch the current tuner,
|
||||
when there is more than one at all. The tuner is solely determined by
|
||||
the current video input. Drivers must support both ioctls and set the
|
||||
|
|
@ -491,8 +491,17 @@ the modulator. The <structfield>type</structfield> field of the
|
|||
respective &v4l2-output; returned by the &VIDIOC-ENUMOUTPUT; ioctl is
|
||||
set to <constant>V4L2_OUTPUT_TYPE_MODULATOR</constant> and its
|
||||
<structfield>modulator</structfield> field contains the index number
|
||||
of the modulator. This specification does not define radio output
|
||||
devices.</para>
|
||||
of the modulator.</para>
|
||||
|
||||
<para>Radio output devices have exactly one modulator with index
|
||||
zero, no video outputs.</para>
|
||||
|
||||
<para>A video or radio device cannot support both a tuner and a
|
||||
modulator. Two separate device nodes will have to be used for such
|
||||
hardware, one that supports the tuner functionality and one that supports
|
||||
the modulator functionality. The reason is a limitation with the
|
||||
&VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency
|
||||
is for a tuner or a modulator.</para>
|
||||
|
||||
<para>To query and change modulator properties applications use
|
||||
the &VIDIOC-G-MODULATOR; and &VIDIOC-S-MODULATOR; ioctl. Note that
|
||||
|
|
|
|||
|
|
@ -2377,10 +2377,11 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
<para>V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add selection API for extended control over cropping and
|
||||
composing. Does not affect the compatibility of current drivers and
|
||||
applications. See <link linkend="selection-api"> selection API </link> for
|
||||
details.</para>
|
||||
<para>Add selection API for extended control over cropping
|
||||
and composing. Does not affect the compatibility of current
|
||||
drivers and applications. See <link
|
||||
linkend="selection-api"> selection API </link> for
|
||||
details.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
|
@ -2458,6 +2459,36 @@ details.</para>
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.6</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Replaced <structfield>input</structfield> in
|
||||
<structname>v4l2_buffer</structname> by
|
||||
<structfield>reserved2</structfield> and removed
|
||||
<constant>V4L2_BUF_FLAG_INPUT</constant>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.6</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.6</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
@ -2587,6 +2618,9 @@ ioctls.</para>
|
|||
<para><link linkend="v4l2-auto-focus-area"><constant>
|
||||
V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -372,6 +372,11 @@ minimum value disables backlight compensation.</entry>
|
|||
Cr component, bits [15:8] as Cb component and bits [31:16] must be zero.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_AUTOBRIGHTNESS</constant></entry>
|
||||
<entry>boolean</entry>
|
||||
<entry>Enable Automatic Brightness.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_ROTATE</constant></entry>
|
||||
<entry>integer</entry>
|
||||
|
|
|
|||
|
|
@ -276,7 +276,7 @@
|
|||
</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<section id="v4l2-subdev-selections">
|
||||
<title>Selections: cropping, scaling and composition</title>
|
||||
|
||||
<para>Many sub-devices support cropping frames on their input or output
|
||||
|
|
@ -290,8 +290,8 @@
|
|||
size. Both the coordinates and sizes are expressed in pixels.</para>
|
||||
|
||||
<para>As for pad formats, drivers store try and active
|
||||
rectangles for the selection targets of ACTUAL type <xref
|
||||
linkend="v4l2-subdev-selection-targets">.</xref></para>
|
||||
rectangles for the selection targets <xref
|
||||
linkend="v4l2-selections-common" />.</para>
|
||||
|
||||
<para>On sink pads, cropping is applied relative to the
|
||||
current pad format. The pad format represents the image size as
|
||||
|
|
@ -308,7 +308,7 @@
|
|||
<para>Scaling support is optional. When supported by a subdev,
|
||||
the crop rectangle on the subdev's sink pad is scaled to the
|
||||
size configured using the &VIDIOC-SUBDEV-S-SELECTION; IOCTL
|
||||
using <constant>V4L2_SUBDEV_SEL_COMPOSE_ACTUAL</constant>
|
||||
using <constant>V4L2_SEL_TGT_COMPOSE</constant>
|
||||
selection target on the same pad. If the subdev supports scaling
|
||||
but not composing, the top and left values are not used and must
|
||||
always be set to zero.</para>
|
||||
|
|
@ -323,32 +323,32 @@
|
|||
<para>The drivers should always use the closest possible
|
||||
rectangle the user requests on all selection targets, unless
|
||||
specifically told otherwise.
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant> and
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant> flags may be
|
||||
<constant>V4L2_SEL_FLAG_GE</constant> and
|
||||
<constant>V4L2_SEL_FLAG_LE</constant> flags may be
|
||||
used to round the image size either up or down. <xref
|
||||
linkend="v4l2-subdev-selection-flags"></xref></para>
|
||||
linkend="v4l2-selection-flags" /></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Types of selection targets</title>
|
||||
|
||||
<section>
|
||||
<title>ACTUAL targets</title>
|
||||
<title>Actual targets</title>
|
||||
|
||||
<para>ACTUAL targets reflect the actual hardware configuration
|
||||
at any point of time. There is a BOUNDS target
|
||||
corresponding to every ACTUAL.</para>
|
||||
<para>Actual targets (without a postfix) reflect the actual
|
||||
hardware configuration at any point of time. There is a BOUNDS
|
||||
target corresponding to every actual target.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>BOUNDS targets</title>
|
||||
|
||||
<para>BOUNDS targets is the smallest rectangle that contains
|
||||
all valid ACTUAL rectangles. It may not be possible to set the
|
||||
ACTUAL rectangle as large as the BOUNDS rectangle, however.
|
||||
This may be because e.g. a sensor's pixel array is not
|
||||
rectangular but cross-shaped or round. The maximum size may
|
||||
also be smaller than the BOUNDS rectangle.</para>
|
||||
<para>BOUNDS targets is the smallest rectangle that contains all
|
||||
valid actual rectangles. It may not be possible to set the actual
|
||||
rectangle as large as the BOUNDS rectangle, however. This may be
|
||||
because e.g. a sensor's pixel array is not rectangular but
|
||||
cross-shaped or round. The maximum size may also be smaller than the
|
||||
BOUNDS rectangle.</para>
|
||||
</section>
|
||||
|
||||
</section>
|
||||
|
|
@ -362,7 +362,7 @@
|
|||
performed by the user: the changes made will be propagated to
|
||||
any subsequent stages. If this behaviour is not desired, the
|
||||
user must set
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant> flag. This
|
||||
<constant>V4L2_SEL_FLAG_KEEP_CONFIG</constant> flag. This
|
||||
flag causes no propagation of the changes are allowed in any
|
||||
circumstances. This may also cause the accessed rectangle to be
|
||||
adjusted by the driver, depending on the properties of the
|
||||
|
|
|
|||
|
|
@ -683,14 +683,12 @@ memory, set by the application. See <xref linkend="userp" /> for details.
|
|||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>input</structfield></entry>
|
||||
<entry><structfield>reserved2</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Some video capture drivers support rapid and
|
||||
synchronous video input changes, a function useful for example in
|
||||
video surveillance applications. For this purpose applications set the
|
||||
<constant>V4L2_BUF_FLAG_INPUT</constant> flag, and this field to the
|
||||
number of a video input as in &v4l2-input; field
|
||||
<structfield>index</structfield>.</entry>
|
||||
<entry>A place holder for future extensions and custom
|
||||
(driver defined) buffer types
|
||||
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
|
||||
should set this to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -921,13 +919,6 @@ previous key frame.</entry>
|
|||
<entry>The <structfield>timecode</structfield> field is valid.
|
||||
Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant>
|
||||
ioctl is called.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_INPUT</constant></entry>
|
||||
<entry>0x0200</entry>
|
||||
<entry>The <structfield>input</structfield> field is valid.
|
||||
Applications set or clear this flag before calling the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
|
||||
|
|
|
|||
|
|
@ -53,11 +53,11 @@ cropping and composing rectangles have the same size.</para>
|
|||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
For complete list of the available selection targets see table <xref
|
||||
linkend="v4l2-sel-target"/>
|
||||
|
||||
</section>
|
||||
|
||||
See <xref linkend="v4l2-selection-targets" /> for more
|
||||
information.
|
||||
|
||||
<section>
|
||||
|
||||
<title>Configuration</title>
|
||||
|
|
@ -74,7 +74,7 @@ cropping/composing rectangles may have to be aligned, and both the source and
|
|||
the sink may have arbitrary upper and lower size limits. Therefore, as usual,
|
||||
drivers are expected to adjust the requested parameters and return the actual
|
||||
values selected. An application can control the rounding behaviour using <link
|
||||
linkend="v4l2-sel-flags"> constraint flags </link>.</para>
|
||||
linkend="v4l2-selection-flags"> constraint flags </link>.</para>
|
||||
|
||||
<section>
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ top/left corner at position <constant> (0,0) </constant>. The rectangle's
|
|||
coordinates are expressed in pixels.</para>
|
||||
|
||||
<para>The top left corner, width and height of the source rectangle, that is
|
||||
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP_ACTIVE
|
||||
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP
|
||||
</constant> target. It uses the same coordinate system as <constant>
|
||||
V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie
|
||||
completely inside the capture boundaries. The driver may further adjust the
|
||||
|
|
@ -111,13 +111,13 @@ height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>.
|
|||
</para>
|
||||
|
||||
<para>The part of a buffer into which the image is inserted by the hardware is
|
||||
controlled by the <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.
|
||||
controlled by the <constant> V4L2_SEL_TGT_COMPOSE </constant> target.
|
||||
The rectangle's coordinates are also expressed in the same coordinate system as
|
||||
the bounds rectangle. The composing rectangle must lie completely inside bounds
|
||||
rectangle. The driver must adjust the composing rectangle to fit to the
|
||||
bounding limits. Moreover, the driver can perform other adjustments according
|
||||
to hardware limitations. The application can control rounding behaviour using
|
||||
<link linkend="v4l2-sel-flags"> constraint flags </link>.</para>
|
||||
<link linkend="v4l2-selection-flags"> constraint flags </link>.</para>
|
||||
|
||||
<para>For capture devices the default composing rectangle is queried using
|
||||
<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the
|
||||
|
|
@ -125,7 +125,7 @@ bounding rectangle.</para>
|
|||
|
||||
<para>The part of a buffer that is modified by the hardware is given by
|
||||
<constant> V4L2_SEL_TGT_COMPOSE_PADDED </constant>. It contains all pixels
|
||||
defined using <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> plus all
|
||||
defined using <constant> V4L2_SEL_TGT_COMPOSE </constant> plus all
|
||||
padding data modified by hardware during insertion process. All pixels outside
|
||||
this rectangle <emphasis>must not</emphasis> be changed by the hardware. The
|
||||
content of pixels that lie inside the padded area but outside active area is
|
||||
|
|
@ -153,7 +153,7 @@ specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para>
|
|||
|
||||
<para>The top left corner, width and height of the source rectangle, that is
|
||||
the area from which image date are processed by the hardware, is given by the
|
||||
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant>. Its coordinates are expressed
|
||||
<constant> V4L2_SEL_TGT_CROP </constant>. Its coordinates are expressed
|
||||
in in the same coordinate system as the bounds rectangle. The active cropping
|
||||
area must lie completely inside the crop boundaries and the driver may further
|
||||
adjust the requested size and/or position according to hardware
|
||||
|
|
@ -165,7 +165,7 @@ bounding rectangle.</para>
|
|||
|
||||
<para>The part of a video signal or graphics display where the image is
|
||||
inserted by the hardware is controlled by <constant>
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target. The rectangle's coordinates
|
||||
V4L2_SEL_TGT_COMPOSE </constant> target. The rectangle's coordinates
|
||||
are expressed in pixels. The composing rectangle must lie completely inside the
|
||||
bounds rectangle. The driver must adjust the area to fit to the bounding
|
||||
limits. Moreover, the driver can perform other adjustments according to
|
||||
|
|
@ -184,7 +184,7 @@ such a padded area is driver-dependent feature not covered by this document.
|
|||
Driver developers are encouraged to keep padded rectangle equal to active one.
|
||||
The padded target is accessed by the <constant> V4L2_SEL_TGT_COMPOSE_PADDED
|
||||
</constant> identifier. It must contain all pixels from the <constant>
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
|
||||
V4L2_SEL_TGT_COMPOSE </constant> target.</para>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -193,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
|
|||
<title>Scaling control</title>
|
||||
|
||||
<para>An application can detect if scaling is performed by comparing the width
|
||||
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP_ACTIVE
|
||||
</constant> and <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> targets. If
|
||||
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP
|
||||
</constant> and <constant> V4L2_SEL_TGT_COMPOSE </constant> targets. If
|
||||
these are not equal then the scaling is applied. The application can compute
|
||||
the scaling ratios using these values.</para>
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ area)</para>
|
|||
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &sel);
|
||||
if (ret)
|
||||
exit(-1);
|
||||
sel.target = V4L2_SEL_TGT_CROP_ACTIVE;
|
||||
sel.target = V4L2_SEL_TGT_CROP;
|
||||
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &sel);
|
||||
if (ret)
|
||||
exit(-1);
|
||||
|
|
@ -281,7 +281,7 @@ area)</para>
|
|||
r.left = sel.r.width / 4;
|
||||
r.top = sel.r.height / 4;
|
||||
sel.r = r;
|
||||
sel.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
|
||||
sel.target = V4L2_SEL_TGT_COMPOSE;
|
||||
sel.flags = V4L2_SEL_FLAG_LE;
|
||||
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &sel);
|
||||
if (ret)
|
||||
|
|
@ -298,11 +298,11 @@ V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para>
|
|||
|
||||
&v4l2-selection; compose = {
|
||||
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
|
||||
.target = V4L2_SEL_TGT_COMPOSE_ACTIVE,
|
||||
.target = V4L2_SEL_TGT_COMPOSE,
|
||||
};
|
||||
&v4l2-selection; crop = {
|
||||
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
|
||||
.target = V4L2_SEL_TGT_CROP_ACTIVE,
|
||||
.target = V4L2_SEL_TGT_CROP,
|
||||
};
|
||||
double hscale, vscale;
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,179 @@
|
|||
<refentry id="vidioc-enum-freq-bands">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_ENUM_FREQ_BANDS</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_ENUM_FREQ_BANDS</refname>
|
||||
<refpurpose>Enumerate supported frequency bands</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_frequency_band
|
||||
*<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_ENUM_FREQ_BANDS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental"> experimental </link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>Enumerates the frequency bands that a tuner or modulator supports.
|
||||
To do this applications initialize the <structfield>tuner</structfield>,
|
||||
<structfield>type</structfield> and <structfield>index</structfield> fields,
|
||||
and zero out the <structfield>reserved</structfield> array of a &v4l2-frequency-band; and
|
||||
call the <constant>VIDIOC_ENUM_FREQ_BANDS</constant> ioctl with a pointer
|
||||
to this structure.</para>
|
||||
|
||||
<para>This ioctl is supported if the <constant>V4L2_TUNER_CAP_FREQ_BANDS</constant> capability
|
||||
of the corresponding tuner/modulator is set.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-frequency-band">
|
||||
<title>struct <structname>v4l2_frequency_band</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>tuner</structfield></entry>
|
||||
<entry>The tuner or modulator index number. This is the
|
||||
same value as in the &v4l2-input; <structfield>tuner</structfield>
|
||||
field and the &v4l2-tuner; <structfield>index</structfield> field, or
|
||||
the &v4l2-output; <structfield>modulator</structfield> field and the
|
||||
&v4l2-modulator; <structfield>index</structfield> field.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>The tuner type. This is the same value as in the
|
||||
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
|
||||
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
|
||||
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
|
||||
for all others. Set this field to <constant>V4L2_TUNER_RADIO</constant> for
|
||||
modulators (currently only radio modulators are supported).
|
||||
See <xref linkend="v4l2-tuner-type" /></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>Identifies the frequency band, set by the application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>capability</structfield></entry>
|
||||
<entry spanname="hspan">The tuner/modulator capability flags for
|
||||
this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant>
|
||||
capability must be the same for all frequency bands of the selected tuner/modulator.
|
||||
So either all bands have that capability set, or none of them have that capability.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>rangelow</structfield></entry>
|
||||
<entry spanname="hspan">The lowest tunable frequency in
|
||||
units of 62.5 kHz, or if the <structfield>capability</structfield>
|
||||
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
|
||||
Hz, for this frequency band.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>rangehigh</structfield></entry>
|
||||
<entry spanname="hspan">The highest tunable frequency in
|
||||
units of 62.5 kHz, or if the <structfield>capability</structfield>
|
||||
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
|
||||
Hz, for this frequency band.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>modulation</structfield></entry>
|
||||
<entry spanname="hspan">The supported modulation systems of this frequency band.
|
||||
See <xref linkend="band-modulation" />. Note that currently only one
|
||||
modulation system per frequency band is supported. More work will need to
|
||||
be done if multiple modulation systems are possible. Contact the
|
||||
linux-media mailing list (&v4l-ml;) if you need that functionality.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers
|
||||
must set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="band-modulation">
|
||||
<title>Band Modulation Systems</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_BAND_MODULATION_VSB</constant></entry>
|
||||
<entry>0x02</entry>
|
||||
<entry>Vestigial Sideband modulation, used for analog TV.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BAND_MODULATION_FM</constant></entry>
|
||||
<entry>0x04</entry>
|
||||
<entry>Frequency Modulation, commonly used for analog radio.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BAND_MODULATION_AM</constant></entry>
|
||||
<entry>0x08</entry>
|
||||
<entry>Amplitude Modulation, commonly used for analog radio.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <structfield>tuner</structfield> or <structfield>index</structfield>
|
||||
is out of bounds or the <structfield>type</structfield> field is wrong.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -98,11 +98,12 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
|
|||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>The tuner type. This is the same value as in the
|
||||
&v4l2-tuner; <structfield>type</structfield> field. See The type must be set
|
||||
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
|
||||
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
|
||||
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
|
||||
for all others. The field is not applicable to modulators, &ie; ignored
|
||||
by drivers. See <xref linkend="v4l2-tuner-type" /></entry>
|
||||
for all others. Set this field to <constant>V4L2_TUNER_RADIO</constant> for
|
||||
modulators (currently only radio modulators are supported).
|
||||
See <xref linkend="v4l2-tuner-type" /></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -135,6 +136,12 @@ bounds or the value in the <structfield>type</structfield> field is
|
|||
wrong.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>A hardware seek is in progress.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
|
|||
|
|
@ -65,9 +65,9 @@ Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
|||
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
|
||||
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> field
|
||||
to <constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
|
||||
to <constant> V4L2_SEL_TGT_CROP </constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
|
||||
targets. The <structfield>flags</structfield> and <structfield>reserved
|
||||
</structfield> fields of &v4l2-selection; are ignored and they must be filled
|
||||
with zeros. The driver fills the rest of the structure or
|
||||
|
|
@ -86,9 +86,9 @@ use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
|
|||
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
|
||||
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> to
|
||||
<constant>V4L2_SEL_TGT_CROP_ACTIVE</constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
|
||||
<constant>V4L2_SEL_TGT_CROP</constant> (<constant>
|
||||
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
|
||||
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
|
||||
targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
|
||||
set to the desired active area. Field &v4l2-selection; <structfield> reserved
|
||||
</structfield> is ignored and must be filled with zeros. The driver may adjust
|
||||
|
|
@ -154,74 +154,8 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
|||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<table frame="none" pgwide="1" id="v4l2-sel-target">
|
||||
<title>Selection targets.</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_CROP_ACTIVE</constant></entry>
|
||||
<entry>0x0000</entry>
|
||||
<entry>The area that is currently cropped by hardware.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>Limits for the cropping rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_ACTIVE</constant></entry>
|
||||
<entry>0x0100</entry>
|
||||
<entry>The area to which data is composed by hardware.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
|
||||
<entry>0x0101</entry>
|
||||
<entry>Suggested composing rectangle that covers the "whole picture".</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
|
||||
<entry>0x0102</entry>
|
||||
<entry>Limits for the composing rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
|
||||
<entry>0x0103</entry>
|
||||
<entry>The active area and all padding pixels that are inserted or modified by hardware.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<table frame="none" pgwide="1" id="v4l2-sel-flags">
|
||||
<title>Selection constraint flags</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
|
||||
<entry>0x00000001</entry>
|
||||
<entry>Indicates that the adjusted rectangle must contain the original
|
||||
&v4l2-selection; <structfield>r</structfield> rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>Indicates that the adjusted rectangle must be inside the original
|
||||
&v4l2-rect; <structfield>r</structfield> rectangle.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
|
||||
<section>
|
||||
<figure id="sel-const-adjust">
|
||||
|
|
@ -252,14 +186,14 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>target</structfield></entry>
|
||||
<entry>Used to select between <link linkend="v4l2-sel-target"> cropping
|
||||
<entry>Used to select between <link linkend="v4l2-selections-common"> cropping
|
||||
and composing rectangles</link>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Flags controlling the selection rectangle adjustments, refer to
|
||||
<link linkend="v4l2-sel-flags">selection flags</link>.</entry>
|
||||
<link linkend="v4l2-selection-flags">selection flags</link>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
|
|
|
|||
|
|
@ -119,10 +119,14 @@ field is not quite clear.--></para></entry>
|
|||
<xref linkend="tuner-capability" />. Audio flags indicate the ability
|
||||
to decode audio subprograms. They will <emphasis>not</emphasis>
|
||||
change, for example with the current video standard.</para><para>When
|
||||
the structure refers to a radio tuner only the
|
||||
<constant>V4L2_TUNER_CAP_LOW</constant>,
|
||||
<constant>V4L2_TUNER_CAP_STEREO</constant> and
|
||||
<constant>V4L2_TUNER_CAP_RDS</constant> flags can be set.</para></entry>
|
||||
the structure refers to a radio tuner the
|
||||
<constant>V4L2_TUNER_CAP_LANG1</constant>,
|
||||
<constant>V4L2_TUNER_CAP_LANG2</constant> and
|
||||
<constant>V4L2_TUNER_CAP_NORM</constant> flags can't be used.</para>
|
||||
<para>If multiple frequency bands are supported, then
|
||||
<structfield>capability</structfield> is the union of all
|
||||
<structfield>capability></structfield> fields of each &v4l2-frequency-band;.
|
||||
</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -130,7 +134,9 @@ the structure refers to a radio tuner only the
|
|||
<entry spanname="hspan">The lowest tunable frequency in
|
||||
units of 62.5 kHz, or if the <structfield>capability</structfield>
|
||||
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
|
||||
Hz.</entry>
|
||||
Hz. If multiple frequency bands are supported, then
|
||||
<structfield>rangelow</structfield> is the lowest frequency
|
||||
of all the frequency bands.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -138,7 +144,9 @@ Hz.</entry>
|
|||
<entry spanname="hspan">The highest tunable frequency in
|
||||
units of 62.5 kHz, or if the <structfield>capability</structfield>
|
||||
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
|
||||
Hz.</entry>
|
||||
Hz. If multiple frequency bands are supported, then
|
||||
<structfield>rangehigh</structfield> is the highest frequency
|
||||
of all the frequency bands.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -275,6 +283,18 @@ can or must be switched. (B/G PAL tuners for example are typically not
|
|||
see the description of ioctl &VIDIOC-ENUMINPUT; for details. Only
|
||||
<constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_TUNER_CAP_HWSEEK_BOUNDED</constant></entry>
|
||||
<entry>0x0004</entry>
|
||||
<entry>If set, then this tuner supports the hardware seek functionality
|
||||
where the seek stops when it reaches the end of the frequency range.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_TUNER_CAP_HWSEEK_WRAP</constant></entry>
|
||||
<entry>0x0008</entry>
|
||||
<entry>If set, then this tuner supports the hardware seek functionality
|
||||
where the seek wraps around when it reaches the end of the frequency range.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_TUNER_CAP_STEREO</constant></entry>
|
||||
<entry>0x0010</entry>
|
||||
|
|
@ -328,6 +348,12 @@ radio tuners.</entry>
|
|||
<entry>0x0200</entry>
|
||||
<entry>The RDS data is parsed by the hardware and set via controls.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_TUNER_CAP_FREQ_BANDS</constant></entry>
|
||||
<entry>0x0400</entry>
|
||||
<entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate
|
||||
the available frequency bands.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -71,12 +71,9 @@ initialize the <structfield>bytesused</structfield>,
|
|||
<structfield>field</structfield> and
|
||||
<structfield>timestamp</structfield> fields, see <xref
|
||||
linkend="buffer" /> for details.
|
||||
Applications must also set <structfield>flags</structfield> to 0. If a driver
|
||||
supports capturing from specific video inputs and you want to specify a video
|
||||
input, then <structfield>flags</structfield> should be set to
|
||||
<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
|
||||
<structfield>input</structfield> must be initialized to the desired input.
|
||||
The <structfield>reserved</structfield> field must be set to 0. When using
|
||||
Applications must also set <structfield>flags</structfield> to 0.
|
||||
The <structfield>reserved2</structfield> and
|
||||
<structfield>reserved</structfield> fields must be set to 0. When using
|
||||
the <link linkend="planar-apis">multi-planar API</link>, the
|
||||
<structfield>m.planes</structfield> field must contain a userspace pointer
|
||||
to a filled-in array of &v4l2-plane; and the <structfield>length</structfield>
|
||||
|
|
|
|||
|
|
@ -191,6 +191,19 @@ linkend="output">Video Output</link> interface.</entry>
|
|||
<link linkend="planar-apis">multi-planar API</link> through the
|
||||
<link linkend="output">Video Output</link> interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_M2M</constant></entry>
|
||||
<entry>0x00004000</entry>
|
||||
<entry>The device supports the single-planar API through the
|
||||
Video Memory-To-Memory interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant></entry>
|
||||
<entry>0x00008000</entry>
|
||||
<entry>The device supports the
|
||||
<link linkend="planar-apis">multi-planar API</link> through the
|
||||
Video Memory-To-Memory interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
|
||||
<entry>0x00000004</entry>
|
||||
|
|
|
|||
|
|
@ -52,11 +52,26 @@
|
|||
<para>Start a hardware frequency seek from the current frequency.
|
||||
To do this applications initialize the <structfield>tuner</structfield>,
|
||||
<structfield>type</structfield>, <structfield>seek_upward</structfield>,
|
||||
<structfield>spacing</structfield> and
|
||||
<structfield>wrap_around</structfield> fields, and zero out the
|
||||
<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
|
||||
call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
|
||||
to this structure.</para>
|
||||
<structfield>wrap_around</structfield>, <structfield>spacing</structfield>,
|
||||
<structfield>rangelow</structfield> and <structfield>rangehigh</structfield>
|
||||
fields, and zero out the <structfield>reserved</structfield> array of a
|
||||
&v4l2-hw-freq-seek; and call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
|
||||
ioctl with a pointer to this structure.</para>
|
||||
|
||||
<para>The <structfield>rangelow</structfield> and
|
||||
<structfield>rangehigh</structfield> fields can be set to a non-zero value to
|
||||
tell the driver to search a specific band. If the &v4l2-tuner;
|
||||
<structfield>capability</structfield> field has the
|
||||
<constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag set, these values
|
||||
must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If
|
||||
the <constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag is not set,
|
||||
then these values must exactly match those of one of the bands returned by
|
||||
&VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall
|
||||
within the selected band it will be clamped to fit in the band before the
|
||||
seek is started.</para>
|
||||
|
||||
<para>If an error is returned, then the original frequency will
|
||||
be restored.</para>
|
||||
|
||||
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
|
||||
|
||||
|
|
@ -87,7 +102,10 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>wrap_around</structfield></entry>
|
||||
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.</entry>
|
||||
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.
|
||||
The &v4l2-tuner; <structfield>capability</structfield> field will tell you what the
|
||||
hardware supports.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -96,7 +114,27 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
|
|||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[7]</entry>
|
||||
<entry><structfield>rangelow</structfield></entry>
|
||||
<entry>If non-zero, the lowest tunable frequency of the band to
|
||||
search in units of 62.5 kHz, or if the &v4l2-tuner;
|
||||
<structfield>capability</structfield> field has the
|
||||
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
|
||||
If <structfield>rangelow</structfield> is zero a reasonable default value
|
||||
is used.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>rangehigh</structfield></entry>
|
||||
<entry>If non-zero, the highest tunable frequency of the band to
|
||||
search in units of 62.5 kHz, or if the &v4l2-tuner;
|
||||
<structfield>capability</structfield> field has the
|
||||
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
|
||||
If <structfield>rangehigh</structfield> is zero a reasonable default value
|
||||
is used.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[5]</entry>
|
||||
<entry>Reserved for future extensions. Applications
|
||||
must set the array to zero.</entry>
|
||||
</row>
|
||||
|
|
@ -113,14 +151,22 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
|
|||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <structfield>tuner</structfield> index is out of
|
||||
bounds, the wrap_around value is not supported or the value in the <structfield>type</structfield> field is
|
||||
wrong.</para>
|
||||
bounds, the <structfield>wrap_around</structfield> value is not supported or
|
||||
one of the values in the <structfield>type</structfield>,
|
||||
<structfield>rangelow</structfield> or <structfield>rangehigh</structfield>
|
||||
fields is wrong.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EAGAIN</errorcode></term>
|
||||
<term><errorcode>ENODATA</errorcode></term>
|
||||
<listitem>
|
||||
<para>The ioctl timed-out. Try again.</para>
|
||||
<para>The hardware seek found no channels.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>Another hardware seek is already in progress.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
|
|||
|
|
@ -72,10 +72,10 @@
|
|||
<section>
|
||||
<title>Types of selection targets</title>
|
||||
|
||||
<para>There are two types of selection targets: actual and bounds.
|
||||
The ACTUAL targets are the targets which configure the hardware.
|
||||
The BOUNDS target will return a rectangle that contain all
|
||||
possible ACTUAL rectangles.</para>
|
||||
<para>There are two types of selection targets: actual and bounds. The
|
||||
actual targets are the targets which configure the hardware. The BOUNDS
|
||||
target will return a rectangle that contain all possible actual
|
||||
rectangles.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
@ -87,71 +87,8 @@
|
|||
<constant>EINVAL</constant>.</para>
|
||||
</section>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-selection-targets">
|
||||
<title>V4L2 subdev selection targets</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL</constant></entry>
|
||||
<entry>0x0000</entry>
|
||||
<entry>Actual crop. Defines the cropping
|
||||
performed by the processing step.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS</constant></entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>Bounds of the crop rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL</constant></entry>
|
||||
<entry>0x0100</entry>
|
||||
<entry>Actual compose rectangle. Used to configure scaling
|
||||
on sink pads and composition on source pads.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
|
||||
<entry>0x0102</entry>
|
||||
<entry>Bounds of the compose rectangle.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-selection-flags">
|
||||
<title>V4L2 subdev selection flags</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant></entry>
|
||||
<entry>(1 << 0)</entry> <entry>Suggest the driver it
|
||||
should choose greater or equal rectangle (in size) than
|
||||
was requested. Albeit the driver may choose a lesser size,
|
||||
it will only do so due to hardware limitations. Without
|
||||
this flag (and
|
||||
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant>) the
|
||||
behaviour is to choose the closest possible
|
||||
rectangle.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant></entry>
|
||||
<entry>(1 << 1)</entry> <entry>Suggest the driver it
|
||||
should choose lesser or equal rectangle (in size) than was
|
||||
requested. Albeit the driver may choose a greater size, it
|
||||
will only do so due to hardware limitations.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant></entry>
|
||||
<entry>(1 << 2)</entry>
|
||||
<entry>The configuration should not be propagated to any
|
||||
further processing steps. If this flag is not given, the
|
||||
configuration is propagated inside the subdevice to all
|
||||
further processing steps.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
<para>Selection targets and flags are documented in <xref
|
||||
linkend="v4l2-selections-common"/>.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-selection">
|
||||
<title>struct <structname>v4l2_subdev_selection</structname></title>
|
||||
|
|
@ -173,13 +110,13 @@
|
|||
<entry>__u32</entry>
|
||||
<entry><structfield>target</structfield></entry>
|
||||
<entry>Target selection rectangle. See
|
||||
<xref linkend="v4l2-subdev-selection-targets">.</xref>.</entry>
|
||||
<xref linkend="v4l2-selections-common" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Flags. See
|
||||
<xref linkend="v4l2-subdev-selection-flags">.</xref></entry>
|
||||
<xref linkend="v4l2-selection-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -22,7 +22,7 @@ Required properties:
|
|||
Example:
|
||||
|
||||
gpio0: gpio@73f84000 {
|
||||
compatible = "fsl,imx51-gpio", "fsl,imx31-gpio";
|
||||
compatible = "fsl,imx51-gpio", "fsl,imx35-gpio";
|
||||
reg = <0x73f84000 0x4000>;
|
||||
interrupts = <50 51>;
|
||||
gpio-controller;
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
Device tree configuration for i2c-ocores
|
||||
|
||||
Required properties:
|
||||
- compatible : "opencores,i2c-ocores"
|
||||
- reg : bus address start and address range size of device
|
||||
- interrupts : interrupt number
|
||||
- clock-frequency : frequency of bus clock in Hz
|
||||
- #address-cells : should be <1>
|
||||
- #size-cells : should be <0>
|
||||
|
||||
Optional properties:
|
||||
- reg-shift : device register offsets are shifted by this value
|
||||
- reg-io-width : io register width in bytes (1, 2 or 4)
|
||||
- regstep : deprecated, use reg-shift above
|
||||
|
||||
Example:
|
||||
|
||||
i2c0: ocores@a0000000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "opencores,i2c-ocores";
|
||||
reg = <0xa0000000 0x8>;
|
||||
interrupts = <10>;
|
||||
clock-frequency = <20000000>;
|
||||
|
||||
reg-shift = <0>; /* 8 bit registers */
|
||||
reg-io-width = <1>; /* 8 bit read/write */
|
||||
|
||||
dummy@60 {
|
||||
compatible = "dummy";
|
||||
reg = <0x60>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
* I2C
|
||||
* Marvell MMP I2C controller
|
||||
|
||||
Required properties :
|
||||
|
||||
|
|
@ -32,3 +32,20 @@ Examples:
|
|||
interrupts = <58>;
|
||||
};
|
||||
|
||||
* Marvell MV64XXX I2C controller
|
||||
|
||||
Required properties :
|
||||
|
||||
- reg : Offset and length of the register set for the device
|
||||
- compatible : Should be "marvell,mv64xxx-i2c"
|
||||
- interrupts : The interrupt number
|
||||
- clock-frequency : Desired I2C bus clock frequency in Hz.
|
||||
|
||||
Examples:
|
||||
|
||||
i2c@11000 {
|
||||
compatible = "marvell,mv64xxx-i2c";
|
||||
reg = <0x11000 0x20>;
|
||||
interrupts = <29>;
|
||||
clock-frequency = <100000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,28 @@
|
|||
NXP LPC32xx Key Scan Interface
|
||||
|
||||
Required Properties:
|
||||
- compatible: Should be "nxp,lpc3220-key"
|
||||
- reg: Physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: The interrupt number to the cpu.
|
||||
- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
|
||||
- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
|
||||
supports square matrices
|
||||
- nxp,debounce-delay-ms: Debounce delay in ms
|
||||
- nxp,scan-delay-ms: Repeated scan period in ms
|
||||
- linux,keymap: the key-code to be reported when the key is pressed
|
||||
and released, see also
|
||||
Documentation/devicetree/bindings/input/matrix-keymap.txt
|
||||
|
||||
Example:
|
||||
|
||||
key@40050000 {
|
||||
compatible = "nxp,lpc3220-key";
|
||||
reg = <0x40050000 0x1000>;
|
||||
interrupts = <54 0>;
|
||||
keypad,num-rows = <1>;
|
||||
keypad,num-columns = <1>;
|
||||
nxp,debounce-delay-ms = <3>;
|
||||
nxp,scan-delay-ms = <34>;
|
||||
linux,keymap = <0x00000002>;
|
||||
};
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
* TI's Keypad Controller device tree bindings
|
||||
|
||||
TI's Keypad controller is used to interface a SoC with a matrix-type
|
||||
keypad device. The keypad controller supports multiple row and column lines.
|
||||
A key can be placed at each intersection of a unique row and a unique column.
|
||||
The keypad controller can sense a key-press and key-release and report the
|
||||
event using a interrupt to the cpu.
|
||||
|
||||
Required SoC Specific Properties:
|
||||
- compatible: should be one of the following
|
||||
- "ti,omap4-keypad": For controllers compatible with omap4 keypad
|
||||
controller.
|
||||
|
||||
Required Board Specific Properties, in addition to those specified by
|
||||
the shared matrix-keyboard bindings:
|
||||
- keypad,num-rows: Number of row lines connected to the keypad
|
||||
controller.
|
||||
|
||||
- keypad,num-columns: Number of column lines connected to the
|
||||
keypad controller.
|
||||
|
||||
Optional Properties specific to linux:
|
||||
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
|
||||
|
||||
Example:
|
||||
keypad@4ae1c000{
|
||||
compatible = "ti,omap4-keypad";
|
||||
keypad,num-rows = <2>;
|
||||
keypad,num-columns = <8>;
|
||||
linux,keypad-no-autorepeat;
|
||||
};
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
Vibra driver for the twl6040 family
|
||||
|
||||
The vibra driver is a child of the twl6040 MFD dirver.
|
||||
Documentation/devicetree/bindings/mfd/twl6040.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "ti,twl6040-vibra";
|
||||
- interrupts: 4, Vibra overcurrent interrupt
|
||||
- vddvibl-supply: Regulator supplying the left vibra motor
|
||||
- vddvibr-supply: Regulator supplying the right vibra motor
|
||||
- vibldrv_res: Board specific left driver resistance
|
||||
- vibrdrv_res: Board specific right driver resistance
|
||||
- viblmotor_res: Board specific left motor resistance
|
||||
- vibrmotor_res: Board specific right motor resistance
|
||||
|
||||
Optional properties:
|
||||
- vddvibl_uV: If the vddvibl default voltage need to be changed
|
||||
- vddvibr_uV: If the vddvibr default voltage need to be changed
|
||||
|
||||
Example:
|
||||
/*
|
||||
* 8-channel high quality low-power audio codec
|
||||
* http://www.ti.com/lit/ds/symlink/twl6040.pdf
|
||||
*/
|
||||
twl6040: twl6040@4b {
|
||||
...
|
||||
twl6040_vibra: twl6040@1 {
|
||||
compatible = "ti,twl6040-vibra";
|
||||
interrupts = <4>;
|
||||
vddvibl-supply = <&vbat>;
|
||||
vddvibr-supply = <&vbat>;
|
||||
vibldrv_res = <8>;
|
||||
vibrdrv_res = <3>;
|
||||
viblmotor_res = <10>;
|
||||
vibrmotor_res = <10>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,123 @@
|
|||
* AB8500 Multi-Functional Device (MFD)
|
||||
|
||||
Required parent device properties:
|
||||
- compatible : contains "stericsson,ab8500";
|
||||
- interrupts : contains the IRQ line for the AB8500
|
||||
- interrupt-controller : describes the AB8500 as an Interrupt Controller (has its own domain)
|
||||
- #interrupt-cells : should be 2, for 2-cell format
|
||||
- The first cell is the AB8500 local IRQ number
|
||||
- The second cell is used to specify optional parameters
|
||||
- bits[3:0] trigger type and level flags:
|
||||
1 = low-to-high edge triggered
|
||||
2 = high-to-low edge triggered
|
||||
4 = active high level-sensitive
|
||||
8 = active low level-sensitive
|
||||
|
||||
Optional parent device properties:
|
||||
- reg : contains the PRCMU mailbox address for the AB8500 i2c port
|
||||
|
||||
The AB8500 consists of a large and varied group of sub-devices:
|
||||
|
||||
Device IRQ Names Supply Names Description
|
||||
------ --------- ------------ -----------
|
||||
ab8500-bm : : : Battery Manager
|
||||
ab8500-btemp : : : Battery Temperature
|
||||
ab8500-charger : : : Battery Charger
|
||||
ab8500-fg : : : Fuel Gauge
|
||||
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter
|
||||
SW_CONV_END : :
|
||||
ab8500-gpio : : : GPIO Controller
|
||||
ab8500-ponkey : ONKEY_DBF : : Power-on Key
|
||||
ONKEY_DBR : :
|
||||
ab8500-pwm : : : Pulse Width Modulator
|
||||
ab8500-regulator : : : Regulators
|
||||
ab8500-rtc : 60S : : Real Time Clock
|
||||
: ALARM : :
|
||||
ab8500-sysctrl : : : System Control
|
||||
ab8500-usb : ID_WAKEUP_R : vddulpivio18 : Universal Serial Bus
|
||||
: ID_WAKEUP_F : v-ape :
|
||||
: VBUS_DET_F : musb_1v8 :
|
||||
: VBUS_DET_R : :
|
||||
: USB_LINK_STATUS : :
|
||||
: USB_ADP_PROBE_PLUG : :
|
||||
: USB_ADP_PROBE_UNPLUG : :
|
||||
|
||||
Required child device properties:
|
||||
- compatible : "stericsson,ab8500-[bm|btemp|charger|fg|gpadc|gpio|ponkey|
|
||||
pwm|regulator|rtc|sysctrl|usb]";
|
||||
|
||||
Optional child device properties:
|
||||
- interrupts : contains the device IRQ(s) using the 2-cell format (see above)
|
||||
- interrupt-names : contains names of IRQ resource in the order in which they were
|
||||
supplied in the interrupts property
|
||||
- <supply_name>-supply : contains a phandle to the regulator supply node in Device Tree
|
||||
|
||||
ab8500@5 {
|
||||
compatible = "stericsson,ab8500";
|
||||
reg = <5>; /* mailbox 5 is i2c */
|
||||
interrupts = <0 40 0x4>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
ab8500-rtc {
|
||||
compatible = "stericsson,ab8500-rtc";
|
||||
interrupts = <17 0x4
|
||||
18 0x4>;
|
||||
interrupt-names = "60S", "ALARM";
|
||||
};
|
||||
|
||||
ab8500-gpadc {
|
||||
compatible = "stericsson,ab8500-gpadc";
|
||||
interrupts = <32 0x4
|
||||
39 0x4>;
|
||||
interrupt-names = "HW_CONV_END", "SW_CONV_END";
|
||||
vddadc-supply = <&ab8500_ldo_tvout_reg>;
|
||||
};
|
||||
|
||||
ab8500-usb {
|
||||
compatible = "stericsson,ab8500-usb";
|
||||
interrupts = < 90 0x4
|
||||
96 0x4
|
||||
14 0x4
|
||||
15 0x4
|
||||
79 0x4
|
||||
74 0x4
|
||||
75 0x4>;
|
||||
interrupt-names = "ID_WAKEUP_R",
|
||||
"ID_WAKEUP_F",
|
||||
"VBUS_DET_F",
|
||||
"VBUS_DET_R",
|
||||
"USB_LINK_STATUS",
|
||||
"USB_ADP_PROBE_PLUG",
|
||||
"USB_ADP_PROBE_UNPLUG";
|
||||
vddulpivio18-supply = <&ab8500_ldo_initcore_reg>;
|
||||
v-ape-supply = <&db8500_vape_reg>;
|
||||
musb_1v8-supply = <&db8500_vsmps2_reg>;
|
||||
};
|
||||
|
||||
ab8500-ponkey {
|
||||
compatible = "stericsson,ab8500-ponkey";
|
||||
interrupts = <6 0x4
|
||||
7 0x4>;
|
||||
interrupt-names = "ONKEY_DBF", "ONKEY_DBR";
|
||||
};
|
||||
|
||||
ab8500-sysctrl {
|
||||
compatible = "stericsson,ab8500-sysctrl";
|
||||
};
|
||||
|
||||
ab8500-pwm {
|
||||
compatible = "stericsson,ab8500-pwm";
|
||||
};
|
||||
|
||||
ab8500-regulators {
|
||||
compatible = "stericsson,ab8500-regulator";
|
||||
|
||||
ab8500_ldo_aux1_reg: ab8500_ldo_aux1 {
|
||||
/*
|
||||
* See: Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
* for more information on regulators
|
||||
*/
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
Maxim MAX77686 multi-function device
|
||||
|
||||
MAX77686 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is
|
||||
interfaced to host controller using i2c interface. PMIC and Charger submodules
|
||||
are addressed using same i2c slave address whereas RTC submodule uses
|
||||
different i2c slave address,presently for which we are statically creating i2c
|
||||
client while probing.This document describes the binding for mfd device and
|
||||
PMIC submodule.
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "maxim,max77686";
|
||||
- reg : Specifies the i2c slave address of PMIC block.
|
||||
- interrupts : This i2c device has an IRQ line connected to the main SoC.
|
||||
- interrupt-parent : The parent interrupt controller.
|
||||
|
||||
Optional node:
|
||||
- voltage-regulators : The regulators of max77686 have to be instantiated
|
||||
under subnode named "voltage-regulators" using the following format.
|
||||
|
||||
regulator_name {
|
||||
regulator-compatible = LDOn/BUCKn
|
||||
standard regulator constraints....
|
||||
};
|
||||
refer Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
The regulator-compatible property of regulator should initialized with string
|
||||
to get matched with their hardware counterparts as follow:
|
||||
|
||||
-LDOn : for LDOs, where n can lie in range 1 to 26.
|
||||
example: LDO1, LDO2, LDO26.
|
||||
-BUCKn : for BUCKs, where n can lie in range 1 to 9.
|
||||
example: BUCK1, BUCK5, BUCK9.
|
||||
|
||||
Example:
|
||||
|
||||
max77686@09 {
|
||||
compatible = "maxim,max77686";
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
interrupts = <26 0>;
|
||||
reg = <0x09>;
|
||||
|
||||
voltage-regulators {
|
||||
ldo11_reg {
|
||||
regulator-compatible = "LDO11";
|
||||
regulator-name = "vdd_ldo11";
|
||||
regulator-min-microvolt = <1900000>;
|
||||
regulator-max-microvolt = <1900000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
buck1_reg {
|
||||
regulator-compatible = "BUCK1";
|
||||
regulator-name = "vdd_mif";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1300000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
}
|
||||
|
|
@ -81,7 +81,7 @@ Example:
|
|||
|
||||
ti,vmbch-threshold = 0;
|
||||
ti,vmbch2-threshold = 0;
|
||||
|
||||
ti,en-ck32k-xtal;
|
||||
ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>;
|
||||
|
||||
vcc1-supply = <®_parent>;
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ They are connected ot the host processor via i2c for commands, McPDM for audio
|
|||
data and commands.
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "ti,twl6040";
|
||||
- compatible : "ti,twl6040" for twl6040, "ti,twl6041" for twl6041
|
||||
- reg: must be 0x4b for i2c address
|
||||
- interrupts: twl6040 has one interrupt line connecteded to the main SoC
|
||||
- interrupt-parent: The parent interrupt controller
|
||||
|
|
|
|||
|
|
@ -0,0 +1,126 @@
|
|||
* Boot Bus
|
||||
|
||||
The Octeon Boot Bus is a configurable parallel bus with 8 chip
|
||||
selects. Each chip select is independently configurable.
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-3860-bootbus"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
|
||||
|
||||
- reg: The base address of the Boot Bus' register bank.
|
||||
|
||||
- #address-cells: Must be <2>. The first cell is the chip select
|
||||
within the bootbus. The second cell is the offset from the chip select.
|
||||
|
||||
- #size-cells: Must be <1>.
|
||||
|
||||
- ranges: There must be one one triplet of (child-bus-address,
|
||||
parent-bus-address, length) for each active chip select. If the
|
||||
length element for any triplet is zero, the chip select is disabled,
|
||||
making it inactive.
|
||||
|
||||
The configuration parameters for each chip select are stored in child
|
||||
nodes.
|
||||
|
||||
Configuration Properties:
|
||||
- compatible: "cavium,octeon-3860-bootbus-config"
|
||||
|
||||
- cavium,cs-index: A single cell indicating the chip select that
|
||||
corresponds to this configuration.
|
||||
|
||||
- cavium,t-adr: A cell specifying the ADR timing (in nS).
|
||||
|
||||
- cavium,t-ce: A cell specifying the CE timing (in nS).
|
||||
|
||||
- cavium,t-oe: A cell specifying the OE timing (in nS).
|
||||
|
||||
- cavium,t-we: A cell specifying the WE timing (in nS).
|
||||
|
||||
- cavium,t-rd-hld: A cell specifying the RD_HLD timing (in nS).
|
||||
|
||||
- cavium,t-wr-hld: A cell specifying the WR_HLD timing (in nS).
|
||||
|
||||
- cavium,t-pause: A cell specifying the PAUSE timing (in nS).
|
||||
|
||||
- cavium,t-wait: A cell specifying the WAIT timing (in nS).
|
||||
|
||||
- cavium,t-page: A cell specifying the PAGE timing (in nS).
|
||||
|
||||
- cavium,t-rd-dly: A cell specifying the RD_DLY timing (in nS).
|
||||
|
||||
- cavium,pages: A cell specifying the PAGES parameter (0 = 8 bytes, 1
|
||||
= 2 bytes, 2 = 4 bytes, 3 = 8 bytes).
|
||||
|
||||
- cavium,wait-mode: Optional. If present, wait mode (WAITM) is selected.
|
||||
|
||||
- cavium,page-mode: Optional. If present, page mode (PAGEM) is selected.
|
||||
|
||||
- cavium,bus-width: A cell specifying the WIDTH parameter (in bits) of
|
||||
the bus for this chip select.
|
||||
|
||||
- cavium,ale-mode: Optional. If present, ALE mode is selected.
|
||||
|
||||
- cavium,sam-mode: Optional. If present, SAM mode is selected.
|
||||
|
||||
- cavium,or-mode: Optional. If present, OR mode is selected.
|
||||
|
||||
Example:
|
||||
bootbus: bootbus@1180000000000 {
|
||||
compatible = "cavium,octeon-3860-bootbus";
|
||||
reg = <0x11800 0x00000000 0x0 0x200>;
|
||||
/* The chip select number and offset */
|
||||
#address-cells = <2>;
|
||||
/* The size of the chip select region */
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0 0x0 0x1f400000 0xc00000>,
|
||||
<1 0 0x10000 0x30000000 0>,
|
||||
<2 0 0x10000 0x40000000 0>,
|
||||
<3 0 0x10000 0x50000000 0>,
|
||||
<4 0 0x0 0x1d020000 0x10000>,
|
||||
<5 0 0x0 0x1d040000 0x10000>,
|
||||
<6 0 0x0 0x1d050000 0x10000>,
|
||||
<7 0 0x10000 0x90000000 0>;
|
||||
|
||||
cavium,cs-config@0 {
|
||||
compatible = "cavium,octeon-3860-bootbus-config";
|
||||
cavium,cs-index = <0>;
|
||||
cavium,t-adr = <20>;
|
||||
cavium,t-ce = <60>;
|
||||
cavium,t-oe = <60>;
|
||||
cavium,t-we = <45>;
|
||||
cavium,t-rd-hld = <35>;
|
||||
cavium,t-wr-hld = <45>;
|
||||
cavium,t-pause = <0>;
|
||||
cavium,t-wait = <0>;
|
||||
cavium,t-page = <35>;
|
||||
cavium,t-rd-dly = <0>;
|
||||
|
||||
cavium,pages = <0>;
|
||||
cavium,bus-width = <8>;
|
||||
};
|
||||
.
|
||||
.
|
||||
.
|
||||
cavium,cs-config@6 {
|
||||
compatible = "cavium,octeon-3860-bootbus-config";
|
||||
cavium,cs-index = <6>;
|
||||
cavium,t-adr = <5>;
|
||||
cavium,t-ce = <300>;
|
||||
cavium,t-oe = <270>;
|
||||
cavium,t-we = <150>;
|
||||
cavium,t-rd-hld = <100>;
|
||||
cavium,t-wr-hld = <70>;
|
||||
cavium,t-pause = <0>;
|
||||
cavium,t-wait = <0>;
|
||||
cavium,t-page = <320>;
|
||||
cavium,t-rd-dly = <0>;
|
||||
|
||||
cavium,pages = <0>;
|
||||
cavium,wait-mode;
|
||||
cavium,bus-width = <16>;
|
||||
};
|
||||
.
|
||||
.
|
||||
.
|
||||
};
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
* Central Interrupt Unit
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-3860-ciu"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn63XX SOCs.
|
||||
|
||||
- interrupt-controller: This is an interrupt controller.
|
||||
|
||||
- reg: The base address of the CIU's register bank.
|
||||
|
||||
- #interrupt-cells: Must be <2>. The first cell is the bank within
|
||||
the CIU and may have a value of 0 or 1. The second cell is the bit
|
||||
within the bank and may have a value between 0 and 63.
|
||||
|
||||
Example:
|
||||
interrupt-controller@1070000000000 {
|
||||
compatible = "cavium,octeon-3860-ciu";
|
||||
interrupt-controller;
|
||||
/* Interrupts are specified by two parts:
|
||||
* 1) Controller register (0 or 1)
|
||||
* 2) Bit within the register (0..63)
|
||||
*/
|
||||
#interrupt-cells = <2>;
|
||||
reg = <0x10700 0x00000000 0x0 0x7000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
* Central Interrupt Unit
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-6880-ciu2"
|
||||
|
||||
Compatibility with 68XX SOCs.
|
||||
|
||||
- interrupt-controller: This is an interrupt controller.
|
||||
|
||||
- reg: The base address of the CIU's register bank.
|
||||
|
||||
- #interrupt-cells: Must be <2>. The first cell is the bank within
|
||||
the CIU and may have a value between 0 and 63. The second cell is
|
||||
the bit within the bank and may also have a value between 0 and 63.
|
||||
|
||||
Example:
|
||||
interrupt-controller@1070100000000 {
|
||||
compatible = "cavium,octeon-6880-ciu2";
|
||||
interrupt-controller;
|
||||
/* Interrupts are specified by two parts:
|
||||
* 1) Controller register (0..63)
|
||||
* 2) Bit within the register (0..63)
|
||||
*/
|
||||
#address-cells = <0>;
|
||||
#interrupt-cells = <2>;
|
||||
reg = <0x10701 0x00000000 0x0 0x4000000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
* DMA Engine.
|
||||
|
||||
The Octeon DMA Engine transfers between the Boot Bus and main memory.
|
||||
The DMA Engine will be refered to by phandle by any device that is
|
||||
connected to it.
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-5750-bootbus-dma"
|
||||
|
||||
Compatibility with all cn52XX, cn56XX and cn6XXX SOCs.
|
||||
|
||||
- reg: The base address of the DMA Engine's register bank.
|
||||
|
||||
- interrupts: A single interrupt specifier.
|
||||
|
||||
Example:
|
||||
dma0: dma-engine@1180000000100 {
|
||||
compatible = "cavium,octeon-5750-bootbus-dma";
|
||||
reg = <0x11800 0x00000100 0x0 0x8>;
|
||||
interrupts = <0 63>;
|
||||
};
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
* UCTL USB controller glue
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-6335-uctl"
|
||||
|
||||
Compatibility with all cn6XXX SOCs.
|
||||
|
||||
- reg: The base address of the UCTL register bank.
|
||||
|
||||
- #address-cells: Must be <2>.
|
||||
|
||||
- #size-cells: Must be <2>.
|
||||
|
||||
- ranges: Empty to signify direct mapping of the children.
|
||||
|
||||
- refclk-frequency: A single cell containing the reference clock
|
||||
frequency in Hz.
|
||||
|
||||
- refclk-type: A string describing the reference clock connection
|
||||
either "crystal" or "external".
|
||||
|
||||
Example:
|
||||
uctl@118006f000000 {
|
||||
compatible = "cavium,octeon-6335-uctl";
|
||||
reg = <0x11800 0x6f000000 0x0 0x100>;
|
||||
ranges; /* Direct mapping */
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
/* 12MHz, 24MHz and 48MHz allowed */
|
||||
refclk-frequency = <24000000>;
|
||||
/* Either "crystal" or "external" */
|
||||
refclk-type = "crystal";
|
||||
|
||||
ehci@16f0000000000 {
|
||||
compatible = "cavium,octeon-6335-ehci","usb-ehci";
|
||||
reg = <0x16f00 0x00000000 0x0 0x100>;
|
||||
interrupts = <0 56>;
|
||||
big-endian-regs;
|
||||
};
|
||||
ohci@16f0000000400 {
|
||||
compatible = "cavium,octeon-6335-ohci","usb-ohci";
|
||||
reg = <0x16f00 0x00000400 0x0 0x100>;
|
||||
interrupts = <0 56>;
|
||||
big-endian-regs;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
Atmel AT25 eeprom
|
||||
|
||||
Required properties:
|
||||
- compatible : "atmel,at25".
|
||||
- reg : chip select number
|
||||
- spi-max-frequency : max spi frequency to use
|
||||
|
||||
- at25,byte-len : total eeprom size in bytes
|
||||
- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h
|
||||
- at25,page-size : size of the eeprom page
|
||||
|
||||
Examples:
|
||||
at25@0 {
|
||||
compatible = "atmel,at25";
|
||||
reg = <0>
|
||||
spi-max-frequency = <5000000>;
|
||||
|
||||
at25,byte-len = <0x8000>;
|
||||
at25,addr-mode = <2>;
|
||||
at25,page-size = <64>;
|
||||
};
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
NAND support for Marvell Orion SoC platforms
|
||||
|
||||
Required properties:
|
||||
- compatible : "mrvl,orion-nand".
|
||||
- compatible : "marvell,orion-nand".
|
||||
- reg : Base physical address of the NAND and length of memory mapped
|
||||
region
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ nand@f4000000 {
|
|||
ale = <1>;
|
||||
bank-width = <1>;
|
||||
chip-delay = <25>;
|
||||
compatible = "mrvl,orion-nand";
|
||||
compatible = "marvell,orion-nand";
|
||||
reg = <0xf4000000 0x400>;
|
||||
|
||||
partition@0 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,27 @@
|
|||
* System Management Interface (SMI) / MDIO
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-3860-mdio"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
|
||||
|
||||
- reg: The base address of the MDIO bus controller register bank.
|
||||
|
||||
- #address-cells: Must be <1>.
|
||||
|
||||
- #size-cells: Must be <0>. MDIO addresses have no size component.
|
||||
|
||||
Typically an MDIO bus might have several children.
|
||||
|
||||
Example:
|
||||
mdio@1180000001800 {
|
||||
compatible = "cavium,octeon-3860-mdio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x11800 0x00001800 0x0 0x40>;
|
||||
|
||||
ethernet-phy@0 {
|
||||
...
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
* MIX Ethernet controller.
|
||||
|
||||
Properties:
|
||||
- compatible: "cavium,octeon-5750-mix"
|
||||
|
||||
Compatibility with all cn5XXX and cn6XXX SOCs populated with MIX
|
||||
devices.
|
||||
|
||||
- reg: The base addresses of four separate register banks. The first
|
||||
bank contains the MIX registers. The second bank the corresponding
|
||||
AGL registers. The third bank are the AGL registers shared by all
|
||||
MIX devices present. The fourth bank is the AGL_PRT_CTL shared by
|
||||
all MIX devices present.
|
||||
|
||||
- cell-index: A single cell specifying which portion of the shared
|
||||
register banks corresponds to this MIX device.
|
||||
|
||||
- interrupts: Two interrupt specifiers. The first is the MIX
|
||||
interrupt routing and the second the routing for the AGL interrupts.
|
||||
|
||||
- mac-address: Optional, the MAC address to assign to the device.
|
||||
|
||||
- local-mac-address: Optional, the MAC address to assign to the device
|
||||
if mac-address is not specified.
|
||||
|
||||
- phy-handle: Optional, a phandle for the PHY device connected to this device.
|
||||
|
||||
Example:
|
||||
ethernet@1070000100800 {
|
||||
compatible = "cavium,octeon-5750-mix";
|
||||
reg = <0x10700 0x00100800 0x0 0x100>, /* MIX */
|
||||
<0x11800 0xE0000800 0x0 0x300>, /* AGL */
|
||||
<0x11800 0xE0000400 0x0 0x400>, /* AGL_SHARED */
|
||||
<0x11800 0xE0002008 0x0 0x8>; /* AGL_PRT_CTL */
|
||||
cell-index = <1>;
|
||||
interrupts = <1 18>, < 1 46>;
|
||||
local-mac-address = [ 00 0f b7 10 63 54 ];
|
||||
phy-handle = <&phy1>;
|
||||
};
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
* PIP Ethernet nexus.
|
||||
|
||||
The PIP Ethernet nexus can control several data packet input/output
|
||||
devices. The devices have a two level grouping scheme. There may be
|
||||
several interfaces, and each interface may have several ports. These
|
||||
ports might be an individual Ethernet PHY.
|
||||
|
||||
|
||||
Properties for the PIP nexus:
|
||||
- compatible: "cavium,octeon-3860-pip"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
|
||||
|
||||
- reg: The base address of the PIP's register bank.
|
||||
|
||||
- #address-cells: Must be <1>.
|
||||
|
||||
- #size-cells: Must be <0>.
|
||||
|
||||
Properties for PIP interfaces which is a child the PIP nexus:
|
||||
- compatible: "cavium,octeon-3860-pip-interface"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
|
||||
|
||||
- reg: The interface number.
|
||||
|
||||
- #address-cells: Must be <1>.
|
||||
|
||||
- #size-cells: Must be <0>.
|
||||
|
||||
Properties for PIP port which is a child the PIP interface:
|
||||
- compatible: "cavium,octeon-3860-pip-port"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
|
||||
|
||||
- reg: The port number within the interface group.
|
||||
|
||||
- mac-address: Optional, the MAC address to assign to the device.
|
||||
|
||||
- local-mac-address: Optional, the MAC address to assign to the device
|
||||
if mac-address is not specified.
|
||||
|
||||
- phy-handle: Optional, a phandle for the PHY device connected to this device.
|
||||
|
||||
Example:
|
||||
|
||||
pip@11800a0000000 {
|
||||
compatible = "cavium,octeon-3860-pip";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x11800 0xa0000000 0x0 0x2000>;
|
||||
|
||||
interface@0 {
|
||||
compatible = "cavium,octeon-3860-pip-interface";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>; /* interface */
|
||||
|
||||
ethernet@0 {
|
||||
compatible = "cavium,octeon-3860-pip-port";
|
||||
reg = <0x0>; /* Port */
|
||||
local-mac-address = [ 00 0f b7 10 63 60 ];
|
||||
phy-handle = <&phy2>;
|
||||
};
|
||||
ethernet@1 {
|
||||
compatible = "cavium,octeon-3860-pip-port";
|
||||
reg = <0x1>; /* Port */
|
||||
local-mac-address = [ 00 0f b7 10 63 61 ];
|
||||
phy-handle = <&phy3>;
|
||||
};
|
||||
ethernet@2 {
|
||||
compatible = "cavium,octeon-3860-pip-port";
|
||||
reg = <0x2>; /* Port */
|
||||
local-mac-address = [ 00 0f b7 10 63 62 ];
|
||||
phy-handle = <&phy4>;
|
||||
};
|
||||
ethernet@3 {
|
||||
compatible = "cavium,octeon-3860-pip-port";
|
||||
reg = <0x3>; /* Port */
|
||||
local-mac-address = [ 00 0f b7 10 63 63 ];
|
||||
phy-handle = <&phy5>;
|
||||
};
|
||||
};
|
||||
|
||||
interface@1 {
|
||||
compatible = "cavium,octeon-3860-pip-interface";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>; /* interface */
|
||||
|
||||
ethernet@0 {
|
||||
compatible = "cavium,octeon-3860-pip-port";
|
||||
reg = <0x0>; /* Port */
|
||||
local-mac-address = [ 00 0f b7 10 63 64 ];
|
||||
phy-handle = <&phy6>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
LPC32XX PWM controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "nxp,lpc3220-pwm"
|
||||
- reg: physical base address and length of the controller's registers
|
||||
|
||||
Examples:
|
||||
|
||||
pwm@0x4005C000 {
|
||||
compatible = "nxp,lpc3220-pwm";
|
||||
reg = <0x4005C000 0x8>;
|
||||
};
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
Freescale MXS PWM controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "fsl,imx23-pwm"
|
||||
- reg: physical base address and length of the controller's registers
|
||||
- #pwm-cells: should be 2. The first cell specifies the per-chip index
|
||||
of the PWM to use and the second cell is the duty cycle in nanoseconds.
|
||||
- fsl,pwm-number: the number of PWM devices
|
||||
|
||||
Example:
|
||||
|
||||
pwm: pwm@80064000 {
|
||||
compatible = "fsl,imx28-pwm", "fsl,imx23-pwm";
|
||||
reg = <0x80064000 2000>;
|
||||
#pwm-cells = <2>;
|
||||
fsl,pwm-number = <8>;
|
||||
};
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
Tegra SoC PWFM controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be one of:
|
||||
- "nvidia,tegra20-pwm"
|
||||
- "nvidia,tegra30-pwm"
|
||||
- reg: physical base address and length of the controller's registers
|
||||
- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
|
||||
first cell specifies the per-chip index of the PWM to use and the second
|
||||
cell is the duty cycle in nanoseconds.
|
||||
|
||||
Example:
|
||||
|
||||
pwm: pwm@7000a000 {
|
||||
compatible = "nvidia,tegra20-pwm";
|
||||
reg = <0x7000a000 0x100>;
|
||||
#pwm-cells = <2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
Specifying PWM information for devices
|
||||
======================================
|
||||
|
||||
1) PWM user nodes
|
||||
-----------------
|
||||
|
||||
PWM users should specify a list of PWM devices that they want to use
|
||||
with a property containing a 'pwm-list':
|
||||
|
||||
pwm-list ::= <single-pwm> [pwm-list]
|
||||
single-pwm ::= <pwm-phandle> <pwm-specifier>
|
||||
pwm-phandle : phandle to PWM controller node
|
||||
pwm-specifier : array of #pwm-cells specifying the given PWM
|
||||
(controller specific)
|
||||
|
||||
PWM properties should be named "pwms". The exact meaning of each pwms
|
||||
property must be documented in the device tree binding for each device.
|
||||
An optional property "pwm-names" may contain a list of strings to label
|
||||
each of the PWM devices listed in the "pwms" property. If no "pwm-names"
|
||||
property is given, the name of the user node will be used as fallback.
|
||||
|
||||
Drivers for devices that use more than a single PWM device can use the
|
||||
"pwm-names" property to map the name of the PWM device requested by the
|
||||
pwm_get() call to an index into the list given by the "pwms" property.
|
||||
|
||||
The following example could be used to describe a PWM-based backlight
|
||||
device:
|
||||
|
||||
pwm: pwm {
|
||||
#pwm-cells = <2>;
|
||||
};
|
||||
|
||||
[...]
|
||||
|
||||
bl: backlight {
|
||||
pwms = <&pwm 0 5000000>;
|
||||
pwm-names = "backlight";
|
||||
};
|
||||
|
||||
pwm-specifier typically encodes the chip-relative PWM number and the PWM
|
||||
period in nanoseconds. Note that in the example above, specifying the
|
||||
"pwm-names" is redundant because the name "backlight" would be used as
|
||||
fallback anyway.
|
||||
|
||||
2) PWM controller nodes
|
||||
-----------------------
|
||||
|
||||
PWM controller nodes must specify the number of cells used for the
|
||||
specifier using the '#pwm-cells' property.
|
||||
|
||||
An example PWM controller might look like this:
|
||||
|
||||
pwm: pwm@7000a000 {
|
||||
compatible = "nvidia,tegra20-pwm";
|
||||
reg = <0x7000a000 0x100>;
|
||||
#pwm-cells = <2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
* Universal Asynchronous Receiver/Transmitter (UART)
|
||||
|
||||
- compatible: "cavium,octeon-3860-uart"
|
||||
|
||||
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
|
||||
|
||||
- reg: The base address of the UART register bank.
|
||||
|
||||
- interrupts: A single interrupt specifier.
|
||||
|
||||
- current-speed: Optional, the current bit rate in bits per second.
|
||||
|
||||
Example:
|
||||
uart1: serial@1180000000c00 {
|
||||
compatible = "cavium,octeon-3860-uart","ns16550";
|
||||
reg = <0x11800 0x00000c00 0x0 0x400>;
|
||||
current-speed = <115200>;
|
||||
interrupts = <0 35>;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
Marvell Orion SPI device
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "marvell,orion-spi".
|
||||
- reg : offset and length of the register set for the device
|
||||
- cell-index : Which of multiple SPI controllers is this.
|
||||
Optional properties:
|
||||
- interrupts : Is currently not used.
|
||||
|
||||
Example:
|
||||
spi@10600 {
|
||||
compatible = "marvell,orion-spi";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
cell-index = <0>;
|
||||
reg = <0x10600 0x28>;
|
||||
interrupts = <23>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
* SPEAr Thermal
|
||||
|
||||
Required properties:
|
||||
- compatible : "st,thermal-spear1340"
|
||||
- reg : Address range of the thermal registers
|
||||
- st,thermal-flags: flags used to enable thermal sensor
|
||||
|
||||
Example:
|
||||
|
||||
thermal@fc000000 {
|
||||
compatible = "st,thermal-spear1340";
|
||||
reg = <0xfc000000 0x1000>;
|
||||
st,thermal-flags = <0x7000>;
|
||||
};
|
||||
|
|
@ -9,6 +9,7 @@ Required properties:
|
|||
- "ns16750"
|
||||
- "ns16850"
|
||||
- "nvidia,tegra20-uart"
|
||||
- "nxp,lpc3220-uart"
|
||||
- "ibm,qpace-nwp-serial"
|
||||
- "serial" if the port type is unknown.
|
||||
- reg : offset and length of the register set for the device.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
* Freescale i.MX ci13xxx usb controllers
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx27-usb"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain controller interrupt
|
||||
|
||||
Optional properties:
|
||||
- fsl,usbphy: phandler of usb phy that connects to the only one port
|
||||
- vbus-supply: regulator for vbus
|
||||
|
||||
Examples:
|
||||
usb@02184000 { /* USB OTG */
|
||||
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
|
||||
reg = <0x02184000 0x200>;
|
||||
interrupts = <0 43 0x04>;
|
||||
fsl,usbphy = <&usbphy1>;
|
||||
};
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
* Freescale MXS USB Phy Device
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx23-usbphy"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain phy interrupt
|
||||
|
||||
Example:
|
||||
usbphy1: usbphy@020c9000 {
|
||||
compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
|
||||
reg = <0x020c9000 0x1000>;
|
||||
interrupts = <0 44 0x04>;
|
||||
};
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
pwm-backlight bindings
|
||||
|
||||
Required properties:
|
||||
- compatible: "pwm-backlight"
|
||||
- pwms: OF device-tree PWM specification (see PWM binding[0])
|
||||
- brightness-levels: Array of distinct brightness levels. Typically these
|
||||
are in the range from 0 to 255, but any range starting at 0 will do.
|
||||
The actual brightness level (PWM duty cycle) will be interpolated
|
||||
from these values. 0 means a 0% duty cycle (darkest/off), while the
|
||||
last value in the array represents a 100% duty cycle (brightest).
|
||||
- default-brightness-level: the default brightness level (index into the
|
||||
array defined by the "brightness-levels" property)
|
||||
|
||||
Optional properties:
|
||||
- pwm-names: a list of names for the PWM devices specified in the
|
||||
"pwms" property (see PWM binding[0])
|
||||
|
||||
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
|
||||
|
||||
Example:
|
||||
|
||||
backlight {
|
||||
compatible = "pwm-backlight";
|
||||
pwms = <&pwm 0 5000000>;
|
||||
|
||||
brightness-levels = <0 4 8 16 32 64 128 255>;
|
||||
default-brightness-level = <6>;
|
||||
};
|
||||
|
|
@ -150,7 +150,6 @@ keywords.c
|
|||
ksym.c*
|
||||
ksym.h*
|
||||
kxgettext
|
||||
lkc_defs.h
|
||||
lex.c
|
||||
lex.*.c
|
||||
linux
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ use IO::Handle;
|
|||
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
|
||||
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5",
|
||||
"drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137",
|
||||
"drxk_pctv");
|
||||
"drxk_pctv", "drxk_terratec_htc_stick", "sms1xxx_hcw");
|
||||
|
||||
# Check args
|
||||
syntax() if (scalar(@ARGV) != 1);
|
||||
|
|
@ -676,6 +676,24 @@ sub drxk_terratec_h5 {
|
|||
"$fwfile"
|
||||
}
|
||||
|
||||
sub drxk_terratec_htc_stick {
|
||||
my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/";
|
||||
my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe";
|
||||
my $hash = "6722a2442a05423b781721fbc069ed5e";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
|
||||
my $drvfile = "Cinergy HTC Stick/BDA Driver 5.09.1202.00/Windows 32 Bit/emOEM.sys";
|
||||
my $fwfile = "dvb-usb-terratec-htc-stick-drxk.fw";
|
||||
|
||||
checkstandard();
|
||||
|
||||
wgetfile($zipfile, $url . $zipfile);
|
||||
verify($zipfile, $hash);
|
||||
unzip($zipfile, $tmpdir);
|
||||
extract("$tmpdir/$drvfile", 0x4e5c0, 42692, "$fwfile");
|
||||
|
||||
"$fwfile"
|
||||
}
|
||||
|
||||
sub it9135 {
|
||||
my $sourcefile = "dvb-usb-it9135.zip";
|
||||
my $url = "http://www.ite.com.tw/uploads/firmware/v3.6.0.0/$sourcefile";
|
||||
|
|
@ -748,6 +766,28 @@ sub drxk_pctv {
|
|||
"$fwfile";
|
||||
}
|
||||
|
||||
sub sms1xxx_hcw {
|
||||
my $url = "http://steventoth.net/linux/sms1xxx/";
|
||||
my %files = (
|
||||
'sms1xxx-hcw-55xxx-dvbt-01.fw' => "afb6f9fb9a71d64392e8564ef9577e5a",
|
||||
'sms1xxx-hcw-55xxx-dvbt-02.fw' => "b44807098ba26e52cbedeadc052ba58f",
|
||||
'sms1xxx-hcw-55xxx-isdbt-02.fw' => "dae934eeea85225acbd63ce6cfe1c9e4",
|
||||
);
|
||||
|
||||
checkstandard();
|
||||
|
||||
my $allfiles;
|
||||
foreach my $fwfile (keys %files) {
|
||||
wgetfile($fwfile, "$url/$fwfile");
|
||||
verify($fwfile, $files{$fwfile});
|
||||
$allfiles .= " $fwfile";
|
||||
}
|
||||
|
||||
$allfiles =~ s/^\s//;
|
||||
|
||||
$allfiles;
|
||||
}
|
||||
|
||||
# ---------------------------------------------------------------
|
||||
# Utilities
|
||||
|
||||
|
|
|
|||
|
|
@ -232,116 +232,20 @@ EDAC control and attribute files.
|
|||
|
||||
|
||||
In 'mcX' directories are EDAC control and attribute files for
|
||||
this 'X' instance of the memory controllers:
|
||||
|
||||
|
||||
Counter reset control file:
|
||||
|
||||
'reset_counters'
|
||||
|
||||
This write-only control file will zero all the statistical counters
|
||||
for UE and CE errors. Zeroing the counters will also reset the timer
|
||||
indicating how long since the last counter zero. This is useful
|
||||
for computing errors/time. Since the counters are always reset at
|
||||
driver initialization time, no module/kernel parameter is available.
|
||||
|
||||
RUN TIME: echo "anything" >/sys/devices/system/edac/mc/mc0/counter_reset
|
||||
|
||||
This resets the counters on memory controller 0
|
||||
|
||||
|
||||
Seconds since last counter reset control file:
|
||||
|
||||
'seconds_since_reset'
|
||||
|
||||
This attribute file displays how many seconds have elapsed since the
|
||||
last counter reset. This can be used with the error counters to
|
||||
measure error rates.
|
||||
|
||||
|
||||
|
||||
Memory Controller name attribute file:
|
||||
|
||||
'mc_name'
|
||||
|
||||
This attribute file displays the type of memory controller
|
||||
that is being utilized.
|
||||
|
||||
|
||||
Total memory managed by this memory controller attribute file:
|
||||
|
||||
'size_mb'
|
||||
|
||||
This attribute file displays, in count of megabytes, of memory
|
||||
that this instance of memory controller manages.
|
||||
|
||||
|
||||
Total Uncorrectable Errors count attribute file:
|
||||
|
||||
'ue_count'
|
||||
|
||||
This attribute file displays the total count of uncorrectable
|
||||
errors that have occurred on this memory controller. If panic_on_ue
|
||||
is set this counter will not have a chance to increment,
|
||||
since EDAC will panic the system.
|
||||
|
||||
|
||||
Total UE count that had no information attribute fileY:
|
||||
|
||||
'ue_noinfo_count'
|
||||
|
||||
This attribute file displays the number of UEs that have occurred
|
||||
with no information as to which DIMM slot is having errors.
|
||||
|
||||
|
||||
Total Correctable Errors count attribute file:
|
||||
|
||||
'ce_count'
|
||||
|
||||
This attribute file displays the total count of correctable
|
||||
errors that have occurred on this memory controller. This
|
||||
count is very important to examine. CEs provide early
|
||||
indications that a DIMM is beginning to fail. This count
|
||||
field should be monitored for non-zero values and report
|
||||
such information to the system administrator.
|
||||
|
||||
|
||||
Total Correctable Errors count attribute file:
|
||||
|
||||
'ce_noinfo_count'
|
||||
|
||||
This attribute file displays the number of CEs that
|
||||
have occurred wherewith no information as to which DIMM slot
|
||||
is having errors. Memory is handicapped, but operational,
|
||||
yet no information is available to indicate which slot
|
||||
the failing memory is in. This count field should be also
|
||||
be monitored for non-zero values.
|
||||
|
||||
Device Symlink:
|
||||
|
||||
'device'
|
||||
|
||||
Symlink to the memory controller device.
|
||||
|
||||
Sdram memory scrubbing rate:
|
||||
|
||||
'sdram_scrub_rate'
|
||||
|
||||
Read/Write attribute file that controls memory scrubbing. The scrubbing
|
||||
rate is set by writing a minimum bandwidth in bytes/sec to the attribute
|
||||
file. The rate will be translated to an internal value that gives at
|
||||
least the specified rate.
|
||||
|
||||
Reading the file will return the actual scrubbing rate employed.
|
||||
|
||||
If configuration fails or memory scrubbing is not implemented, accessing
|
||||
that attribute will fail.
|
||||
this 'X' instance of the memory controllers.
|
||||
|
||||
For a description of the sysfs API, please see:
|
||||
Documentation/ABI/testing/sysfs/devices-edac
|
||||
|
||||
|
||||
============================================================================
|
||||
'csrowX' DIRECTORIES
|
||||
|
||||
When CONFIG_EDAC_LEGACY_SYSFS is enabled, the sysfs will contain the
|
||||
csrowX directories. As this API doesn't work properly for Rambus, FB-DIMMs
|
||||
and modern Intel Memory Controllers, this is being deprecated in favor
|
||||
of dimmX directories.
|
||||
|
||||
In the 'csrowX' directories are EDAC control and attribute files for
|
||||
this 'X' instance of csrow:
|
||||
|
||||
|
|
|
|||
|
|
@ -240,3 +240,30 @@ trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT
|
|||
echo "Injecting errors into the module $module... (interrupt to stop)"
|
||||
sleep 1000000
|
||||
|
||||
Tool to run command with failslab or fail_page_alloc
|
||||
----------------------------------------------------
|
||||
In order to make it easier to accomplish the tasks mentioned above, we can use
|
||||
tools/testing/fault-injection/failcmd.sh. Please run a command
|
||||
"./tools/testing/fault-injection/failcmd.sh --help" for more information and
|
||||
see the following examples.
|
||||
|
||||
Examples:
|
||||
|
||||
Run a command "make -C tools/testing/selftests/ run_tests" with injecting slab
|
||||
allocation failure.
|
||||
|
||||
# ./tools/testing/fault-injection/failcmd.sh \
|
||||
-- make -C tools/testing/selftests/ run_tests
|
||||
|
||||
Same as above except to specify 100 times failures at most instead of one time
|
||||
at most by default.
|
||||
|
||||
# ./tools/testing/fault-injection/failcmd.sh --times=100 \
|
||||
-- make -C tools/testing/selftests/ run_tests
|
||||
|
||||
Same as above except to inject page allocation failure instead of slab
|
||||
allocation failure.
|
||||
|
||||
# env FAILCMD_TYPE=fail_page_alloc \
|
||||
./tools/testing/fault-injection/failcmd.sh --times=100 \
|
||||
-- make -C tools/testing/selftests/ run_tests
|
||||
|
|
|
|||
|
|
@ -0,0 +1,99 @@
|
|||
Notifier error injection
|
||||
========================
|
||||
|
||||
Notifier error injection provides the ability to inject artifical errors to
|
||||
specified notifier chain callbacks. It is useful to test the error handling of
|
||||
notifier call chain failures which is rarely executed. There are kernel
|
||||
modules that can be used to test the following notifiers.
|
||||
|
||||
* CPU notifier
|
||||
* PM notifier
|
||||
* Memory hotplug notifier
|
||||
* powerpc pSeries reconfig notifier
|
||||
|
||||
CPU notifier error injection module
|
||||
-----------------------------------
|
||||
This feature can be used to test the error handling of the CPU notifiers by
|
||||
injecting artifical errors to CPU notifier chain callbacks.
|
||||
|
||||
If the notifier call chain should be failed with some events notified, write
|
||||
the error code to debugfs interface
|
||||
/sys/kernel/debug/notifier-error-inject/cpu/actions/<notifier event>/error
|
||||
|
||||
Possible CPU notifier events to be failed are:
|
||||
|
||||
* CPU_UP_PREPARE
|
||||
* CPU_UP_PREPARE_FROZEN
|
||||
* CPU_DOWN_PREPARE
|
||||
* CPU_DOWN_PREPARE_FROZEN
|
||||
|
||||
Example1: Inject CPU offline error (-1 == -EPERM)
|
||||
|
||||
# cd /sys/kernel/debug/notifier-error-inject/cpu
|
||||
# echo -1 > actions/CPU_DOWN_PREPARE/error
|
||||
# echo 0 > /sys/devices/system/cpu/cpu1/online
|
||||
bash: echo: write error: Operation not permitted
|
||||
|
||||
Example2: inject CPU online error (-2 == -ENOENT)
|
||||
|
||||
# echo -2 > actions/CPU_UP_PREPARE/error
|
||||
# echo 1 > /sys/devices/system/cpu/cpu1/online
|
||||
bash: echo: write error: No such file or directory
|
||||
|
||||
PM notifier error injection module
|
||||
----------------------------------
|
||||
This feature is controlled through debugfs interface
|
||||
/sys/kernel/debug/notifier-error-inject/pm/actions/<notifier event>/error
|
||||
|
||||
Possible PM notifier events to be failed are:
|
||||
|
||||
* PM_HIBERNATION_PREPARE
|
||||
* PM_SUSPEND_PREPARE
|
||||
* PM_RESTORE_PREPARE
|
||||
|
||||
Example: Inject PM suspend error (-12 = -ENOMEM)
|
||||
|
||||
# cd /sys/kernel/debug/notifier-error-inject/pm/
|
||||
# echo -12 > actions/PM_SUSPEND_PREPARE/error
|
||||
# echo mem > /sys/power/state
|
||||
bash: echo: write error: Cannot allocate memory
|
||||
|
||||
Memory hotplug notifier error injection module
|
||||
----------------------------------------------
|
||||
This feature is controlled through debugfs interface
|
||||
/sys/kernel/debug/notifier-error-inject/memory/actions/<notifier event>/error
|
||||
|
||||
Possible memory notifier events to be failed are:
|
||||
|
||||
* MEM_GOING_ONLINE
|
||||
* MEM_GOING_OFFLINE
|
||||
|
||||
Example: Inject memory hotplug offline error (-12 == -ENOMEM)
|
||||
|
||||
# cd /sys/kernel/debug/notifier-error-inject/memory
|
||||
# echo -12 > actions/MEM_GOING_OFFLINE/error
|
||||
# echo offline > /sys/devices/system/memory/memoryXXX/state
|
||||
bash: echo: write error: Cannot allocate memory
|
||||
|
||||
powerpc pSeries reconfig notifier error injection module
|
||||
--------------------------------------------------------
|
||||
This feature is controlled through debugfs interface
|
||||
/sys/kernel/debug/notifier-error-inject/pSeries-reconfig/actions/<notifier event>/error
|
||||
|
||||
Possible pSeries reconfig notifier events to be failed are:
|
||||
|
||||
* PSERIES_RECONFIG_ADD
|
||||
* PSERIES_RECONFIG_REMOVE
|
||||
* PSERIES_DRCONF_MEM_ADD
|
||||
* PSERIES_DRCONF_MEM_REMOVE
|
||||
|
||||
For more usage examples
|
||||
-----------------------
|
||||
There are tools/testing/selftests using the notifier error injection features
|
||||
for CPU and memory notifiers.
|
||||
|
||||
* tools/testing/selftests/cpu-hotplug/on-off-test.sh
|
||||
* tools/testing/selftests/memory-hotplug/on-off-test.sh
|
||||
|
||||
These scripts first do simple online and offline tests and then do fault
|
||||
injection tests if notifier error injection module is available.
|
||||
|
|
@ -13,6 +13,14 @@ Who: Jim Cromie <jim.cromie@gmail.com>, Jason Baron <jbaron@redhat.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: /proc/sys/vm/nr_pdflush_threads
|
||||
When: 2012
|
||||
Why: Since pdflush is deprecated, the interface exported in /proc/sys/vm/
|
||||
should be removed.
|
||||
Who: Wanpeng Li <liwp@linux.vnet.ibm.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
|
||||
When: 2012
|
||||
Why: This optional sub-feature of APM is of dubious reliability,
|
||||
|
|
@ -70,20 +78,6 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: IRQF_SAMPLE_RANDOM
|
||||
Check: IRQF_SAMPLE_RANDOM
|
||||
When: July 2009
|
||||
|
||||
Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy
|
||||
sources in the kernel's current entropy model. To resolve this, every
|
||||
input point to the kernel's entropy pool needs to better document the
|
||||
type of entropy source it actually is. This will be replaced with
|
||||
additional add_*_randomness functions in drivers/char/random.c
|
||||
|
||||
Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: The ieee80211_regdom module parameter
|
||||
When: March 2010 / desktop catchup
|
||||
|
||||
|
|
@ -512,14 +506,6 @@ Who: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: kmap_atomic(page, km_type)
|
||||
When: 3.5
|
||||
Why: The old kmap_atomic() with two arguments is deprecated, we only
|
||||
keep it for backward compatibility for few cycles and then drop it.
|
||||
Who: Cong Wang <amwang@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: get_robust_list syscall
|
||||
When: 2013
|
||||
Why: There appear to be no production users of the get_robust_list syscall,
|
||||
|
|
@ -608,3 +594,35 @@ When: June 2013
|
|||
Why: Unsupported/unmaintained/unused since 2.6
|
||||
|
||||
----------------------------
|
||||
|
||||
What: V4L2 selections API target rectangle and flags unification, the
|
||||
following definitions will be removed: V4L2_SEL_TGT_CROP_ACTIVE,
|
||||
V4L2_SEL_TGT_COMPOSE_ACTIVE, V4L2_SUBDEV_SEL_*, V4L2_SUBDEV_SEL_FLAG_*
|
||||
in favor of common V4L2_SEL_TGT_* and V4L2_SEL_FLAG_* definitions.
|
||||
For more details see include/linux/v4l2-common.h.
|
||||
When: 3.8
|
||||
Why: The regular V4L2 selections and the subdev selection API originally
|
||||
defined distinct names for the target rectangles and flags - V4L2_SEL_*
|
||||
and V4L2_SUBDEV_SEL_*. Although, it turned out that the meaning of these
|
||||
target rectangles is virtually identical and the APIs were consolidated
|
||||
to use single set of names - V4L2_SEL_*. This didn't involve any ABI
|
||||
changes. Alias definitions were created for the original ones to avoid
|
||||
any instabilities in the user space interface. After few cycles these
|
||||
backward compatibility definitions will be removed.
|
||||
Who: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Using V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags
|
||||
to indicate a V4L2 memory-to-memory device capability
|
||||
When: 3.8
|
||||
Why: New drivers should use new V4L2_CAP_VIDEO_M2M capability flag
|
||||
to indicate a V4L2 video memory-to-memory (M2M) device and
|
||||
applications can now identify a M2M video device by checking
|
||||
for V4L2_CAP_VIDEO_M2M, with VIDIOC_QUERYCAP ioctl. Using ORed
|
||||
V4L2_CAP_VIDEO_CAPTURE and V4L2_CAP_VIDEO_OUTPUT flags for M2M
|
||||
devices is ambiguous and may lead, for example, to identifying
|
||||
a M2M device as a video capture or output device.
|
||||
Who: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
|
||||
----------------------------
|
||||
|
|
|
|||
|
|
@ -206,6 +206,8 @@ prototypes:
|
|||
int (*launder_page)(struct page *);
|
||||
int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long);
|
||||
int (*error_remove_page)(struct address_space *, struct page *);
|
||||
int (*swap_activate)(struct file *);
|
||||
int (*swap_deactivate)(struct file *);
|
||||
|
||||
locking rules:
|
||||
All except set_page_dirty and freepage may block
|
||||
|
|
@ -229,6 +231,8 @@ migratepage: yes (both)
|
|||
launder_page: yes
|
||||
is_partially_uptodate: yes
|
||||
error_remove_page: yes
|
||||
swap_activate: no
|
||||
swap_deactivate: no
|
||||
|
||||
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
|
||||
may be called from the request handler (/dev/loop).
|
||||
|
|
@ -330,6 +334,15 @@ cleaned, or an error value if not. Note that in order to prevent the page
|
|||
getting mapped back in and redirtied, it needs to be kept locked
|
||||
across the entire operation.
|
||||
|
||||
->swap_activate will be called with a non-zero argument on
|
||||
files backing (non block device backed) swapfiles. A return value
|
||||
of zero indicates success, in which case this file can be used for
|
||||
backing swapspace. The swapspace operations will be proxied to the
|
||||
address space operations.
|
||||
|
||||
->swap_deactivate() will be called in the sys_swapoff()
|
||||
path after ->swap_activate() returned success.
|
||||
|
||||
----------------------- file_lock_operations ------------------------------
|
||||
prototypes:
|
||||
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
|
||||
|
|
|
|||
|
|
@ -592,6 +592,8 @@ struct address_space_operations {
|
|||
int (*migratepage) (struct page *, struct page *);
|
||||
int (*launder_page) (struct page *);
|
||||
int (*error_remove_page) (struct mapping *mapping, struct page *page);
|
||||
int (*swap_activate)(struct file *);
|
||||
int (*swap_deactivate)(struct file *);
|
||||
};
|
||||
|
||||
writepage: called by the VM to write a dirty page to backing store.
|
||||
|
|
@ -760,6 +762,16 @@ struct address_space_operations {
|
|||
Setting this implies you deal with pages going away under you,
|
||||
unless you have them locked or reference counts increased.
|
||||
|
||||
swap_activate: Called when swapon is used on a file to allocate
|
||||
space if necessary and pin the block lookup information in
|
||||
memory. A return value of zero indicates success,
|
||||
in which case this file can be used to back swapspace. The
|
||||
swapspace operations will be proxied to this address space's
|
||||
->swap_{out,in} methods.
|
||||
|
||||
swap_deactivate: Called during swapoff on files where swap_activate
|
||||
was successful.
|
||||
|
||||
|
||||
The File Object
|
||||
===============
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
EDT ft5x06 based Polytouch devices
|
||||
----------------------------------
|
||||
|
||||
The edt-ft5x06 driver is useful for the EDT "Polytouch" family of capacitive
|
||||
touch screens. Note that it is *not* suitable for other devices based on the
|
||||
focaltec ft5x06 devices, since they contain vendor-specific firmware. In
|
||||
particular this driver is not suitable for the Nook tablet.
|
||||
|
||||
It has been tested with the following devices:
|
||||
* EP0350M06
|
||||
* EP0430M06
|
||||
* EP0570M06
|
||||
* EP0700M06
|
||||
|
||||
The driver allows configuration of the touch screen via a set of sysfs files:
|
||||
|
||||
/sys/class/input/eventX/device/device/threshold:
|
||||
allows setting the "click"-threshold in the range from 20 to 80.
|
||||
|
||||
/sys/class/input/eventX/device/device/gain:
|
||||
allows setting the sensitivity in the range from 0 to 31. Note that
|
||||
lower values indicate higher sensitivity.
|
||||
|
||||
/sys/class/input/eventX/device/device/offset:
|
||||
allows setting the edge compensation in the range from 0 to 31.
|
||||
|
||||
/sys/class/input/eventX/device/device/report_rate:
|
||||
allows setting the report rate in the range from 3 to 14.
|
||||
|
||||
|
||||
For debugging purposes the driver provides a few files in the debug
|
||||
filesystem (if available in the kernel). In /sys/kernel/debug/edt_ft5x06
|
||||
you'll find the following files:
|
||||
|
||||
num_x, num_y:
|
||||
(readonly) contains the number of sensor fields in X- and
|
||||
Y-direction.
|
||||
|
||||
mode:
|
||||
allows switching the sensor between "factory mode" and "operation
|
||||
mode" by writing "1" or "0" to it. In factory mode (1) it is
|
||||
possible to get the raw data from the sensor. Note that in factory
|
||||
mode regular events don't get delivered and the options described
|
||||
above are unavailable.
|
||||
|
||||
raw_data:
|
||||
contains num_x * num_y big endian 16 bit values describing the raw
|
||||
values for each sensor field. Note that each read() call on this
|
||||
files triggers a new readout. It is recommended to provide a buffer
|
||||
big enough to contain num_x * num_y * 2 bytes.
|
||||
|
||||
Note that reading raw_data gives a I/O error when the device is not in factory
|
||||
mode. The same happens when reading/writing to the parameter files when the
|
||||
device is not in regular operation mode.
|
||||
|
|
@ -162,26 +162,48 @@ are divided into categories, to allow for partial implementation. The
|
|||
minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
|
||||
allows for multiple contacts to be tracked. If the device supports it, the
|
||||
ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
|
||||
of the contact area and approaching contact, respectively.
|
||||
of the contact area and approaching tool, respectively.
|
||||
|
||||
The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
|
||||
looking through a window at someone gently holding a finger against the
|
||||
glass. You will see two regions, one inner region consisting of the part
|
||||
of the finger actually touching the glass, and one outer region formed by
|
||||
the perimeter of the finger. The diameter of the inner region is the
|
||||
ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
|
||||
ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
|
||||
against the glass. The inner region will increase, and in general, the
|
||||
ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
|
||||
unity, is related to the contact pressure. For pressure-based devices,
|
||||
the perimeter of the finger. The center of the touching region (a) is
|
||||
ABS_MT_POSITION_X/Y and the center of the approaching finger (b) is
|
||||
ABS_MT_TOOL_X/Y. The touch diameter is ABS_MT_TOUCH_MAJOR and the finger
|
||||
diameter is ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger
|
||||
harder against the glass. The touch region will increase, and in general,
|
||||
the ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller
|
||||
than unity, is related to the contact pressure. For pressure-based devices,
|
||||
ABS_MT_PRESSURE may be used to provide the pressure on the contact area
|
||||
instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to
|
||||
indicate the distance between the contact and the surface.
|
||||
|
||||
In addition to the MAJOR parameters, the oval shape of the contact can be
|
||||
described by adding the MINOR parameters, such that MAJOR and MINOR are the
|
||||
major and minor axis of an ellipse. Finally, the orientation of the oval
|
||||
shape can be describe with the ORIENTATION parameter.
|
||||
|
||||
Linux MT Win8
|
||||
__________ _______________________
|
||||
/ \ | |
|
||||
/ \ | |
|
||||
/ ____ \ | |
|
||||
/ / \ \ | |
|
||||
\ \ a \ \ | a |
|
||||
\ \____/ \ | |
|
||||
\ \ | |
|
||||
\ b \ | b |
|
||||
\ \ | |
|
||||
\ \ | |
|
||||
\ \ | |
|
||||
\ / | |
|
||||
\ / | |
|
||||
\ / | |
|
||||
\__________/ |_______________________|
|
||||
|
||||
|
||||
In addition to the MAJOR parameters, the oval shape of the touch and finger
|
||||
regions can be described by adding the MINOR parameters, such that MAJOR
|
||||
and MINOR are the major and minor axis of an ellipse. The orientation of
|
||||
the touch ellipse can be described with the ORIENTATION parameter, and the
|
||||
direction of the finger ellipse is given by the vector (a - b).
|
||||
|
||||
For type A devices, further specification of the touch shape is possible
|
||||
via ABS_MT_BLOB_ID.
|
||||
|
|
@ -224,7 +246,7 @@ tool. Omit if circular [4].
|
|||
The above four values can be used to derive additional information about
|
||||
the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates
|
||||
the notion of pressure. The fingers of the hand and the palm all have
|
||||
different characteristic widths [1].
|
||||
different characteristic widths.
|
||||
|
||||
ABS_MT_PRESSURE
|
||||
|
||||
|
|
@ -240,17 +262,24 @@ the contact is hovering above the surface.
|
|||
|
||||
ABS_MT_ORIENTATION
|
||||
|
||||
The orientation of the ellipse. The value should describe a signed quarter
|
||||
of a revolution clockwise around the touch center. The signed value range
|
||||
is arbitrary, but zero should be returned for a finger aligned along the Y
|
||||
axis of the surface, a negative value when finger is turned to the left, and
|
||||
a positive value when finger turned to the right. When completely aligned with
|
||||
the X axis, the range max should be returned. Orientation can be omitted
|
||||
if the touching object is circular, or if the information is not available
|
||||
in the kernel driver. Partial orientation support is possible if the device
|
||||
can distinguish between the two axis, but not (uniquely) any values in
|
||||
between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
|
||||
[4].
|
||||
The orientation of the touching ellipse. The value should describe a signed
|
||||
quarter of a revolution clockwise around the touch center. The signed value
|
||||
range is arbitrary, but zero should be returned for an ellipse aligned with
|
||||
the Y axis of the surface, a negative value when the ellipse is turned to
|
||||
the left, and a positive value when the ellipse is turned to the
|
||||
right. When completely aligned with the X axis, the range max should be
|
||||
returned.
|
||||
|
||||
Touch ellipsis are symmetrical by default. For devices capable of true 360
|
||||
degree orientation, the reported orientation must exceed the range max to
|
||||
indicate more than a quarter of a revolution. For an upside-down finger,
|
||||
range max * 2 should be returned.
|
||||
|
||||
Orientation can be omitted if the touch area is circular, or if the
|
||||
information is not available in the kernel driver. Partial orientation
|
||||
support is possible if the device can distinguish between the two axis, but
|
||||
not (uniquely) any values in between. In such cases, the range of
|
||||
ABS_MT_ORIENTATION should be [0, 1] [4].
|
||||
|
||||
ABS_MT_POSITION_X
|
||||
|
||||
|
|
@ -260,6 +289,23 @@ ABS_MT_POSITION_Y
|
|||
|
||||
The surface Y coordinate of the center of the touching ellipse.
|
||||
|
||||
ABS_MT_TOOL_X
|
||||
|
||||
The surface X coordinate of the center of the approaching tool. Omit if
|
||||
the device cannot distinguish between the intended touch point and the
|
||||
tool itself.
|
||||
|
||||
ABS_MT_TOOL_Y
|
||||
|
||||
The surface Y coordinate of the center of the approaching tool. Omit if the
|
||||
device cannot distinguish between the intended touch point and the tool
|
||||
itself.
|
||||
|
||||
The four position values can be used to separate the position of the touch
|
||||
from the position of the tool. If both positions are present, the major
|
||||
tool axis points towards the touch point [1]. Otherwise, the tool axes are
|
||||
aligned with the touch axes.
|
||||
|
||||
ABS_MT_TOOL_TYPE
|
||||
|
||||
The type of approaching tool. A lot of kernel drivers cannot distinguish
|
||||
|
|
@ -305,6 +351,28 @@ The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that
|
|||
the device can distinguish between a finger along the Y axis (0) and a
|
||||
finger along the X axis (1).
|
||||
|
||||
For win8 devices with both T and C coordinates, the position mapping is
|
||||
|
||||
ABS_MT_POSITION_X := T_X
|
||||
ABS_MT_POSITION_Y := T_Y
|
||||
ABS_MT_TOOL_X := C_X
|
||||
ABS_MT_TOOL_X := C_Y
|
||||
|
||||
Unfortunately, there is not enough information to specify both the touching
|
||||
ellipse and the tool ellipse, so one has to resort to approximations. One
|
||||
simple scheme, which is compatible with earlier usage, is:
|
||||
|
||||
ABS_MT_TOUCH_MAJOR := min(X, Y)
|
||||
ABS_MT_TOUCH_MINOR := <not used>
|
||||
ABS_MT_ORIENTATION := <not used>
|
||||
ABS_MT_WIDTH_MAJOR := min(X, Y) + distance(T, C)
|
||||
ABS_MT_WIDTH_MINOR := min(X, Y)
|
||||
|
||||
Rationale: We have no information about the orientation of the touching
|
||||
ellipse, so approximate it with an inscribed circle instead. The tool
|
||||
ellipse should align with the the vector (T - C), so the diameter must
|
||||
increase with distance(T, C). Finally, assume that the touch diameter is
|
||||
equal to the tool thickness, and we arrive at the formulas above.
|
||||
|
||||
Finger Tracking
|
||||
---------------
|
||||
|
|
@ -338,9 +406,7 @@ subsequent events of the same type refer to different fingers.
|
|||
For example usage of the type A protocol, see the bcm5974 driver. For
|
||||
example usage of the type B protocol, see the hid-egalax driver.
|
||||
|
||||
[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the
|
||||
difference between the contact position and the approaching tool position
|
||||
could be used to derive tilt.
|
||||
[1] Also, the difference (TOOL_X - POSITION_X) can be used to model tilt.
|
||||
[2] The list can of course be extended.
|
||||
[3] The mtdev project: http://bitmath.org/code/mtdev/.
|
||||
[4] See the section on event computation.
|
||||
|
|
|
|||
|
|
@ -88,6 +88,7 @@ Code Seq#(hex) Include File Comments
|
|||
and kernel/power/user.c
|
||||
'8' all SNP8023 advanced NIC card
|
||||
<mailto:mcr@solidum.com>
|
||||
';' 64-7F linux/vfio.h
|
||||
'@' 00-0F linux/radeonfb.h conflict!
|
||||
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
|
||||
'A' 00-1F linux/apm_bios.h conflict!
|
||||
|
|
|
|||
|
|
@ -526,7 +526,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
|
||||
coherent_pool=nn[KMG] [ARM,KNL]
|
||||
Sets the size of memory pool for coherent, atomic dma
|
||||
allocations if Contiguous Memory Allocator (CMA) is used.
|
||||
allocations, by default set to 256K.
|
||||
|
||||
code_bytes [X86] How many bytes of object code to print
|
||||
in an oops report.
|
||||
|
|
|
|||
|
|
@ -6,3 +6,5 @@ leds-lp5521.txt
|
|||
- notes on how to use the leds-lp5521 driver.
|
||||
leds-lp5523.txt
|
||||
- notes on how to use the leds-lp5523 driver.
|
||||
leds-lm3556.txt
|
||||
- notes on how to use the leds-lm3556 driver.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,80 @@
|
|||
The leds-blinkm driver supports the devices of the BlinkM family.
|
||||
|
||||
They are RGB-LED modules driven by a (AT)tiny microcontroller and
|
||||
communicate through I2C. The default address of these modules is
|
||||
0x09 but this can be changed through a command. By this you could
|
||||
dasy-chain up to 127 BlinkMs on an I2C bus.
|
||||
|
||||
The device accepts RGB and HSB color values through separate commands.
|
||||
Also you can store blinking sequences as "scripts" in
|
||||
the controller and run them. Also fading is an option.
|
||||
|
||||
The interface this driver provides is 2-fold:
|
||||
|
||||
a) LED class interface for use with triggers
|
||||
############################################
|
||||
|
||||
The registration follows the scheme:
|
||||
blinkm-<i2c-bus-nr>-<i2c-device-nr>-<color>
|
||||
|
||||
$ ls -h /sys/class/leds/blinkm-6-*
|
||||
/sys/class/leds/blinkm-6-9-blue:
|
||||
brightness device max_brightness power subsystem trigger uevent
|
||||
|
||||
/sys/class/leds/blinkm-6-9-green:
|
||||
brightness device max_brightness power subsystem trigger uevent
|
||||
|
||||
/sys/class/leds/blinkm-6-9-red:
|
||||
brightness device max_brightness power subsystem trigger uevent
|
||||
|
||||
(same is /sys/bus/i2c/devices/6-0009/leds)
|
||||
|
||||
We can control the colors separated into red, green and blue and
|
||||
assign triggers on each color.
|
||||
|
||||
E.g.:
|
||||
|
||||
$ cat blinkm-6-9-blue/brightness
|
||||
05
|
||||
|
||||
$ echo 200 > blinkm-6-9-blue/brightness
|
||||
$
|
||||
|
||||
$ modprobe ledtrig-heartbeat
|
||||
$ echo heartbeat > blinkm-6-9-green/trigger
|
||||
$
|
||||
|
||||
|
||||
b) Sysfs group to control rgb, fade, hsb, scripts ...
|
||||
#####################################################
|
||||
|
||||
This extended interface is available as folder blinkm
|
||||
in the sysfs folder of the I2C device.
|
||||
E.g. below /sys/bus/i2c/devices/6-0009/blinkm
|
||||
|
||||
$ ls -h /sys/bus/i2c/devices/6-0009/blinkm/
|
||||
blue green red test
|
||||
|
||||
Currently supported is just setting red, green, blue
|
||||
and a test sequence.
|
||||
|
||||
E.g.:
|
||||
|
||||
$ cat *
|
||||
00
|
||||
00
|
||||
00
|
||||
#Write into test to start test sequence!#
|
||||
|
||||
$ echo 1 > test
|
||||
$
|
||||
|
||||
$ echo 255 > red
|
||||
$
|
||||
|
||||
|
||||
|
||||
as of 6/2012
|
||||
|
||||
dl9pf <at> gmx <dot> de
|
||||
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
Kernel driver for lm3556
|
||||
========================
|
||||
|
||||
*Texas Instrument:
|
||||
1.5 A Synchronous Boost LED Flash Driver w/ High-Side Current Source
|
||||
* Datasheet: http://www.national.com/ds/LM/LM3556.pdf
|
||||
|
||||
Authors:
|
||||
Daniel Jeong
|
||||
Contact:Daniel Jeong(daniel.jeong-at-ti.com, gshark.jeong-at-gmail.com)
|
||||
|
||||
Description
|
||||
-----------
|
||||
There are 3 functions in LM3556, Flash, Torch and Indicator.
|
||||
|
||||
FLASH MODE
|
||||
In Flash Mode, the LED current source(LED) provides 16 target current levels
|
||||
from 93.75 mA to 1500 mA.The Flash currents are adjusted via the CURRENT
|
||||
CONTROL REGISTER(0x09).Flash mode is activated by the ENABLE REGISTER(0x0A),
|
||||
or by pulling the STROBE pin HIGH.
|
||||
LM3556 Flash can be controlled through sys/class/leds/flash/brightness file
|
||||
* if STROBE pin is enabled, below example control brightness only, and
|
||||
ON / OFF will be controlled by STROBE pin.
|
||||
|
||||
Flash Example:
|
||||
OFF : #echo 0 > sys/class/leds/flash/brightness
|
||||
93.75 mA: #echo 1 > sys/class/leds/flash/brightness
|
||||
... .....
|
||||
1500 mA: #echo 16 > sys/class/leds/flash/brightness
|
||||
|
||||
TORCH MODE
|
||||
In Torch Mode, the current source(LED) is programmed via the CURRENT CONTROL
|
||||
REGISTER(0x09).Torch Mode is activated by the ENABLE REGISTER(0x0A) or by the
|
||||
hardware TORCH input.
|
||||
LM3556 torch can be controlled through sys/class/leds/torch/brightness file.
|
||||
* if TORCH pin is enabled, below example control brightness only,
|
||||
and ON / OFF will be controlled by TORCH pin.
|
||||
|
||||
Torch Example:
|
||||
OFF : #echo 0 > sys/class/leds/torch/brightness
|
||||
46.88 mA: #echo 1 > sys/class/leds/torch/brightness
|
||||
... .....
|
||||
375 mA : #echo 8 > sys/class/leds/torch/brightness
|
||||
|
||||
INDICATOR MODE
|
||||
Indicator pattern can be set through sys/class/leds/indicator/pattern file,
|
||||
and 4 patterns are pre-defined in indicator_pattern array.
|
||||
According to N-lank, Pulse time and N Period values, different pattern wiill
|
||||
be generated.If you want new patterns for your own device, change
|
||||
indicator_pattern array with your own values and INDIC_PATTERN_SIZE.
|
||||
Please refer datasheet for more detail about N-Blank, Pulse time and N Period.
|
||||
|
||||
Indicator pattern example:
|
||||
pattern 0: #echo 0 > sys/class/leds/indicator/pattern
|
||||
....
|
||||
pattern 3: #echo 3 > sys/class/leds/indicator/pattern
|
||||
|
||||
Indicator brightness can be controlled through
|
||||
sys/class/leds/indicator/brightness file.
|
||||
|
||||
Example:
|
||||
OFF : #echo 0 > sys/class/leds/indicator/brightness
|
||||
5.86 mA : #echo 1 > sys/class/leds/indicator/brightness
|
||||
........
|
||||
46.875mA : #echo 8 > sys/class/leds/indicator/brightness
|
||||
|
||||
Notes
|
||||
-----
|
||||
Driver expects it is registered using the i2c_board_info mechanism.
|
||||
To register the chip at address 0x63 on specific adapter, set the platform data
|
||||
according to include/linux/platform_data/leds-lm3556.h, set the i2c board info
|
||||
|
||||
Example:
|
||||
static struct i2c_board_info __initdata board_i2c_ch4[] = {
|
||||
{
|
||||
I2C_BOARD_INFO(LM3556_NAME, 0x63),
|
||||
.platform_data = &lm3556_pdata,
|
||||
},
|
||||
};
|
||||
|
||||
and register it in the platform init function
|
||||
|
||||
Example:
|
||||
board_register_i2c_bus(4, 400,
|
||||
board_i2c_ch4, ARRAY_SIZE(board_i2c_ch4));
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
One-shot LED Trigger
|
||||
====================
|
||||
|
||||
This is a LED trigger useful for signaling the user of an event where there are
|
||||
no clear trap points to put standard led-on and led-off settings. Using this
|
||||
trigger, the application needs only to signal the trigger when an event has
|
||||
happened, than the trigger turns the LED on and than keeps it off for a
|
||||
specified amount of time.
|
||||
|
||||
This trigger is meant to be usable both for sporadic and dense events. In the
|
||||
first case, the trigger produces a clear single controlled blink for each
|
||||
event, while in the latter it keeps blinking at constant rate, as to signal
|
||||
that the events are arriving continuously.
|
||||
|
||||
A one-shot LED only stays in a constant state when there are no events. An
|
||||
additional "invert" property specifies if the LED has to stay off (normal) or
|
||||
on (inverted) when not rearmed.
|
||||
|
||||
The trigger can be activated from user space on led class devices as shown
|
||||
below:
|
||||
|
||||
echo oneshot > trigger
|
||||
|
||||
This adds the following sysfs attributes to the LED:
|
||||
|
||||
delay_on - specifies for how many milliseconds the LED has to stay at
|
||||
LED_FULL brightness after it has been armed.
|
||||
Default to 100 ms.
|
||||
|
||||
delay_off - specifies for how many milliseconds the LED has to stay at
|
||||
LED_OFF brightness after it has been armed.
|
||||
Default to 100 ms.
|
||||
|
||||
invert - reverse the blink logic. If set to 0 (default) blink on for delay_on
|
||||
ms, then blink off for delay_off ms, leaving the LED normally off. If
|
||||
set to 1, blink off for delay_off ms, then blink on for delay_on ms,
|
||||
leaving the LED normally on.
|
||||
Setting this value also immediately change the LED state.
|
||||
|
||||
shot - write any non-empty string to signal an events, this starts a blink
|
||||
sequence if not already running.
|
||||
|
||||
Example use-case: network devices, initialization:
|
||||
|
||||
echo oneshot > trigger # set trigger for this led
|
||||
echo 33 > delay_on # blink at 1 / (33 + 33) Hz on continuous traffic
|
||||
echo 33 > delay_off
|
||||
|
||||
interface goes up:
|
||||
|
||||
echo 1 > invert # set led as normally-on, turn the led on
|
||||
|
||||
packet received/transmitted:
|
||||
|
||||
echo 1 > shot # led starts blinking, ignored if already blinking
|
||||
|
||||
interface goes down
|
||||
|
||||
echo 0 > invert # set led as normally-off, turn the led off
|
||||
|
|
@ -50,25 +50,25 @@ Intel MEI Driver
|
|||
The driver exposes a misc device called /dev/mei.
|
||||
|
||||
An application maintains communication with an Intel ME feature while
|
||||
/dev/mei is open. The binding to a specific features is performed by calling
|
||||
/dev/mei is open. The binding to a specific feature is performed by calling
|
||||
MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID.
|
||||
The number of instances of an Intel ME feature that can be opened
|
||||
at the same time depends on the Intel ME feature, but most of the
|
||||
features allow only a single instance.
|
||||
|
||||
The Intel AMT Host Interface (Intel AMTHI) feature supports multiple
|
||||
simultaneous user applications. Therefore, the Intel MEI driver handles
|
||||
this internally by maintaining request queues for the applications.
|
||||
simultaneous user connected applications. The Intel MEI driver
|
||||
handles this internally by maintaining request queues for the applications.
|
||||
|
||||
The driver is oblivious to data that is passed between firmware feature
|
||||
The driver is transparent to data that are passed between firmware feature
|
||||
and host application.
|
||||
|
||||
Because some of the Intel ME features can change the system
|
||||
configuration, the driver by default allows only a privileged
|
||||
user to access it.
|
||||
|
||||
A code snippet for an application communicating with
|
||||
Intel AMTHI client:
|
||||
A code snippet for an application communicating with Intel AMTHI client:
|
||||
|
||||
struct mei_connect_client_data data;
|
||||
fd = open(MEI_DEVICE);
|
||||
|
||||
|
|
@ -185,7 +185,7 @@ The Intel AMT Watchdog is composed of two parts:
|
|||
2) Intel MEI driver - connects to the watchdog feature, configures the
|
||||
watchdog and sends the heartbeats.
|
||||
|
||||
The Intel MEI driver uses the kernel watchdog to configure the Intel AMT
|
||||
The Intel MEI driver uses the kernel watchdog API to configure the Intel AMT
|
||||
Watchdog and to send heartbeats to it. The default timeout of the
|
||||
watchdog is 120 seconds.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,12 +48,6 @@ min_adv_mss - INTEGER
|
|||
The advertised MSS depends on the first hop route MTU, but will
|
||||
never be lower than this setting.
|
||||
|
||||
rt_cache_rebuild_count - INTEGER
|
||||
The per net-namespace route cache emergency rebuild threshold.
|
||||
Any net-namespace having its route cache rebuilt due to
|
||||
a hash bucket chain being too long more than this many times
|
||||
will have its route caching disabled
|
||||
|
||||
IP Fragmentation:
|
||||
|
||||
ipfrag_high_thresh - INTEGER
|
||||
|
|
|
|||
|
|
@ -112,14 +112,24 @@ CHARGE_COUNTER - the current charge counter (in µAh). This could easily
|
|||
be negative; there is no empty or full value. It is only useful for
|
||||
relative, time-based measurements.
|
||||
|
||||
CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
|
||||
|
||||
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
|
||||
|
||||
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
|
||||
|
||||
CAPACITY - capacity in percents.
|
||||
CAPACITY_ALERT_MIN - minimum capacity alert value in percents.
|
||||
CAPACITY_ALERT_MAX - maximum capacity alert value in percents.
|
||||
CAPACITY_LEVEL - capacity level. This corresponds to
|
||||
POWER_SUPPLY_CAPACITY_LEVEL_*.
|
||||
|
||||
TEMP - temperature of the power supply.
|
||||
TEMP_ALERT_MIN - minimum battery temperature alert value in milli centigrade.
|
||||
TEMP_ALERT_MAX - maximum battery temperature alert value in milli centigrade.
|
||||
TEMP_AMBIENT - ambient temperature.
|
||||
TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert value in milli centigrade.
|
||||
TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert value in milli centigrade.
|
||||
|
||||
TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
|
||||
while battery powers a load)
|
||||
|
|
|
|||
|
|
@ -53,9 +53,20 @@ Struct Resources:
|
|||
For printing struct resources. The 'R' and 'r' specifiers result in a
|
||||
printed resource with ('R') or without ('r') a decoded flags member.
|
||||
|
||||
Raw buffer as a hex string:
|
||||
%*ph 00 01 02 ... 3f
|
||||
%*phC 00:01:02: ... :3f
|
||||
%*phD 00-01-02- ... -3f
|
||||
%*phN 000102 ... 3f
|
||||
|
||||
For printing a small buffers (up to 64 bytes long) as a hex string with
|
||||
certain separator. For the larger buffers consider to use
|
||||
print_hex_dump().
|
||||
|
||||
MAC/FDDI addresses:
|
||||
|
||||
%pM 00:01:02:03:04:05
|
||||
%pMR 05:04:03:02:01:00
|
||||
%pMF 00-01-02-03-04-05
|
||||
%pm 000102030405
|
||||
|
||||
|
|
@ -67,6 +78,10 @@ MAC/FDDI addresses:
|
|||
the 'M' specifier to use dash ('-') separators instead of the default
|
||||
separator.
|
||||
|
||||
For Bluetooth addresses the 'R' specifier shall be used after the 'M'
|
||||
specifier to use reversed byte order suitable for visual interpretation
|
||||
of Bluetooth addresses which are in the little endian order.
|
||||
|
||||
IPv4 addresses:
|
||||
|
||||
%pI4 1.2.3.4
|
||||
|
|
|
|||
|
|
@ -0,0 +1,76 @@
|
|||
Pulse Width Modulation (PWM) interface
|
||||
|
||||
This provides an overview about the Linux PWM interface
|
||||
|
||||
PWMs are commonly used for controlling LEDs, fans or vibrators in
|
||||
cell phones. PWMs with a fixed purpose have no need implementing
|
||||
the Linux PWM API (although they could). However, PWMs are often
|
||||
found as discrete devices on SoCs which have no fixed purpose. It's
|
||||
up to the board designer to connect them to LEDs or fans. To provide
|
||||
this kind of flexibility the generic PWM API exists.
|
||||
|
||||
Identifying PWMs
|
||||
----------------
|
||||
|
||||
Users of the legacy PWM API use unique IDs to refer to PWM devices.
|
||||
|
||||
Instead of referring to a PWM device via its unique ID, board setup code
|
||||
should instead register a static mapping that can be used to match PWM
|
||||
consumers to providers, as given in the following example:
|
||||
|
||||
static struct pwm_lookup board_pwm_lookup[] = {
|
||||
PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
|
||||
};
|
||||
|
||||
static void __init board_init(void)
|
||||
{
|
||||
...
|
||||
pwm_add_table(board_pwm_lookup, ARRAY_SIZE(board_pwm_lookup));
|
||||
...
|
||||
}
|
||||
|
||||
Using PWMs
|
||||
----------
|
||||
|
||||
Legacy users can request a PWM device using pwm_request() and free it
|
||||
after usage with pwm_free().
|
||||
|
||||
New users should use the pwm_get() function and pass to it the consumer
|
||||
device or a consumer name. pwm_put() is used to free the PWM device.
|
||||
|
||||
After being requested a PWM has to be configured using:
|
||||
|
||||
int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
|
||||
|
||||
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
|
||||
|
||||
Implementing a PWM driver
|
||||
-------------------------
|
||||
|
||||
Currently there are two ways to implement pwm drivers. Traditionally
|
||||
there only has been the barebone API meaning that each driver has
|
||||
to implement the pwm_*() functions itself. This means that it's impossible
|
||||
to have multiple PWM drivers in the system. For this reason it's mandatory
|
||||
for new drivers to use the generic PWM framework.
|
||||
|
||||
A new PWM controller/chip can be added using pwmchip_add() and removed
|
||||
again with pwmchip_remove(). pwmchip_add() takes a filled in struct
|
||||
pwm_chip as argument which provides a description of the PWM chip, the
|
||||
number of PWM devices provider by the chip and the chip-specific
|
||||
implementation of the supported PWM operations to the framework.
|
||||
|
||||
Locking
|
||||
-------
|
||||
|
||||
The PWM core list manipulations are protected by a mutex, so pwm_request()
|
||||
and pwm_free() may not be called from an atomic context. Currently the
|
||||
PWM core does not enforce any locking to pwm_enable(), pwm_disable() and
|
||||
pwm_config(), so the calling context is currently driver specific. This
|
||||
is an issue derived from the former barebone API and should be fixed soon.
|
||||
|
||||
Helpers
|
||||
-------
|
||||
|
||||
Currently a PWM can only be configured with period_ns and duty_ns. For several
|
||||
use cases freq_hz and duty_percent might be better. Instead of calculating
|
||||
this in your driver please consider adding appropriate helpers to the framework.
|
||||
|
|
@ -40,6 +40,12 @@ corrupt, but usually it is restorable.
|
|||
Setting the ramoops parameters can be done in 2 different manners:
|
||||
1. Use the module parameters (which have the names of the variables described
|
||||
as before).
|
||||
For quick debugging, you can also reserve parts of memory during boot
|
||||
and then use the reserved memory for ramoops. For example, assuming a machine
|
||||
with > 128 MB of memory, the following kernel command line will tell the
|
||||
kernel to use only the first 128 MB of memory, and place ECC-protected ramoops
|
||||
region at 128 MB boundary:
|
||||
"mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1"
|
||||
2. Use a platform device and set the platform data. The parameters can then
|
||||
be set through that platform data. An example of doing that is:
|
||||
|
||||
|
|
@ -70,6 +76,14 @@ if (ret) {
|
|||
return ret;
|
||||
}
|
||||
|
||||
You can specify either RAM memory or peripheral devices' memory. However, when
|
||||
specifying RAM, be sure to reserve the memory by issuing memblock_reserve()
|
||||
very early in the architecture code, e.g.:
|
||||
|
||||
#include <linux/memblock.h>
|
||||
|
||||
memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size);
|
||||
|
||||
3. Dump format
|
||||
|
||||
The data dump begins with a header, currently defined as "====" followed by a
|
||||
|
|
@ -80,3 +94,28 @@ timestamp and a new line. The dump then continues with the actual data.
|
|||
The dump data can be read from the pstore filesystem. The format for these
|
||||
files is "dmesg-ramoops-N", where N is the record number in memory. To delete
|
||||
a stored record from RAM, simply unlink the respective pstore file.
|
||||
|
||||
5. Persistent function tracing
|
||||
|
||||
Persistent function tracing might be useful for debugging software or hardware
|
||||
related hangs. The functions call chain log is stored in a "ftrace-ramoops"
|
||||
file. Here is an example of usage:
|
||||
|
||||
# mount -t debugfs debugfs /sys/kernel/debug/
|
||||
# cd /sys/kernel/debug/tracing
|
||||
# echo function > current_tracer
|
||||
# echo 1 > options/func_pstore
|
||||
# reboot -f
|
||||
[...]
|
||||
# mount -t pstore pstore /mnt/
|
||||
# tail /mnt/ftrace-ramoops
|
||||
0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0
|
||||
0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0
|
||||
0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90
|
||||
0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90
|
||||
0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40
|
||||
0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0
|
||||
0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0
|
||||
0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0
|
||||
0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40
|
||||
0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20
|
||||
|
|
|
|||
|
|
@ -36,8 +36,7 @@ cost.
|
|||
Note: to use this function you should already have a valid rproc
|
||||
handle. There are several ways to achieve that cleanly (devres, pdata,
|
||||
the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we
|
||||
might also consider using dev_archdata for this). See also
|
||||
rproc_get_by_name() below.
|
||||
might also consider using dev_archdata for this).
|
||||
|
||||
void rproc_shutdown(struct rproc *rproc)
|
||||
- Power off a remote processor (previously booted with rproc_boot()).
|
||||
|
|
@ -51,30 +50,6 @@ cost.
|
|||
which means that the @rproc handle stays valid even after
|
||||
rproc_shutdown() returns, and users can still use it with a subsequent
|
||||
rproc_boot(), if needed.
|
||||
- don't call rproc_shutdown() to unroll rproc_get_by_name(), exactly
|
||||
because rproc_shutdown() _does not_ decrement the refcount of @rproc.
|
||||
To decrement the refcount of @rproc, use rproc_put() (but _only_ if
|
||||
you acquired @rproc using rproc_get_by_name()).
|
||||
|
||||
struct rproc *rproc_get_by_name(const char *name)
|
||||
- Find an rproc handle using the remote processor's name, and then
|
||||
boot it. If it's already powered on, then just immediately return
|
||||
(successfully). Returns the rproc handle on success, and NULL on failure.
|
||||
This function increments the remote processor's refcount, so always
|
||||
use rproc_put() to decrement it back once rproc isn't needed anymore.
|
||||
Note: currently rproc_get_by_name() and rproc_put() are not used anymore
|
||||
by the rpmsg bus and its drivers. We need to scrutinize the use cases
|
||||
that still need them, and see if we can migrate them to use the non
|
||||
name-based boot/shutdown interface.
|
||||
|
||||
void rproc_put(struct rproc *rproc)
|
||||
- Decrement @rproc's power refcount and shut it down if it reaches zero
|
||||
(essentially by just calling rproc_shutdown), and then decrement @rproc's
|
||||
validity refcount too.
|
||||
After this function returns, @rproc may _not_ be used anymore, and its
|
||||
handle should be considered invalid.
|
||||
This function should be called _iff_ the @rproc handle was grabbed by
|
||||
calling rproc_get_by_name().
|
||||
|
||||
3. Typical usage
|
||||
|
||||
|
|
@ -115,21 +90,21 @@ int dummy_rproc_example(struct rproc *my_rproc)
|
|||
This function should be used by rproc implementations during
|
||||
initialization of the remote processor.
|
||||
After creating an rproc handle using this function, and when ready,
|
||||
implementations should then call rproc_register() to complete
|
||||
implementations should then call rproc_add() to complete
|
||||
the registration of the remote processor.
|
||||
On success, the new rproc is returned, and on failure, NULL.
|
||||
|
||||
Note: _never_ directly deallocate @rproc, even if it was not registered
|
||||
yet. Instead, if you just need to unroll rproc_alloc(), use rproc_free().
|
||||
yet. Instead, when you need to unroll rproc_alloc(), use rproc_put().
|
||||
|
||||
void rproc_free(struct rproc *rproc)
|
||||
void rproc_put(struct rproc *rproc)
|
||||
- Free an rproc handle that was allocated by rproc_alloc.
|
||||
This function should _only_ be used if @rproc was only allocated,
|
||||
but not registered yet.
|
||||
If @rproc was already successfully registered (by calling
|
||||
rproc_register()), then use rproc_unregister() instead.
|
||||
This function essentially unrolls rproc_alloc(), by decrementing the
|
||||
rproc's refcount. It doesn't directly free rproc; that would happen
|
||||
only if there are no other references to rproc and its refcount now
|
||||
dropped to zero.
|
||||
|
||||
int rproc_register(struct rproc *rproc)
|
||||
int rproc_add(struct rproc *rproc)
|
||||
- Register @rproc with the remoteproc framework, after it has been
|
||||
allocated with rproc_alloc().
|
||||
This is called by the platform-specific rproc implementation, whenever
|
||||
|
|
@ -142,20 +117,15 @@ int dummy_rproc_example(struct rproc *my_rproc)
|
|||
of registering this remote processor, additional virtio drivers might get
|
||||
probed.
|
||||
|
||||
int rproc_unregister(struct rproc *rproc)
|
||||
- Unregister a remote processor, and decrement its refcount.
|
||||
If its refcount drops to zero, then @rproc will be freed. If not,
|
||||
it will be freed later once the last reference is dropped.
|
||||
|
||||
int rproc_del(struct rproc *rproc)
|
||||
- Unroll rproc_add().
|
||||
This function should be called when the platform specific rproc
|
||||
implementation decides to remove the rproc device. it should
|
||||
_only_ be called if a previous invocation of rproc_register()
|
||||
_only_ be called if a previous invocation of rproc_add()
|
||||
has completed successfully.
|
||||
|
||||
After rproc_unregister() returns, @rproc is _not_ valid anymore and
|
||||
it shouldn't be used. More specifically, don't call rproc_free()
|
||||
or try to directly free @rproc after rproc_unregister() returns;
|
||||
none of these are needed, and calling them is a bug.
|
||||
After rproc_del() returns, @rproc is still valid, and its
|
||||
last refcount should be decremented by calling rproc_put().
|
||||
|
||||
Returns 0 on success and -EINVAL if @rproc isn't valid.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Everything you ever wanted to know about Linux 2.6 -stable releases.
|
||||
Everything you ever wanted to know about Linux -stable releases.
|
||||
|
||||
Rules on what kind of patches are accepted, and which ones are not, into the
|
||||
"-stable" tree:
|
||||
|
|
@ -42,10 +42,10 @@ Procedure for submitting patches to the -stable tree:
|
|||
cherry-picked than this can be specified in the following format in
|
||||
the sign-off area:
|
||||
|
||||
Cc: <stable@vger.kernel.org> # .32.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@vger.kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@vger.kernel.org> # .32.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@vger.kernel.org> # .32.x
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||
|
||||
The tag sequence has the meaning of:
|
||||
|
|
@ -79,6 +79,15 @@ Review cycle:
|
|||
security kernel team, and not go through the normal review cycle.
|
||||
Contact the kernel security team for more details on this procedure.
|
||||
|
||||
Trees:
|
||||
|
||||
- The queues of patches, for both completed versions and in progress
|
||||
versions can be found at:
|
||||
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git
|
||||
- The finalized and tagged releases of all stable kernels can be found
|
||||
in separate branches per version at:
|
||||
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git
|
||||
|
||||
|
||||
Review committee:
|
||||
|
||||
|
|
|
|||
|
|
@ -163,16 +163,22 @@ This value can be used to query and set the core dump mode for setuid
|
|||
or otherwise protected/tainted binaries. The modes are
|
||||
|
||||
0 - (default) - traditional behaviour. Any process which has changed
|
||||
privilege levels or is execute only will not be dumped
|
||||
privilege levels or is execute only will not be dumped.
|
||||
1 - (debug) - all processes dump core when possible. The core dump is
|
||||
owned by the current user and no security is applied. This is
|
||||
intended for system debugging situations only. Ptrace is unchecked.
|
||||
This is insecure as it allows regular users to examine the memory
|
||||
contents of privileged processes.
|
||||
2 - (suidsafe) - any binary which normally would not be dumped is dumped
|
||||
readable by root only. This allows the end user to remove
|
||||
such a dump but not access it directly. For security reasons
|
||||
core dumps in this mode will not overwrite one another or
|
||||
other files. This mode is appropriate when administrators are
|
||||
attempting to debug problems in a normal environment.
|
||||
anyway, but only if the "core_pattern" kernel sysctl is set to
|
||||
either a pipe handler or a fully qualified path. (For more details
|
||||
on this limitation, see CVE-2006-2451.) This mode is appropriate
|
||||
when administrators are attempting to debug problems in a normal
|
||||
environment, and either have a core dump pipe handler that knows
|
||||
to treat privileged core dumps with care, or specific directory
|
||||
defined for catching core dumps. If a core dump happens without
|
||||
a pipe handler or fully qualifid path, a message will be emitted
|
||||
to syslog warning about the lack of a correct setting.
|
||||
|
||||
==============================================================
|
||||
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче