提交 80b304fd 编写于 作者: I Ingo Molnar

Merge tag 'efi-urgent' of...

Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent

Pull EFI fixes from Matt Fleming:

 * WARN_ON(!spin_is_locked()) always triggers on non-SMP machines.
   Swap it for the more canonical lockdep_assert_held() which always
   does the right thing - Guenter Roeck

 * Assign the correct value to efi.runtime_version on arm64 so that all
   the runtime services can be invoked - Semen Protsenko
Signed-off-by: NIngo Molnar <mingo@kernel.org>

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
...@@ -34,6 +34,7 @@ ...@@ -34,6 +34,7 @@
*.gcno *.gcno
modules.builtin modules.builtin
Module.symvers Module.symvers
*.dwo
# #
# Top-level generic files # Top-level generic files
......
...@@ -1381,6 +1381,9 @@ S: 17 rue Danton ...@@ -1381,6 +1381,9 @@ S: 17 rue Danton
S: F - 94270 Le Kremlin-Bicêtre S: F - 94270 Le Kremlin-Bicêtre
S: France S: France
N: Jack Hammer
D: IBM ServeRAID RAID (ips) driver maintenance
N: Greg Hankins N: Greg Hankins
E: gregh@cc.gatech.edu E: gregh@cc.gatech.edu
D: fixed keyboard driver to separate LED and locking status D: fixed keyboard driver to separate LED and locking status
...@@ -1691,6 +1694,10 @@ S: Reading ...@@ -1691,6 +1694,10 @@ S: Reading
S: RG6 2NU S: RG6 2NU
S: United Kingdom S: United Kingdom
N: Dave Jeffery
E: dhjeffery@gmail.com
D: SCSI hacks and IBM ServeRAID RAID driver maintenance
N: Jakub Jelinek N: Jakub Jelinek
E: jakub@redhat.com E: jakub@redhat.com
W: http://sunsite.mff.cuni.cz/~jj W: http://sunsite.mff.cuni.cz/~jj
......
...@@ -3,13 +3,13 @@ Date: May 2007 ...@@ -3,13 +3,13 @@ Date: May 2007
KernelVersion: 2.6.23 KernelVersion: 2.6.23
Contact: Alan Stern <stern@rowland.harvard.edu> Contact: Alan Stern <stern@rowland.harvard.edu>
Description: Description:
If CONFIG_USB_PERSIST is set, then each USB device directory USB device directories can contain a file named power/persist.
will contain a file named power/persist. The file holds a The file holds a boolean value (0 or 1) indicating whether or
boolean value (0 or 1) indicating whether or not the not the "USB-Persist" facility is enabled for the device. For
"USB-Persist" facility is enabled for the device. Since the hubs this facility is always enabled and their device
facility is inherently dangerous, it is disabled by default directories will not contain this file.
for all devices except hubs. For more information, see
Documentation/usb/persist.txt. For more information, see Documentation/usb/persist.txt.
What: /sys/bus/usb/devices/.../power/autosuspend What: /sys/bus/usb/devices/.../power/autosuspend
Date: March 2007 Date: March 2007
......
...@@ -26,6 +26,7 @@ Description: ...@@ -26,6 +26,7 @@ Description:
option: [[appraise_type=]] [permit_directio] option: [[appraise_type=]] [permit_directio]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK] base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC] mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value fsmagic:= hex value
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6) fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
...@@ -57,7 +58,8 @@ Description: ...@@ -57,7 +58,8 @@ Description:
measure func=BPRM_CHECK measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0 measure func=FILE_CHECK mask=MAY_READ uid=0
measure func=MODULE_CHECK uid=0 measure func=MODULE_CHECK
measure func=FIRMWARE_CHECK
appraise fowner=0 appraise fowner=0
The default policy measures all executables in bprm_check, The default policy measures all executables in bprm_check,
......
...@@ -260,6 +260,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale ...@@ -260,6 +260,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
KernelVersion: 2.6.35 KernelVersion: 2.6.35
...@@ -447,6 +451,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en ...@@ -447,6 +451,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
...@@ -492,6 +504,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en ...@@ -492,6 +504,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en
What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en
What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en
What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en
...@@ -538,6 +558,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value ...@@ -538,6 +558,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value
What: /sys/.../events/in_magn_y_raw_thresh_falling_value What: /sys/.../events/in_magn_y_raw_thresh_falling_value
What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_rising_value
What: /sys/.../events/in_magn_z_raw_thresh_falling_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value
What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value
What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value
What: /sys/.../events/in_voltageY_raw_thresh_rising_value What: /sys/.../events/in_voltageY_raw_thresh_rising_value
...@@ -588,6 +616,18 @@ What: /sys/.../events/in_magn_y_thresh_either_hysteresis ...@@ -588,6 +616,18 @@ What: /sys/.../events/in_magn_y_thresh_either_hysteresis
What: /sys/.../events/in_magn_z_thresh_rising_hysteresis What: /sys/.../events/in_magn_z_thresh_rising_hysteresis
What: /sys/.../events/in_magn_z_thresh_falling_hysteresis What: /sys/.../events/in_magn_z_thresh_falling_hysteresis
What: /sys/.../events/in_magn_z_thresh_either_hysteresis What: /sys/.../events/in_magn_z_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_true_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_true_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_true_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_either_hysteresis
What: /sys/.../events/in_voltageY_thresh_rising_hysteresis What: /sys/.../events/in_voltageY_thresh_rising_hysteresis
What: /sys/.../events/in_voltageY_thresh_falling_hysteresis What: /sys/.../events/in_voltageY_thresh_falling_hysteresis
What: /sys/.../events/in_voltageY_thresh_either_hysteresis What: /sys/.../events/in_voltageY_thresh_either_hysteresis
...@@ -635,6 +675,14 @@ What: /sys/.../events/in_magn_y_raw_roc_rising_value ...@@ -635,6 +675,14 @@ What: /sys/.../events/in_magn_y_raw_roc_rising_value
What: /sys/.../events/in_magn_y_raw_roc_falling_value What: /sys/.../events/in_magn_y_raw_roc_falling_value
What: /sys/.../events/in_magn_z_raw_roc_rising_value What: /sys/.../events/in_magn_z_raw_roc_rising_value
What: /sys/.../events/in_magn_z_raw_roc_falling_value What: /sys/.../events/in_magn_z_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_true_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_true_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_roc_falling_value
What: /sys/.../events/in_voltageY_supply_raw_roc_rising_value What: /sys/.../events/in_voltageY_supply_raw_roc_rising_value
What: /sys/.../events/in_voltageY_supply_raw_roc_falling_value What: /sys/.../events/in_voltageY_supply_raw_roc_falling_value
What: /sys/.../events/in_voltageY_raw_roc_rising_value What: /sys/.../events/in_voltageY_raw_roc_rising_value
...@@ -690,6 +738,22 @@ What: /sys/.../events/in_magn_z_thresh_rising_period ...@@ -690,6 +738,22 @@ What: /sys/.../events/in_magn_z_thresh_rising_period
What: /sys/.../events/in_magn_z_thresh_falling_period What: /sys/.../events/in_magn_z_thresh_falling_period
What: /sys/.../events/in_magn_z_roc_rising_period What: /sys/.../events/in_magn_z_roc_rising_period
What: /sys/.../events/in_magn_z_roc_falling_period What: /sys/.../events/in_magn_z_roc_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_thresh_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_thresh_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_roc_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_roc_falling_period
What: /sys/.../events/in_rot_from_north_true_thresh_rising_period
What: /sys/.../events/in_rot_from_north_true_thresh_falling_period
What: /sys/.../events/in_rot_from_north_true_roc_rising_period
What: /sys/.../events/in_rot_from_north_true_roc_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_roc_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_roc_falling_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_rising_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_falling_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_roc_rising_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_roc_falling_period
What: /sys/.../events/in_voltageY_supply_thresh_rising_period What: /sys/.../events/in_voltageY_supply_thresh_rising_period
What: /sys/.../events/in_voltageY_supply_thresh_falling_period What: /sys/.../events/in_voltageY_supply_thresh_falling_period
What: /sys/.../events/in_voltageY_supply_roc_rising_period What: /sys/.../events/in_voltageY_supply_roc_rising_period
...@@ -787,6 +851,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en ...@@ -787,6 +851,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
...@@ -853,6 +921,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index ...@@ -853,6 +921,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
...@@ -895,6 +967,19 @@ Description: ...@@ -895,6 +967,19 @@ Description:
on-chip EEPROM. After power-up or chip reset the device will on-chip EEPROM. After power-up or chip reset the device will
automatically load the saved configuration. automatically load the saved configuration.
What: /sys/.../iio:deviceX/in_proximity_raw
What: /sys/.../iio:deviceX/in_proximity_input
What: /sys/.../iio:deviceX/in_proximityY_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
Proximity measurement indicating that some
object is near the sensor, usually be observing
reflectivity of infrared or ultrasound emitted.
Often these sensors are unit less and as such conversion
to SI units is not possible. Where it is, the units should
be meters.
What: /sys/.../iio:deviceX/in_illuminanceY_input What: /sys/.../iio:deviceX/in_illuminanceY_input
What: /sys/.../iio:deviceX/in_illuminanceY_raw What: /sys/.../iio:deviceX/in_illuminanceY_raw
What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw
...@@ -933,3 +1018,13 @@ Description: ...@@ -933,3 +1018,13 @@ Description:
x y z w. Here x, y, and z component represents the axis about x y z w. Here x, y, and z component represents the axis about
which a rotation will occur and w component represents the which a rotation will occur and w component represents the
amount of rotation. amount of rotation.
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_raw
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_raw
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_raw
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_raw
KernelVersion: 3.15
Contact: linux-iio@vger.kernel.org
Description:
Raw value of rotation from true/magnetic north measured with
or without compensation from tilt sensors.
What: /sys/bus/platform/devices/.../driver_override
Date: April 2014
Contact: Kim Phillips <kim.phillips@freescale.com>
Description:
This file allows the driver for a device to be specified which
will override standard OF, ACPI, ID table, and name matching.
When specified, only a driver with a name matching the value
written to driver_override will have an opportunity to bind
to the device. The override is specified by writing a string
to the driver_override file (echo vfio-platform > \
driver_override) and may be cleared with an empty string
(echo > driver_override). This returns the device to standard
matching rules binding. Writing to driver_override does not
automatically unbind the device from its current driver or make
any attempt to automatically load the specified driver. If no
driver with a matching name is currently loaded in the kernel,
the device will not bind to any driver. This also allows
devices to opt-out of driver binding using a driver_override
name such as "none". Only a single driver may be specified in
the override, there is no support for parsing delimiters.
...@@ -94,5 +94,5 @@ current_snap ...@@ -94,5 +94,5 @@ current_snap
parent parent
Information identifying the pool, image, and snapshot id for Information identifying the chain of parent images in a layered rbd
the parent image in a layered rbd image (format 2 only). image. Entries are separated by empty lines.
Link Layer Validation Device is a standard device for testing of Super
Speed Link Layer tests. These nodes are available in sysfs only when lvs
driver is bound with root hub device.
What: /sys/bus/usb/devices/.../get_dev_desc
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "Get Device Descriptor"
for Link Layer Validation device. It is needed for TD.7.06.
What: /sys/bus/usb/devices/.../u1_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Set "U1 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.
What: /sys/bus/usb/devices/.../u2_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Set "U2 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.
What: /sys/bus/usb/devices/.../hot_reset
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "Reset" for Link Layer Validation
device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
What: /sys/bus/usb/devices/.../u3_entry
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "U3 entry" for Link Layer
Validation device. It is needed for TD.7.35 and TD.7.36.
What: /sys/bus/usb/devices/.../u3_exit
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "U3 exit" for Link Layer
Validation device. It is needed for TD.7.36.
What: /sys/class/iommu/<iommu>/devices/
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU drivers are able to link devices managed by a
given IOMMU here to allow association of IOMMU to
device.
What: /sys/devices/.../iommu
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU drivers are able to link the IOMMU for a
given device here to allow association of device to
IOMMU.
What: /sys/class/iommu/<iommu>/amd-iommu/cap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU capability header as documented in the AMD IOMMU
specification. Format: %x
What: /sys/class/iommu/<iommu>/amd-iommu/features
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
Extended features of the IOMMU. Format: %llx
What: /sys/class/iommu/<iommu>/intel-iommu/address
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
Physical address of the VT-d DRHD for this IOMMU.
Format: %llx. This allows association of a sysfs
intel-iommu with a DMAR DRHD table entry.
What: /sys/class/iommu/<iommu>/intel-iommu/cap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The cached hardware capability register value
of this DRHD unit. Format: %llx.
What: /sys/class/iommu/<iommu>/intel-iommu/ecap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The cached hardware extended capability register
value of this DRHD unit. Format: %llx.
What: /sys/class/iommu/<iommu>/intel-iommu/version
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The architecture version as reported from the
VT-d VER_REG. Format: %d:%d, major:minor
What: /sys/class/leds/<led>/gt683r/mode
Date: Jun 2014
KernelVersion: 3.17
Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
Description:
Set the mode of LEDs. You should notice that changing the mode
of one LED will update the mode of its two sibling devices as
well.
0 - normal
1 - audio
2 - breathing
Normal: LEDs are fully on when enabled
Audio: LEDs brightness depends on sound level
Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
What: /sys/class/mei/
Date: May 2014
KernelVersion: 3.17
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description:
The mei/ class sub-directory belongs to mei device class
What: /sys/class/mei/meiN/
Date: May 2014
KernelVersion: 3.17
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description:
The /sys/class/mei/meiN directory is created for
each probed mei device
...@@ -184,3 +184,41 @@ Description: ...@@ -184,3 +184,41 @@ Description:
It will always be a non-negative integer. In the case of It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0. devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/ecc_failures
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of failures reported by this device's ECC. Typically,
these failures are associated with failed read operations.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/corrected_bits
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of bits that have been corrected by means of the
device's ECC.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/bad_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks marked as bad, if any, in this partition.
What: /sys/class/mtd/mtdX/bbt_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks that are marked as reserved, if any, in
this partition. These are typically used to store the in-flash
bad block table (BBT).
What: /sys/class/net/<iface>/name_assign_type
Date: July 2014
KernelVersion: 3.17
Contact: netdev@vger.kernel.org
Description:
Indicates the name assignment type. Possible values are:
1: enumerated by the kernel, possibly in an unpredictable way
2: predictably named by the kernel
3: named by userspace
4: renamed
What: /sys/class/net/<iface>/addr_assign_type What: /sys/class/net/<iface>/addr_assign_type
Date: July 2010 Date: July 2010
KernelVersion: 3.2 KernelVersion: 3.2
......
...@@ -25,6 +25,15 @@ Date: Oct 2013 ...@@ -25,6 +25,15 @@ Date: Oct 2013
Contact: haver@linux.vnet.ibm.com Contact: haver@linux.vnet.ibm.com
Description: Interface to set the next bitstream to be used. Description: Interface to set the next bitstream to be used.
What: /sys/class/genwqe/genwqe<n>_card/reload_bitstream
Date: May 2014
Contact: klebers@linux.vnet.ibm.com
Description: Interface to trigger a PCIe card reset to reload the bitstream.
sudo sh -c 'echo 1 > \
/sys/class/genwqe/genwqe0_card/reload_bitstream'
If successfully, the card will come back with the bitstream set
on 'next_bitstream'.
What: /sys/class/genwqe/genwqe<n>_card/tempsens What: /sys/class/genwqe/genwqe<n>_card/tempsens
Date: Oct 2013 Date: Oct 2013
Contact: haver@linux.vnet.ibm.com Contact: haver@linux.vnet.ibm.com
......
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be
is being controlled by press_speed.
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled.
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate
a left or right mouse button click.
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This file contains the trackpoint sensitivity.
Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity).
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled.
Values are decimal integers from 1 (slowest) to 255 (fastest).
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fn_lock
Date: July 2014
Contact: linux-input@vger.kernel.org
Description: This setting controls whether Fn Lock is enabled on the keyboard (i.e. if F1 is Mute or F1)
Values are 0 or 1
Applies to ThinkPad Compact (USB|Bluetooth) Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be
is being controlled by press_speed.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate
a left or right mouse button click.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This file contains the trackpoint sensitivity.
Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity).
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled.
Values are decimal integers from 1 (slowest) to 255 (fastest).
What: /sys/bus/pci/drivers/pciback/quirks
Date: Oct 2011
KernelVersion: 3.1
Contact: xen-devel@lists.xenproject.org
Description:
If the permissive attribute is set, then writing a string in
the format of DDDD:BB:DD.F-REG:SIZE:MASK will allow the guest
to write and read from the PCI device. That is Domain:Bus:
Device.Function-Register:Size:Mask (Domain is optional).
For example:
#echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
will allow the guest to read and write to the configuration
register 0x0E.
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is layed out in 32bit
words in LSB first format. Each bit represents a single value
as decoded from the fuse registers. Bits order/assignment
exactly matches the HW registers, including any unused bits.
Users: any user space application which wants to read the efuses on
Tegra SoC's
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
Date: June 2012
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/oled*_img files control
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
has to contain 256 bytes (64x32 px 1 bit colour). The format
is the same as PBM image 62x32px without header (64 bits per
horizontal line, 32 lines). An example of setting OLED No. 0:
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
The attribute is read only and no local copy of the image is
stored.
What: /sys/class/hidraw/hidraw*/device/speed
Date: April 2010 Date: April 2010
Kernel Version: 2.6.35 Kernel Version: 2.6.35
Contact: linux-bluetooth@vger.kernel.org Contact: linux-bluetooth@vger.kernel.org
Description: Description:
The /sys/class/hidraw/hidraw*/device/speed file controls The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
reporting speed of Wacom bluetooth tablet. Reading from controls reporting speed of Wacom bluetooth tablet. Reading
this file returns 1 if tablet reports in high speed mode from this file returns 1 if tablet reports in high speed mode
or 0 otherwise. Writing to this file one of these values or 0 otherwise. Writing to this file one of these values
switches reporting speed. switches reporting speed.
What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/ What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
Date: May 2012 Date: August 2014
Kernel Version: 3.5
Contact: linux-bluetooth@vger.kernel.org
Description:
LED selector for Intuos4 WL. There are 4 leds, but only one LED
can be lit at a time. Max brightness is 127.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
Date: August 2011
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
Attribute group for control of the status LEDs and the OLEDs. Attribute group for control of the status LEDs and the OLEDs.
This attribute group is only available for Intuos 4 M, L, This attribute group is only available for Intuos 4 M, L,
and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
21UX2 and Cintiq 24HD (LEDs only). Therefore its presence Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
implicitly signifies the presence of said LEDs and OLEDs on the (LEDs only). Therefore its presence implicitly signifies the
tablet device. presence of said LEDs and OLEDs on the tablet device.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
Date: August 2011 Date: August 2014
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
Writing to this file sets the status LED luminance (1..127) Writing to this file sets the status LED luminance (1..127)
...@@ -50,16 +29,16 @@ Description: ...@@ -50,16 +29,16 @@ Description:
button is pressed on the stylus. This luminance level is button is pressed on the stylus. This luminance level is
normally lower than the level when a button is pressed. normally lower than the level when a button is pressed.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
Date: August 2011 Date: August 2014
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
Writing to this file sets the status LED luminance (1..127) Writing to this file sets the status LED luminance (1..127)
when the stylus touches the tablet surface, or any button is when the stylus touches the tablet surface, or any button is
pressed on the stylus. pressed on the stylus.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
Date: August 2011 Date: August 2014
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
Writing to this file sets which one of the four (for Intuos 4 Writing to this file sets which one of the four (for Intuos 4
...@@ -67,23 +46,23 @@ Description: ...@@ -67,23 +46,23 @@ Description:
24HD) status LEDs is active (0..3). The other three LEDs on the 24HD) status LEDs is active (0..3). The other three LEDs on the
same side are always inactive. same side are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
Date: September 2011 Date: August 2014
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
Writing to this file sets which one of the left four (for Cintiq 21UX2 Writing to this file sets which one of the left four (for Cintiq 21UX2
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
the left are always inactive. the left are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
Date: August 2011 Date: August 2014
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
Writing to this file sets the overall luminance level (0..15) Writing to this file sets the overall luminance level (0..15)
of all eight button OLED displays. of all eight button OLED displays.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
Date: August 2011 Date: August 2014
Contact: linux-input@vger.kernel.org Contact: linux-input@vger.kernel.org
Description: Description:
When writing a 1024 byte raw image in Wacom Intuos 4 When writing a 1024 byte raw image in Wacom Intuos 4
...@@ -93,3 +72,8 @@ Description: ...@@ -93,3 +72,8 @@ Description:
byte chunk encodes the image data for two consecutive lines on byte chunk encodes the image data for two consecutive lines on
the display. The low nibble of each byte contains the first the display. The low nibble of each byte contains the first
line, and the high nibble contains the second line. line, and the high nibble contains the second line.
When the Wacom Intuos 4 is connected over Bluetooth, the
image has to contain 256 bytes (64x32 px 1 bit colour).
The format is also scrambled, like in the USB mode, and it can
be summarized by converting 76543210 into GECA6420.
HGFEDCBA HFDB7531
What: /sys/fs/nilfs2/features/revision
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show current revision of NILFS file system driver.
This value informs about file system revision that
driver is ready to support.
What: /sys/fs/nilfs2/features/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/features group.
What: /sys/fs/nilfs2/<device>/revision
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show NILFS file system revision on volume.
This value informs about metadata structures'
revision on mounted volume.
What: /sys/fs/nilfs2/<device>/blocksize
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's block size in bytes.
What: /sys/fs/nilfs2/<device>/device_size
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume size in bytes.
What: /sys/fs/nilfs2/<device>/free_blocks
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of free blocks on volume.
What: /sys/fs/nilfs2/<device>/uuid
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's UUID (Universally Unique Identifier).
What: /sys/fs/nilfs2/<device>/volume_name
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's label.
What: /sys/fs/nilfs2/<device>/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device> group.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show last write time of super block in human-readable
format.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show last write time of super block in seconds.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show current write count of super block.
What: /sys/fs/nilfs2/<device>/superblock/sb_update_frequency
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show/Set interval of periodical update of superblock
(in seconds).
What: /sys/fs/nilfs2/<device>/superblock/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/superblock
group.
What: /sys/fs/nilfs2/<device>/segctor/last_pseg_block
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show start block number of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_sequence
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show sequence value of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show checkpoint number of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/current_seg_sequence
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show segment sequence counter.
What: /sys/fs/nilfs2/<device>/segctor/current_last_full_seg
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show index number of the latest full segment.
What: /sys/fs/nilfs2/<device>/segctor/next_full_seg
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show index number of the full segment index
to be used next.
What: /sys/fs/nilfs2/<device>/segctor/next_pseg_offset
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show offset of next partial segment in the current
full segment.
What: /sys/fs/nilfs2/<device>/segctor/next_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show next checkpoint number.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment in
human-readable format.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment in seconds.
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment not for cleaner
operation in human-readable format.
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment not for cleaner
operation in seconds.
What: /sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of dirty data blocks.
What: /sys/fs/nilfs2/<device>/segctor/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/segctor
group.
What: /sys/fs/nilfs2/<device>/segments/segments_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of segments on a volume.
What: /sys/fs/nilfs2/<device>/segments/blocks_per_segment
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of blocks in segment.
What: /sys/fs/nilfs2/<device>/segments/clean_segments
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of clean segments.
What: /sys/fs/nilfs2/<device>/segments/dirty_segments
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of dirty segments.
What: /sys/fs/nilfs2/<device>/segments/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/segments
group.
What: /sys/fs/nilfs2/<device>/checkpoints/checkpoints_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of checkpoints on volume.
What: /sys/fs/nilfs2/<device>/checkpoints/snapshots_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of snapshots on volume.
What: /sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show checkpoint number of the latest segment.
What: /sys/fs/nilfs2/<device>/checkpoints/next_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show next checkpoint number.
What: /sys/fs/nilfs2/<device>/checkpoints/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/checkpoints
group.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots
group.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of inodes for snapshot.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of blocks for snapshot.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id>
group.
What: /sys/fs/xfs/<disk>/log/log_head_lsn
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The log sequence number (LSN) of the current head of the
log. The LSN is exported in "cycle:basic block" format.
Users: xfstests
What: /sys/fs/xfs/<disk>/log/log_tail_lsn
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The log sequence number (LSN) of the current tail of the
log. The LSN is exported in "cycle:basic block" format.
What: /sys/fs/xfs/<disk>/log/reserve_grant_head
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The current state of the log reserve grant head. It
represents the total log reservation of all currently
outstanding transactions. The grant head is exported in
"cycle:bytes" format.
Users: xfstests
What: /sys/fs/xfs/<disk>/log/write_grant_head
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The current state of the log write grant head. It
represents the total log reservation of all currently
oustanding transactions, including regrants due to
rolling transactions. The grant head is exported in
"cycle:bytes" format.
Users: xfstests
...@@ -138,3 +138,19 @@ Description: ...@@ -138,3 +138,19 @@ Description:
These sysfs values expose the TIOCGSERIAL interface via These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls. sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/rx_trig_bytes
Date: May 2014
Contact: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Description:
Shows current RX interrupt trigger bytes or sets the
user specified value to change it for the FIFO buffer.
Users can show or set this value regardless of opening the
serial device file or not.
The RX trigger can be set one of four kinds of values for UART
serials. When users input a meaning less value to this I/F,
the RX trigger is changed to the nearest lower value for the
device specification. For example, when user sets 7bytes on
16550A, which has 1/4/8/14 bytes trigger, the RX trigger is
automatically changed to 4 bytes.
...@@ -54,7 +54,7 @@ ...@@ -54,7 +54,7 @@
!Ikernel/sched/cpupri.c !Ikernel/sched/cpupri.c
!Ikernel/sched/fair.c !Ikernel/sched/fair.c
!Iinclude/linux/completion.h !Iinclude/linux/completion.h
!Ekernel/timer.c !Ekernel/time/timer.c
</sect1> </sect1>
<sect1><title>Wait queues and Wake events</title> <sect1><title>Wait queues and Wake events</title>
!Iinclude/linux/wait.h !Iinclude/linux/wait.h
...@@ -63,7 +63,7 @@ ...@@ -63,7 +63,7 @@
<sect1><title>High-resolution timers</title> <sect1><title>High-resolution timers</title>
!Iinclude/linux/ktime.h !Iinclude/linux/ktime.h
!Iinclude/linux/hrtimer.h !Iinclude/linux/hrtimer.h
!Ekernel/hrtimer.c !Ekernel/time/hrtimer.c
</sect1> </sect1>
<sect1><title>Workqueues and Kevents</title> <sect1><title>Workqueues and Kevents</title>
!Ekernel/workqueue.c !Ekernel/workqueue.c
...@@ -128,8 +128,12 @@ X!Edrivers/base/interface.c ...@@ -128,8 +128,12 @@ X!Edrivers/base/interface.c
!Edrivers/base/bus.c !Edrivers/base/bus.c
</sect1> </sect1>
<sect1><title>Device Drivers DMA Management</title> <sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-buf.c !Edrivers/dma-buf/dma-buf.c
!Edrivers/base/reservation.c !Edrivers/dma-buf/fence.c
!Edrivers/dma-buf/seqno-fence.c
!Iinclude/linux/fence.h
!Iinclude/linux/seqno-fence.h
!Edrivers/dma-buf/reservation.c
!Iinclude/linux/reservation.h !Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c !Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c !Edrivers/base/dma-mapping.c
......
...@@ -315,7 +315,7 @@ char *date;</synopsis> ...@@ -315,7 +315,7 @@ char *date;</synopsis>
<function>drm_dev_unregister()</function> followed by a call to <function>drm_dev_unregister()</function> followed by a call to
<function>drm_dev_unref()</function>. <function>drm_dev_unref()</function>.
</para> </para>
!Edrivers/gpu/drm/drm_stub.c !Edrivers/gpu/drm/drm_drv.c
</sect2> </sect2>
<sect2> <sect2>
<title>Driver Load</title> <title>Driver Load</title>
...@@ -1610,7 +1610,7 @@ int max_width, max_height;</synopsis> ...@@ -1610,7 +1610,7 @@ int max_width, max_height;</synopsis>
The connector is then registered with a call to The connector is then registered with a call to
<function>drm_connector_init</function> with a pointer to the connector <function>drm_connector_init</function> with a pointer to the connector
functions and a connector type, and exposed through sysfs with a call to functions and a connector type, and exposed through sysfs with a call to
<function>drm_sysfs_connector_add</function>. <function>drm_connector_register</function>.
</para> </para>
<para> <para>
Supported connector types are Supported connector types are
...@@ -1768,7 +1768,7 @@ int max_width, max_height;</synopsis> ...@@ -1768,7 +1768,7 @@ int max_width, max_height;</synopsis>
(<function>drm_encoder_cleanup</function>) and connectors (<function>drm_encoder_cleanup</function>) and connectors
(<function>drm_connector_cleanup</function>). Furthermore, connectors (<function>drm_connector_cleanup</function>). Furthermore, connectors
that have been added to sysfs must be removed by a call to that have been added to sysfs must be removed by a call to
<function>drm_sysfs_connector_remove</function> before calling <function>drm_connector_unregister</function> before calling
<function>drm_connector_cleanup</function>. <function>drm_connector_cleanup</function>.
</para> </para>
<para> <para>
...@@ -1813,7 +1813,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -1813,7 +1813,7 @@ void intel_crt_init(struct drm_device *dev)
drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs); drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs); drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
drm_sysfs_connector_add(connector); drm_connector_register(connector);
}]]></programlisting> }]]></programlisting>
<para> <para>
In the example above (taken from the i915 driver), a CRTC, connector and In the example above (taken from the i915 driver), a CRTC, connector and
...@@ -2336,6 +2336,12 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2336,6 +2336,12 @@ void intel_crt_init(struct drm_device *dev)
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
!Iinclude/drm/drm_dp_helper.h !Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c !Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
<sect2>
<title>Display Port MST Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
!Iinclude/drm/drm_dp_mst_helper.h
!Edrivers/gpu/drm/drm_dp_mst_topology.c
</sect2> </sect2>
<sect2> <sect2>
<title>EDID Helper Functions Reference</title> <title>EDID Helper Functions Reference</title>
...@@ -2502,7 +2508,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2502,7 +2508,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td> <td valign="top" >Description/Restrictions</td>
</tr> </tr>
<tr> <tr>
<td rowspan="20" valign="top" >DRM</td> <td rowspan="21" valign="top" >DRM</td>
<td rowspan="2" valign="top" >Generic</td> <td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“EDID”</td> <td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td> <td valign="top" >BLOB | IMMUTABLE</td>
...@@ -2633,7 +2639,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2633,7 +2639,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td rowspan="2" valign="top" >Optional</td> <td rowspan="3" valign="top" >Optional</td>
<td valign="top" >“scaling mode”</td> <td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td> <td valign="top" >ENUM</td>
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td> <td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
...@@ -2641,6 +2647,15 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2641,6 +2647,15 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td valign="top" >"aspect ratio"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "4:3", "16:9" }</td>
<td valign="top" >Connector</td>
<td valign="top" >DRM property to set aspect ratio from user space app.
This enum is made generic to allow addition of custom aspect
ratios.</td>
</tr>
<tr>
<td valign="top" >“dirty”</td> <td valign="top" >“dirty”</td>
<td valign="top" >ENUM | IMMUTABLE</td> <td valign="top" >ENUM | IMMUTABLE</td>
<td valign="top" >{ "Off", "On", "Annotate" }</td> <td valign="top" >{ "Off", "On", "Annotate" }</td>
...@@ -2649,7 +2664,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2649,7 +2664,7 @@ void intel_crt_init(struct drm_device *dev)
</tr> </tr>
<tr> <tr>
<td rowspan="21" valign="top" >i915</td> <td rowspan="21" valign="top" >i915</td>
<td rowspan="3" valign="top" >Generic</td> <td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td> <td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td> <td valign="top" >ENUM</td>
<td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td> <td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
...@@ -2664,10 +2679,11 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2664,10 +2679,11 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td valign="top" >Standard name as in DRM</td> <td rowspan="1" valign="top" >Plane</td>
<td valign="top" >Standard type as in DRM</td> <td valign="top" >“rotation”</td>
<td valign="top" >Standard value as in DRM</td> <td valign="top" >BITMASK</td>
<td valign="top" >Standard Object as in DRM</td> <td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td>
<td valign="top" >Plane</td>
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
...@@ -2799,8 +2815,8 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2799,8 +2815,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td rowspan="3" valign="top" >CDV gma-500</td> <td rowspan="2" valign="top" >CDV gma-500</td>
<td rowspan="3" valign="top" >Generic</td> <td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td> <td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td> <td valign="top" >ENUM</td>
<td valign="top" >{ “Full”, “Limited 16:235” }</td> <td valign="top" >{ “Full”, “Limited 16:235” }</td>
...@@ -2815,15 +2831,8 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2815,15 +2831,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td valign="top" >Standard name as in DRM</td> <td rowspan="19" valign="top" >Poulsbo</td>
<td valign="top" >Standard type as in DRM</td> <td rowspan="1" valign="top" >Generic</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="20" valign="top" >Poulsbo</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“backlight”</td> <td valign="top" >“backlight”</td>
<td valign="top" >RANGE</td> <td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=100</td> <td valign="top" >Min=0, Max=100</td>
...@@ -2831,13 +2840,6 @@ void intel_crt_init(struct drm_device *dev) ...@@ -2831,13 +2840,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="17" valign="top" >SDVO-TV</td> <td rowspan="17" valign="top" >SDVO-TV</td>
<td valign="top" >“mode”</td> <td valign="top" >“mode”</td>
<td valign="top" >ENUM</td> <td valign="top" >ENUM</td>
...@@ -3064,7 +3066,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -3064,7 +3066,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td rowspan="3" valign="top" >i2c/ch7006_drv</td> <td rowspan="2" valign="top" >i2c/ch7006_drv</td>
<td valign="top" >Generic</td> <td valign="top" >Generic</td>
<td valign="top" >“scale”</td> <td valign="top" >“scale”</td>
<td valign="top" >RANGE</td> <td valign="top" >RANGE</td>
...@@ -3073,14 +3075,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -3073,14 +3075,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td rowspan="2" valign="top" >TV</td> <td rowspan="1" valign="top" >TV</td>
<td valign="top" >Standard names as in DRM</td>
<td valign="top" >Standard types as in DRM</td>
<td valign="top" >Standard Values as in DRM</td>
<td valign="top" >Standard object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >“mode”</td> <td valign="top" >“mode”</td>
<td valign="top" >ENUM</td> <td valign="top" >ENUM</td>
<td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" <td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
...@@ -3089,7 +3084,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -3089,7 +3084,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td rowspan="16" valign="top" >nouveau</td> <td rowspan="15" valign="top" >nouveau</td>
<td rowspan="6" valign="top" >NV10 Overlay</td> <td rowspan="6" valign="top" >NV10 Overlay</td>
<td valign="top" >"colorkey"</td> <td valign="top" >"colorkey"</td>
<td valign="top" >RANGE</td> <td valign="top" >RANGE</td>
...@@ -3198,14 +3193,6 @@ void intel_crt_init(struct drm_device *dev) ...@@ -3198,14 +3193,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td valign="top" >Generic</td>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >omap</td> <td rowspan="2" valign="top" >omap</td>
<td rowspan="2" valign="top" >Generic</td> <td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“rotation”</td> <td valign="top" >“rotation”</td>
...@@ -3236,7 +3223,7 @@ void intel_crt_init(struct drm_device *dev) ...@@ -3236,7 +3223,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td rowspan="10" valign="top" >radeon</td> <td rowspan="9" valign="top" >radeon</td>
<td valign="top" >DVI-I</td> <td valign="top" >DVI-I</td>
<td valign="top" >“coherent”</td> <td valign="top" >“coherent”</td>
<td valign="top" >RANGE</td> <td valign="top" >RANGE</td>
...@@ -3308,14 +3295,6 @@ void intel_crt_init(struct drm_device *dev) ...@@ -3308,14 +3295,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td> <td valign="top" >TBD</td>
</tr> </tr>
<tr> <tr>
<td valign="top" >Generic</td>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >rcar-du</td> <td rowspan="3" valign="top" >rcar-du</td>
<td rowspan="3" valign="top" >Generic</td> <td rowspan="3" valign="top" >Generic</td>
<td valign="top" >"alpha"</td> <td valign="top" >"alpha"</td>
......
...@@ -556,11 +556,11 @@ been converted to this framework. ...@@ -556,11 +556,11 @@ been converted to this framework.
Near-term plans include converting all of them, except for "gadgetfs". Near-term plans include converting all of them, except for "gadgetfs".
</para> </para>
!Edrivers/usb/gadget/f_acm.c !Edrivers/usb/gadget/function/f_acm.c
!Edrivers/usb/gadget/f_ecm.c !Edrivers/usb/gadget/function/f_ecm.c
!Edrivers/usb/gadget/f_subset.c !Edrivers/usb/gadget/function/f_subset.c
!Edrivers/usb/gadget/f_obex.c !Edrivers/usb/gadget/function/f_obex.c
!Edrivers/usb/gadget/f_serial.c !Edrivers/usb/gadget/function/f_serial.c
</sect1> </sect1>
......
...@@ -174,7 +174,7 @@ FILENAME = \ ...@@ -174,7 +174,7 @@ FILENAME = \
DOCUMENTED = \ DOCUMENTED = \
-e "s/\(enum *\)v4l2_mpeg_cx2341x_video_\([a-z]*_spatial_filter_type\)/\1<link linkend=\"\2\">v4l2_mpeg_cx2341x_video_\2<\/link>/g" \ -e "s/\(enum *\)v4l2_mpeg_cx2341x_video_\([a-z]*_spatial_filter_type\)/\1<link linkend=\"\2\">v4l2_mpeg_cx2341x_video_\2<\/link>/g" \
-e "s/\(\(enum\|struct\) *\)\(v4l2_[a-zA-Z0-9_]*\)/\1<link linkend=\"\3\">\3<\/link>/g" \ -e "s/\(\(enum\|struct\) *\)\(v4l2_[a-zA-Z0-9_]*\)/\1<link linkend=\"\3\">\3<\/link>/g" \
-e "s/\(V4L2_PIX_FMT_[A-Z0-9_]\+\) /<link linkend=\"\1\">\1<\/link> /g" \ -e "s/\(V4L2_PIX_FMT_[A-Z0-9_]\+\)\(\s\+v4l2_fourcc\)/<link linkend=\"\1\">\1<\/link>\2/g" \
-e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \ -e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \
-e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g" -e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g"
......
...@@ -555,10 +555,46 @@ typedef enum fe_delivery_system { ...@@ -555,10 +555,46 @@ typedef enum fe_delivery_system {
</section> </section>
<section id="DTV-ISDBT-LAYER-TIME-INTERLEAVING"> <section id="DTV-ISDBT-LAYER-TIME-INTERLEAVING">
<title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title> <title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title>
<para>Possible values: 0, 1, 2, 3, -1 (AUTO)</para> <para>Valid values: 0, 1, 2, 4, -1 (AUTO)</para>
<para>Note: The real inter-leaver depth-names depend on the mode (fft-size); the values <para>when DTV_ISDBT_SOUND_BROADCASTING is active, value 8 is also valid.</para>
here are referring to what can be found in the TMCC-structure - <para>Note: The real time interleaving length depends on the mode (fft-size). The values
independent of the mode.</para> here are referring to what can be found in the TMCC-structure, as shown in the table below.</para>
<informaltable id="isdbt-layer-interleaving-table">
<tgroup cols="4" align="center">
<tbody>
<row>
<entry>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</entry>
<entry>Mode 1 (2K FFT)</entry>
<entry>Mode 2 (4K FFT)</entry>
<entry>Mode 3 (8K FFT)</entry>
</row>
<row>
<entry>0</entry>
<entry>0</entry>
<entry>0</entry>
<entry>0</entry>
</row>
<row>
<entry>1</entry>
<entry>4</entry>
<entry>2</entry>
<entry>1</entry>
</row>
<row>
<entry>2</entry>
<entry>8</entry>
<entry>4</entry>
<entry>2</entry>
</row>
<row>
<entry>4</entry>
<entry>16</entry>
<entry>8</entry>
<entry>4</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</section> </section>
<section id="DTV-ATSCMH-FIC-VER"> <section id="DTV-ATSCMH-FIC-VER">
<title><constant>DTV_ATSCMH_FIC_VER</constant></title> <title><constant>DTV_ATSCMH_FIC_VER</constant></title>
......
...@@ -150,9 +150,15 @@ signal. Drivers shall not convert the sample format by software.</para></entry> ...@@ -150,9 +150,15 @@ signal. Drivers shall not convert the sample format by software.</para></entry>
<entry>This is the scanning system line number <entry>This is the scanning system line number
associated with the first line of the VBI image, of the first and the associated with the first line of the VBI image, of the first and the
second field respectively. See <xref linkend="vbi-525" /> and second field respectively. See <xref linkend="vbi-525" /> and
<xref linkend="vbi-625" /> for valid values. VBI input drivers can <xref linkend="vbi-625" /> for valid values.
return start values 0 if the hardware cannot reliable identify The <constant>V4L2_VBI_ITU_525_F1_START</constant>,
scanning lines, VBI acquisition may not require this <constant>V4L2_VBI_ITU_525_F2_START</constant>,
<constant>V4L2_VBI_ITU_625_F1_START</constant> and
<constant>V4L2_VBI_ITU_625_F2_START</constant> defines give the start line
numbers for each field for each 525 or 625 line format as a convenience.
Don't forget that ITU line numbering starts at 1, not 0.
VBI input drivers can return start values 0 if the hardware cannot
reliable identify scanning lines, VBI acquisition may not require this
information.</entry> information.</entry>
</row> </row>
<row> <row>
......
...@@ -72,9 +72,12 @@ To use the <link linkend="format">format</link> ioctls applications set the ...@@ -72,9 +72,12 @@ To use the <link linkend="format">format</link> ioctls applications set the
<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format; <constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format;
<structfield>sdr</structfield> member of the <structfield>fmt</structfield> <structfield>sdr</structfield> member of the <structfield>fmt</structfield>
union as needed per the desired operation. union as needed per the desired operation.
Currently only the <structfield>pixelformat</structfield> field of Currently there is two fields, <structfield>pixelformat</structfield> and
&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code <structfield>buffersize</structfield>, of struct &v4l2-sdr-format; which are
of the data format. used. Content of the <structfield>pixelformat</structfield> is V4L2 FourCC
code of the data format. The <structfield>buffersize</structfield> field is
maximum buffer size in bytes required for data transfer, set by the driver in
order to inform application.
</para> </para>
<table pgwide="1" frame="none" id="v4l2-sdr-format"> <table pgwide="1" frame="none" id="v4l2-sdr-format">
...@@ -91,9 +94,16 @@ little endian <link linkend="v4l2-fourcc">four character code</link>. ...@@ -91,9 +94,16 @@ little endian <link linkend="v4l2-fourcc">four character code</link>.
V4L2 defines SDR formats in <xref linkend="sdr-formats" />. V4L2 defines SDR formats in <xref linkend="sdr-formats" />.
</entry> </entry>
</row> </row>
<row>
<entry>__u32</entry>
<entry><structfield>buffersize</structfield></entry>
<entry>
Maximum size in bytes required for data. Value is set by the driver.
</entry>
</row>
<row> <row>
<entry>__u8</entry> <entry>__u8</entry>
<entry><structfield>reserved[28]</structfield></entry> <entry><structfield>reserved[24]</structfield></entry>
<entry>This array is reserved for future extensions. <entry>This array is reserved for future extensions.
Drivers and applications must set it to zero.</entry> Drivers and applications must set it to zero.</entry>
</row> </row>
......
...@@ -185,7 +185,14 @@ tables, sigh. --></para></entry> ...@@ -185,7 +185,14 @@ tables, sigh. --></para></entry>
<entry></entry> <entry></entry>
<entry spanname="hspan">Drivers must set <entry spanname="hspan">Drivers must set
<structfield>service_lines</structfield>[0][0] and <structfield>service_lines</structfield>[0][0] and
<structfield>service_lines</structfield>[1][0] to zero.</entry> <structfield>service_lines</structfield>[1][0] to zero.
The <constant>V4L2_VBI_ITU_525_F1_START</constant>,
<constant>V4L2_VBI_ITU_525_F2_START</constant>,
<constant>V4L2_VBI_ITU_625_F1_START</constant> and
<constant>V4L2_VBI_ITU_625_F2_START</constant> defines give the start
line numbers for each field for each 525 or 625 line format as a
convenience. Don't forget that ITU line numbering starts at 1, not 0.
</entry>
</row> </row>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
......
...@@ -870,7 +870,8 @@ should set this to 0.</entry> ...@@ -870,7 +870,8 @@ should set this to 0.</entry>
If the application sets this to 0 for an output stream, then If the application sets this to 0 for an output stream, then
<structfield>bytesused</structfield> will be set to the size of the <structfield>bytesused</structfield> will be set to the size of the
plane (see the <structfield>length</structfield> field of this struct) plane (see the <structfield>length</structfield> field of this struct)
by the driver.</entry> by the driver. Note that the actual image data starts at
<structfield>data_offset</structfield> which may not be 0.</entry>
</row> </row>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
...@@ -919,6 +920,10 @@ should set this to 0.</entry> ...@@ -919,6 +920,10 @@ should set this to 0.</entry>
<entry>Offset in bytes to video data in the plane. <entry>Offset in bytes to video data in the plane.
Drivers must set this field when <structfield>type</structfield> Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream. refers to an input stream, applications when it refers to an output stream.
Note that data_offset is included in <structfield>bytesused</structfield>.
So the size of the image in the plane is
<structfield>bytesused</structfield>-<structfield>data_offset</structfield> at
offset <structfield>data_offset</structfield> from the start of the plane.
</entry> </entry>
</row> </row>
<row> <row>
...@@ -1066,7 +1071,7 @@ state, in the application domain so to say.</entry> ...@@ -1066,7 +1071,7 @@ state, in the application domain so to say.</entry>
<entry>Drivers set or clear this flag when calling the <entry>Drivers set or clear this flag when calling the
<constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video <constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video
capture devices when the buffer contains a compressed image which is a capture devices when the buffer contains a compressed image which is a
key frame (or field), &ie; can be decompressed on its own. Also know as key frame (or field), &ie; can be decompressed on its own. Also known as
an I-frame. Applications can set this bit when <structfield>type</structfield> an I-frame. Applications can set this bit when <structfield>type</structfield>
refers to an output stream.</entry> refers to an output stream.</entry>
</row> </row>
......
...@@ -15,9 +15,6 @@ typical PC graphics frame buffers. They occupy 8, 16, 24 or 32 bits ...@@ -15,9 +15,6 @@ typical PC graphics frame buffers. They occupy 8, 16, 24 or 32 bits
per pixel. These are all packed-pixel formats, meaning all the data per pixel. These are all packed-pixel formats, meaning all the data
for a pixel lie next to each other in memory.</para> for a pixel lie next to each other in memory.</para>
<para>When one of these formats is used, drivers shall report the
colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<table pgwide="1" frame="none" id="rgb-formats"> <table pgwide="1" frame="none" id="rgb-formats">
<title>Packed RGB Image Formats</title> <title>Packed RGB Image Formats</title>
<tgroup cols="37" align="center"> <tgroup cols="37" align="center">
...@@ -130,9 +127,9 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> ...@@ -130,9 +127,9 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>b<subscript>1</subscript></entry> <entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry> <entry>b<subscript>0</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-RGB444"> <row id="V4L2-PIX-FMT-ARGB444">
<entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> <entry><constant>V4L2_PIX_FMT_ARGB444</constant></entry>
<entry>'R444'</entry> <entry>'AR12'</entry>
<entry></entry> <entry></entry>
<entry>g<subscript>3</subscript></entry> <entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry> <entry>g<subscript>2</subscript></entry>
...@@ -152,9 +149,31 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> ...@@ -152,9 +149,31 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>r<subscript>1</subscript></entry> <entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry> <entry>r<subscript>0</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-RGB555"> <row id="V4L2-PIX-FMT-XRGB444">
<entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> <entry><constant>V4L2_PIX_FMT_XRGB444</constant></entry>
<entry>'RGBO'</entry> <entry>'XR12'</entry>
<entry></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-ARGB555">
<entry><constant>V4L2_PIX_FMT_ARGB555</constant></entry>
<entry>'AR15'</entry>
<entry></entry> <entry></entry>
<entry>g<subscript>2</subscript></entry> <entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry> <entry>g<subscript>1</subscript></entry>
...@@ -174,6 +193,28 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> ...@@ -174,6 +193,28 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>g<subscript>4</subscript></entry> <entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry> <entry>g<subscript>3</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-XRGB555">
<entry><constant>V4L2_PIX_FMT_XRGB555</constant></entry>
<entry>'XR15'</entry>
<entry></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>-</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB565"> <row id="V4L2-PIX-FMT-RGB565">
<entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry>
<entry>'RGBP'</entry> <entry>'RGBP'</entry>
...@@ -341,9 +382,9 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> ...@@ -341,9 +382,9 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>b<subscript>1</subscript></entry> <entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry> <entry>b<subscript>0</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-BGR32"> <row id="V4L2-PIX-FMT-ABGR32">
<entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> <entry><constant>V4L2_PIX_FMT_ABGR32</constant></entry>
<entry>'BGR4'</entry> <entry>'AR24'</entry>
<entry></entry> <entry></entry>
<entry>b<subscript>7</subscript></entry> <entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry> <entry>b<subscript>6</subscript></entry>
...@@ -381,9 +422,49 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> ...@@ -381,9 +422,49 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>a<subscript>1</subscript></entry> <entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry> <entry>a<subscript>0</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-RGB32"> <row id="V4L2-PIX-FMT-XBGR32">
<entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> <entry><constant>V4L2_PIX_FMT_XBGR32</constant></entry>
<entry>'RGB4'</entry> <entry>'XR24'</entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
</row>
<row id="V4L2-PIX-FMT-ARGB32">
<entry><constant>V4L2_PIX_FMT_ARGB32</constant></entry>
<entry>'AX24'</entry>
<entry></entry> <entry></entry>
<entry>a<subscript>7</subscript></entry> <entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry> <entry>a<subscript>6</subscript></entry>
...@@ -421,18 +502,76 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> ...@@ -421,18 +502,76 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
<entry>b<subscript>1</subscript></entry> <entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry> <entry>b<subscript>0</subscript></entry>
</row> </row>
<row id="V4L2-PIX-FMT-XRGB32">
<entry><constant>V4L2_PIX_FMT_XRGB32</constant></entry>
<entry>'BX24'</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
<para>Bit 7 is the most significant bit. The value of the a = alpha <para>Bit 7 is the most significant bit.</para>
bits is undefined when reading from the driver, ignored when writing
to the driver, except when alpha blending has been negotiated for a <para>The usage and value of the alpha bits (a) in the ARGB and ABGR formats
<link linkend="overlay">Video Overlay</link> or <link linkend="osd"> (collectively referred to as alpha formats) depend on the device type and
Video Output Overlay</link> or when the alpha component has been configured hardware operation. <link linkend="capture">Capture</link> devices
for a <link linkend="capture">Video Capture</link> by means of <link (including capture queues of mem-to-mem devices) fill the alpha component in
linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT memory. When the device outputs an alpha channel the alpha component will
</constant> </link> control.</para> have a meaningful value. Otherwise, when the device doesn't output an alpha
channel but can set the alpha bit to a user-configurable value, the <link
linkend="v4l2-alpha-component"><constant>V4L2_CID_ALPHA_COMPONENT</constant>
</link> control is used to specify that alpha value, and the alpha component
of all pixels will be set to the value specified by that control. Otherwise
a corresponding format without an alpha component (XRGB or XBGR) must be
used instead of an alpha format.</para>
<para><link linkend="output">Output</link> devices (including output queues
of mem-to-mem devices and <link linkend="osd">video output overlay</link>
devices) read the alpha component from memory. When the device processes the
alpha channel the alpha component must be filled with meaningful values by
applications. Otherwise a corresponding format without an alpha component
(XRGB or XBGR) must be used instead of an alpha format.</para>
<para>The XRGB and XBGR formats contain undefined bits (-). Applications,
devices and drivers must ignore those bits, for both <link
linkend="capture">capture</link> and <link linkend="output">output</link>
devices.</para>
<example> <example>
<title><constant>V4L2_PIX_FMT_BGR24</constant> 4 &times; 4 pixel <title><constant>V4L2_PIX_FMT_BGR24</constant> 4 &times; 4 pixel
...@@ -512,6 +651,239 @@ image</title> ...@@ -512,6 +651,239 @@ image</title>
</formalpara> </formalpara>
</example> </example>
<para>Formats defined in <xref linkend="rgb-formats-deprecated"/> are
deprecated and must not be used by new drivers. They are documented here for
reference. The meaning of their alpha bits (a) is ill-defined and
interpreted as in either the corresponding ARGB or XRGB format, depending on
the driver.</para>
<table pgwide="1" frame="none" id="rgb-formats-deprecated">
<title>Deprecated Packed RGB Image Formats</title>
<tgroup cols="37" align="center">
<colspec colname="id" align="left" />
<colspec colname="fourcc" />
<colspec colname="bit" />
<colspec colnum="4" colname="b07" align="center" />
<colspec colnum="5" colname="b06" align="center" />
<colspec colnum="6" colname="b05" align="center" />
<colspec colnum="7" colname="b04" align="center" />
<colspec colnum="8" colname="b03" align="center" />
<colspec colnum="9" colname="b02" align="center" />
<colspec colnum="10" colname="b01" align="center" />
<colspec colnum="11" colname="b00" align="center" />
<colspec colnum="13" colname="b17" align="center" />
<colspec colnum="14" colname="b16" align="center" />
<colspec colnum="15" colname="b15" align="center" />
<colspec colnum="16" colname="b14" align="center" />
<colspec colnum="17" colname="b13" align="center" />
<colspec colnum="18" colname="b12" align="center" />
<colspec colnum="19" colname="b11" align="center" />
<colspec colnum="20" colname="b10" align="center" />
<colspec colnum="22" colname="b27" align="center" />
<colspec colnum="23" colname="b26" align="center" />
<colspec colnum="24" colname="b25" align="center" />
<colspec colnum="25" colname="b24" align="center" />
<colspec colnum="26" colname="b23" align="center" />
<colspec colnum="27" colname="b22" align="center" />
<colspec colnum="28" colname="b21" align="center" />
<colspec colnum="29" colname="b20" align="center" />
<colspec colnum="31" colname="b37" align="center" />
<colspec colnum="32" colname="b36" align="center" />
<colspec colnum="33" colname="b35" align="center" />
<colspec colnum="34" colname="b34" align="center" />
<colspec colnum="35" colname="b33" align="center" />
<colspec colnum="36" colname="b32" align="center" />
<colspec colnum="37" colname="b31" align="center" />
<colspec colnum="38" colname="b30" align="center" />
<spanspec namest="b07" nameend="b00" spanname="b0" />
<spanspec namest="b17" nameend="b10" spanname="b1" />
<spanspec namest="b27" nameend="b20" spanname="b2" />
<spanspec namest="b37" nameend="b30" spanname="b3" />
<thead>
<row>
<entry>Identifier</entry>
<entry>Code</entry>
<entry>&nbsp;</entry>
<entry spanname="b0">Byte&nbsp;0 in memory</entry>
<entry spanname="b1">Byte&nbsp;1</entry>
<entry spanname="b2">Byte&nbsp;2</entry>
<entry spanname="b3">Byte&nbsp;3</entry>
</row>
<row>
<entry>&nbsp;</entry>
<entry>&nbsp;</entry>
<entry>Bit</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
<entry>&nbsp;</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
<entry>&nbsp;</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
<entry>&nbsp;</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
<entry>4</entry>
<entry>3</entry>
<entry>2</entry>
<entry>1</entry>
<entry>0</entry>
</row>
</thead>
<tbody>
<row id="V4L2-PIX-FMT-RGB444">
<entry><constant>V4L2_PIX_FMT_RGB444</constant></entry>
<entry>'R444'</entry>
<entry></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB555">
<entry><constant>V4L2_PIX_FMT_RGB555</constant></entry>
<entry>'RGBO'</entry>
<entry></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>a</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-BGR32">
<entry><constant>V4L2_PIX_FMT_BGR32</constant></entry>
<entry>'BGR4'</entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
<entry></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-RGB32">
<entry><constant>V4L2_PIX_FMT_RGB32</constant></entry>
<entry>'RGB4'</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
<entry>a<subscript>6</subscript></entry>
<entry>a<subscript>5</subscript></entry>
<entry>a<subscript>4</subscript></entry>
<entry>a<subscript>3</subscript></entry>
<entry>a<subscript>2</subscript></entry>
<entry>a<subscript>1</subscript></entry>
<entry>a<subscript>0</subscript></entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
</tbody>
</tgroup>
</table>
<para>A test utility to determine which RGB formats a driver <para>A test utility to determine which RGB formats a driver
actually supports is available from the LinuxTV v4l-dvb repository. actually supports is available from the LinuxTV v4l-dvb repository.
See &v4l-dvb; for access instructions.</para> See &v4l-dvb; for access instructions.</para>
......
<refentry id="V4L2-SDR-FMT-CS08">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_CS8 ('CS08')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_CS8</constant>
</refname>
<refpurpose>Complex signed 8-bit IQ sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of complex number samples. Each complex number
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
represented as a 8 bit signed number. I value comes first and Q value after
that.
</para>
<example>
<title><constant>V4L2_SDR_FMT_CS8</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="2" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;1:</entry>
<entry>Q'<subscript>0</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<refentry id="V4L2-SDR-FMT-CS14LE">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_CS14LE ('CS14')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_CS14LE</constant>
</refname>
<refpurpose>Complex signed 14-bit little endian IQ sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of complex number samples. Each complex number
consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
represented as a 14 bit signed little endian number. I value comes first
and Q value after that. 14 bit value is stored in 16 bit space with unused
high bits padded with 0.
</para>
<example>
<title><constant>V4L2_SDR_FMT_CS14LE</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0[7:0]</subscript></entry>
<entry>I'<subscript>0[13:8]</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;2:</entry>
<entry>Q'<subscript>0[7:0]</subscript></entry>
<entry>Q'<subscript>0[13:8]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<refentry id="V4L2-SDR-FMT-RU12LE">
<refmeta>
<refentrytitle>V4L2_SDR_FMT_RU12LE ('RU12')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>
<constant>V4L2_SDR_FMT_RU12LE</constant>
</refname>
<refpurpose>Real unsigned 12-bit little endian sample</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>
This format contains sequence of real number samples. Each sample is
represented as a 12 bit unsigned little endian number. Sample is stored
in 16 bit space with unused high bits padded with 0.
</para>
<example>
<title><constant>V4L2_SDR_FMT_RU12LE</constant> 1 sample</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>I'<subscript>0[7:0]</subscript></entry>
<entry>I'<subscript>0[11:8]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
...@@ -18,7 +18,7 @@ ...@@ -18,7 +18,7 @@
<title>Description</title> <title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats with <para>The following four pixel formats are raw sRGB / Bayer formats with
12 bits per colour. Each colour component is stored in a 16-bit word, with 6 12 bits per colour. Each colour component is stored in a 16-bit word, with 4
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
and n/2 blue or red samples, with alternating red and blue rows. Bytes are and n/2 blue or red samples, with alternating red and blue rows. Bytes are
stored in memory in little endian order. They are conventionally described stored in memory in little endian order. They are conventionally described
......
...@@ -112,9 +112,34 @@ see <xref linkend="colorspaces" />.</entry> ...@@ -112,9 +112,34 @@ see <xref linkend="colorspaces" />.</entry>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
<entry><structfield>priv</structfield></entry> <entry><structfield>priv</structfield></entry>
<entry>Reserved for custom (driver defined) additional <entry><para>This field indicates whether the remaining fields of the
information about formats. When not used drivers and applications must <structname>v4l2_pix_format</structname> structure, also called the extended
set this field to zero.</entry> fields, are valid. When set to <constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, it
indicates that the extended fields have been correctly initialized. When set to
any other value it indicates that the extended fields contain undefined values.
</para>
<para>Applications that wish to use the pixel format extended fields must first
ensure that the feature is supported by querying the device for the
<link linkend="querycap"><constant>V4L2_CAP_EXT_PIX_FORMAT</constant></link>
capability. If the capability isn't set the pixel format extended fields are not
supported and using the extended fields will lead to undefined results.</para>
<para>To use the extended fields, applications must set the
<structfield>priv</structfield> field to
<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, initialize all the extended fields
and zero the unused bytes of the <structname>v4l2_format</structname>
<structfield>raw_data</structfield> field.</para>
<para>When the <structfield>priv</structfield> field isn't set to
<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant> drivers must act as if all the
extended fields were set to zero. On return drivers must set the
<structfield>priv</structfield> field to
<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant> and all the extended fields to
applicable values.</para></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags set by the application or driver, see <xref
linkend="format-flags" />.</entry>
</row> </row>
</tbody> </tbody>
</tgroup> </tgroup>
...@@ -201,9 +226,15 @@ codes can be used.</entry> ...@@ -201,9 +226,15 @@ codes can be used.</entry>
and the number of valid entries in the and the number of valid entries in the
<structfield>plane_fmt</structfield> array.</entry> <structfield>plane_fmt</structfield> array.</entry>
</row> </row>
<row>
<entry>__u8</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags set by the application or driver, see <xref
linkend="format-flags" />.</entry>
</row>
<row> <row>
<entry>__u8</entry> <entry>__u8</entry>
<entry><structfield>reserved[11]</structfield></entry> <entry><structfield>reserved[10]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the <entry>Reserved for future extensions. Should be zeroed by the
application.</entry> application.</entry>
</row> </row>
...@@ -248,7 +279,7 @@ has just as many pad bytes after it as the other rows.</para> ...@@ -248,7 +279,7 @@ has just as many pad bytes after it as the other rows.</para>
<para>In V4L2 each format has an identifier which looks like <para>In V4L2 each format has an identifier which looks like
<constant>PIX_FMT_XXX</constant>, defined in the <link <constant>PIX_FMT_XXX</constant>, defined in the <link
linkend="videodev">videodev.h</link> header file. These identifiers linkend="videodev">videodev2.h</link> header file. These identifiers
represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link> represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link>
which are also listed below, however they are not the same as those which are also listed below, however they are not the same as those
used in the Windows world.</para> used in the Windows world.</para>
...@@ -828,6 +859,9 @@ interface only.</para> ...@@ -828,6 +859,9 @@ interface only.</para>
&sub-sdr-cu08; &sub-sdr-cu08;
&sub-sdr-cu16le; &sub-sdr-cu16le;
&sub-sdr-cs08;
&sub-sdr-cs14le;
&sub-sdr-ru12le;
</section> </section>
...@@ -1060,4 +1094,21 @@ concatenated to form the JPEG stream. </para> ...@@ -1060,4 +1094,21 @@ concatenated to form the JPEG stream. </para>
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
<table frame="none" pgwide="1" id="format-flags">
<title>Format Flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_PIX_FMT_FLAG_PREMUL_ALPHA</constant></entry>
<entry>0x00000001</entry>
<entry>The color values are premultiplied by the alpha channel
value. For example, if a light blue pixel with 50% transparency was described by
RGBA values (128, 192, 255, 128), the same pixel described with premultiplied
colors would be described by RGBA values (64, 96, 128, 128) </entry>
</row>
</tbody>
</tgroup>
</table>
</section> </section>
...@@ -86,47 +86,47 @@ selection targets available for a video capture device. It is recommended to ...@@ -86,47 +86,47 @@ selection targets available for a video capture device. It is recommended to
configure the cropping targets before to the composing targets.</para> configure the cropping targets before to the composing targets.</para>
<para>The range of coordinates of the top left corner, width and height of <para>The range of coordinates of the top left corner, width and height of
areas that can be sampled is given by the <constant> V4L2_SEL_TGT_CROP_BOUNDS areas that can be sampled is given by the <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>
</constant> target. It is recommended for the driver developers to put the target. It is recommended for the driver developers to put the
top/left corner at position <constant> (0,0) </constant>. The rectangle's top/left corner at position <constant>(0,0)</constant>. The rectangle's
coordinates are expressed in pixels.</para> coordinates are expressed in pixels.</para>
<para>The top left corner, width and height of the source rectangle, that is <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 the area actually sampled, is given by the <constant>V4L2_SEL_TGT_CROP</constant>
</constant> target. It uses the same coordinate system as <constant> target. It uses the same coordinate system as <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>.
V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie The active cropping area must lie completely inside the capture boundaries. The
completely inside the capture boundaries. The driver may further adjust the driver may further adjust the requested size and/or position according to hardware
requested size and/or position according to hardware limitations.</para> limitations.</para>
<para>Each capture device has a default source rectangle, given by the <para>Each capture device has a default source rectangle, given by the
<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant> target. This rectangle shall <constant>V4L2_SEL_TGT_CROP_DEFAULT</constant> target. This rectangle shall
over what the driver writer considers the complete picture. Drivers shall set over what the driver writer considers the complete picture. Drivers shall set
the active crop rectangle to the default when the driver is first loaded, but the active crop rectangle to the default when the driver is first loaded, but
not later.</para> not later.</para>
<para>The composing targets refer to a memory buffer. The limits of composing <para>The composing targets refer to a memory buffer. The limits of composing
coordinates are obtained using <constant> V4L2_SEL_TGT_COMPOSE_BOUNDS coordinates are obtained using <constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant>.
</constant>. All coordinates are expressed in pixels. The rectangle's top/left All coordinates are expressed in pixels. The rectangle's top/left
corner must be located at position <constant> (0,0) </constant>. The width and corner must be located at position <constant>(0,0)</constant>. The width and
height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>. height are equal to the image size set by <constant>VIDIOC_S_FMT</constant>.
</para> </para>
<para>The part of a buffer into which the image is inserted by the hardware is <para>The part of a buffer into which the image is inserted by the hardware is
controlled by the <constant> V4L2_SEL_TGT_COMPOSE </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 rectangle's coordinates are also expressed in the same coordinate system as
the bounds rectangle. The composing rectangle must lie completely inside bounds the bounds rectangle. The composing rectangle must lie completely inside bounds
rectangle. The driver must adjust the composing rectangle to fit to the rectangle. The driver must adjust the composing rectangle to fit to the
bounding limits. Moreover, the driver can perform other adjustments according bounding limits. Moreover, the driver can perform other adjustments according
to hardware limitations. The application can control rounding behaviour using to hardware limitations. The application can control rounding behaviour using
<link linkend="v4l2-selection-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 <para>For capture devices the default composing rectangle is queried using
<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the <constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant>. It is usually equal to the
bounding rectangle.</para> bounding rectangle.</para>
<para>The part of a buffer that is modified by the hardware is given by <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 <constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant>. It contains all pixels
defined using <constant> V4L2_SEL_TGT_COMPOSE </constant> plus all defined using <constant>V4L2_SEL_TGT_COMPOSE</constant> plus all
padding data modified by hardware during insertion process. All pixels outside padding data modified by hardware during insertion process. All pixels outside
this rectangle <emphasis>must not</emphasis> be changed by the hardware. The 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 content of pixels that lie inside the padded area but outside active area is
...@@ -140,52 +140,51 @@ where the rubbish pixels are located and remove them if needed.</para> ...@@ -140,52 +140,51 @@ where the rubbish pixels are located and remove them if needed.</para>
<title>Configuration of video output</title> <title>Configuration of video output</title>
<para>For output devices targets and ioctls are used similarly to the video <para>For output devices targets and ioctls are used similarly to the video
capture case. The <emphasis> composing </emphasis> rectangle refers to the capture case. The <emphasis>composing</emphasis> rectangle refers to the
insertion of an image into a video signal. The cropping rectangles refer to a insertion of an image into a video signal. The cropping rectangles refer to a
memory buffer. It is recommended to configure the composing targets before to memory buffer. It is recommended to configure the composing targets before to
the cropping targets.</para> the cropping targets.</para>
<para>The cropping targets refer to the memory buffer that contains an image to <para>The cropping targets refer to the memory buffer that contains an image to
be inserted into a video signal or graphical screen. The limits of cropping be inserted into a video signal or graphical screen. The limits of cropping
coordinates are obtained using <constant> V4L2_SEL_TGT_CROP_BOUNDS </constant>. coordinates are obtained using <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>.
All coordinates are expressed in pixels. The top/left corner is always point All coordinates are expressed in pixels. The top/left corner is always point
<constant> (0,0) </constant>. The width and height is equal to the image size <constant>(0,0)</constant>. The width and height is equal to the image size
specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para> specified using <constant>VIDIOC_S_FMT</constant> ioctl.</para>
<para>The top left corner, width and height of the source rectangle, that is <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 the area from which image date are processed by the hardware, is given by the
<constant> V4L2_SEL_TGT_CROP </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 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 area must lie completely inside the crop boundaries and the driver may further
adjust the requested size and/or position according to hardware adjust the requested size and/or position according to hardware
limitations.</para> limitations.</para>
<para>For output devices the default cropping rectangle is queried using <para>For output devices the default cropping rectangle is queried using
<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant>. It is usually equal to the <constant>V4L2_SEL_TGT_CROP_DEFAULT</constant>. It is usually equal to the
bounding rectangle.</para> bounding rectangle.</para>
<para>The part of a video signal or graphics display where the image is <para>The part of a video signal or graphics display where the image is
inserted by the hardware is controlled by <constant> inserted by the hardware is controlled by <constant>V4L2_SEL_TGT_COMPOSE</constant>
V4L2_SEL_TGT_COMPOSE </constant> target. The rectangle's coordinates target. The rectangle's coordinates are expressed in pixels. The composing
are expressed in pixels. The composing rectangle must lie completely inside the rectangle must lie completely inside the bounds rectangle. The driver must
bounds rectangle. The driver must adjust the area to fit to the bounding adjust the area to fit to the bounding limits. Moreover, the driver can
limits. Moreover, the driver can perform other adjustments according to perform other adjustments according to hardware limitations.</para>
hardware limitations. </para>
<para>The device has a default composing rectangle, given by the
<para>The device has a default composing rectangle, given by the <constant> <constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant> target. This rectangle shall cover what
V4L2_SEL_TGT_COMPOSE_DEFAULT </constant> target. This rectangle shall cover what
the driver writer considers the complete picture. It is recommended for the the driver writer considers the complete picture. It is recommended for the
driver developers to put the top/left corner at position <constant> (0,0) driver developers to put the top/left corner at position <constant>(0,0)</constant>.
</constant>. Drivers shall set the active composing rectangle to the default Drivers shall set the active composing rectangle to the default
one when the driver is first loaded.</para> one when the driver is first loaded.</para>
<para>The devices may introduce additional content to video signal other than <para>The devices may introduce additional content to video signal other than
an image from memory buffers. It includes borders around an image. However, an image from memory buffers. It includes borders around an image. However,
such a padded area is driver-dependent feature not covered by this document. 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. 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 The padded target is accessed by the <constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant>
</constant> identifier. It must contain all pixels from the <constant> identifier. It must contain all pixels from the <constant>V4L2_SEL_TGT_COMPOSE</constant>
V4L2_SEL_TGT_COMPOSE </constant> target.</para> target.</para>
</section> </section>
...@@ -194,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE </constant> target.</para> ...@@ -194,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE </constant> target.</para>
<title>Scaling control</title> <title>Scaling control</title>
<para>An application can detect if scaling is performed by comparing the width <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 and the height of rectangles obtained using <constant>V4L2_SEL_TGT_CROP</constant>
</constant> and <constant> V4L2_SEL_TGT_COMPOSE </constant> targets. If and <constant>V4L2_SEL_TGT_COMPOSE</constant> targets. If
these are not equal then the scaling is applied. The application can compute these are not equal then the scaling is applied. The application can compute
the scaling ratios using these values.</para> the scaling ratios using these values.</para>
...@@ -208,7 +207,7 @@ the scaling ratios using these values.</para> ...@@ -208,7 +207,7 @@ the scaling ratios using these values.</para>
<title>Comparison with old cropping API</title> <title>Comparison with old cropping API</title>
<para>The selection API was introduced to cope with deficiencies of previous <para>The selection API was introduced to cope with deficiencies of previous
<link linkend="crop"> API </link>, that was designed to control simple capture <link linkend="crop"> API</link>, that was designed to control simple capture
devices. Later the cropping API was adopted by video output drivers. The ioctls devices. Later the cropping API was adopted by video output drivers. The ioctls
are used to select a part of the display were the video signal is inserted. It are used to select a part of the display were the video signal is inserted. It
should be considered as an API abuse because the described operation is should be considered as an API abuse because the described operation is
...@@ -220,7 +219,7 @@ part of an image by abusing V4L2 API. Cropping a smaller image from a larger ...@@ -220,7 +219,7 @@ part of an image by abusing V4L2 API. Cropping a smaller image from a larger
one is achieved by setting the field one is achieved by setting the field
&v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets &v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets
could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield> could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield>
before calling <constant> VIDIOC_QBUF </constant>. Those before calling <constant>VIDIOC_QBUF</constant>. Those
operations should be avoided because they are not portable (endianness), and do operations should be avoided because they are not portable (endianness), and do
not work for macroblock and Bayer formats and mmap buffers. The selection API not work for macroblock and Bayer formats and mmap buffers. The selection API
deals with configuration of buffer cropping/composing in a clear, intuitive and deals with configuration of buffer cropping/composing in a clear, intuitive and
...@@ -229,7 +228,7 @@ and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap; ...@@ -229,7 +228,7 @@ and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap;
have no reserved fields. Therefore there is no way to extend their functionality. have no reserved fields. Therefore there is no way to extend their functionality.
The new &v4l2-selection; provides a lot of place for future The new &v4l2-selection; provides a lot of place for future
extensions. Driver developers are encouraged to implement only selection API. extensions. Driver developers are encouraged to implement only selection API.
The former cropping API would be simulated using the new one. </para> The former cropping API would be simulated using the new one.</para>
</section> </section>
...@@ -238,9 +237,9 @@ The former cropping API would be simulated using the new one. </para> ...@@ -238,9 +237,9 @@ The former cropping API would be simulated using the new one. </para>
<example> <example>
<title>Resetting the cropping parameters</title> <title>Resetting the cropping parameters</title>
<para>(A video capture device is assumed; change <constant> <para>(A video capture device is assumed; change
V4L2_BUF_TYPE_VIDEO_CAPTURE </constant> for other devices; change target to <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> for other devices; change target to
<constant> V4L2_SEL_TGT_COMPOSE_* </constant> family to configure composing <constant>V4L2_SEL_TGT_COMPOSE_*</constant> family to configure composing
area)</para> area)</para>
<programlisting> <programlisting>
...@@ -292,8 +291,8 @@ area)</para> ...@@ -292,8 +291,8 @@ area)</para>
<example> <example>
<title>Querying for scaling factors</title> <title>Querying for scaling factors</title>
<para>A video output device is assumed; change <constant> <para>A video output device is assumed; change
V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para> <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> for other devices</para>
<programlisting> <programlisting>
&v4l2-selection; compose = { &v4l2-selection; compose = {
......
...@@ -151,6 +151,14 @@ structs, ioctls) must be noted in more detail in the history chapter ...@@ -151,6 +151,14 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and (compat.xml), along with the possible impact on existing drivers and
applications. --> applications. -->
<revision>
<revnumber>3.16</revnumber>
<date>2014-05-27</date>
<authorinitials>lp</authorinitials>
<revremark>Extended &v4l2-pix-format;. Added format flags.
</revremark>
</revision>
<revision> <revision>
<revnumber>3.15</revnumber> <revnumber>3.15</revnumber>
<date>2014-02-03</date> <date>2014-02-03</date>
......
...@@ -92,6 +92,18 @@ ...@@ -92,6 +92,18 @@
<entry><structfield>frame_sync</structfield></entry> <entry><structfield>frame_sync</structfield></entry>
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry> <entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
</row> </row>
<row>
<entry></entry>
<entry>&v4l2-event-motion-det;</entry>
<entry><structfield>motion_det</structfield></entry>
<entry>Event data for event V4L2_EVENT_MOTION_DET.</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-event-src-change;</entry>
<entry><structfield>src_change</structfield></entry>
<entry>Event data for event V4L2_EVENT_SOURCE_CHANGE.</entry>
</row>
<row> <row>
<entry></entry> <entry></entry>
<entry>__u8</entry> <entry>__u8</entry>
...@@ -258,6 +270,44 @@ ...@@ -258,6 +270,44 @@
</tgroup> </tgroup>
</table> </table>
<table frame="none" pgwide="1" id="v4l2-event-motion-det">
<title>struct <structname>v4l2_event_motion_det</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>
Currently only one flag is available: if <constant>V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ</constant>
is set, then the <structfield>frame_sequence</structfield> field is valid,
otherwise that field should be ignored.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>frame_sequence</structfield></entry>
<entry>
The sequence number of the frame being received. Only valid if the
<constant>V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ</constant> flag was set.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>region_mask</structfield></entry>
<entry>
The bitmask of the regions that reported motion. There is at least one
region. If this field is 0, then no motion was detected at all.
If there is no <constant>V4L2_CID_DETECT_MD_REGION_GRID</constant> control
(see <xref linkend="detect-controls" />) to assign a different region
to each cell in the motion detection grid, then that all cells
are automatically assigned to the default region 0.
</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="changes-flags"> <table pgwide="1" frame="none" id="changes-flags">
<title>Changes</title> <title>Changes</title>
<tgroup cols="3"> <tgroup cols="3">
......
...@@ -72,23 +72,30 @@ initialize the <structfield>id</structfield>, ...@@ -72,23 +72,30 @@ initialize the <structfield>id</structfield>,
<structfield>size</structfield> and <structfield>reserved2</structfield> fields <structfield>size</structfield> and <structfield>reserved2</structfield> fields
of each &v4l2-ext-control; and call the of each &v4l2-ext-control; and call the
<constant>VIDIOC_G_EXT_CTRLS</constant> ioctl. String controls controls <constant>VIDIOC_G_EXT_CTRLS</constant> ioctl. String controls controls
must also set the <structfield>string</structfield> field.</para> must also set the <structfield>string</structfield> field. Controls
of compound types (<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set)
must set the <structfield>ptr</structfield> field.</para>
<para>If the <structfield>size</structfield> is too small to <para>If the <structfield>size</structfield> is too small to
receive the control result (only relevant for pointer-type controls receive the control result (only relevant for pointer-type controls
like strings), then the driver will set <structfield>size</structfield> like strings), then the driver will set <structfield>size</structfield>
to a valid value and return an &ENOSPC;. You should re-allocate the to a valid value and return an &ENOSPC;. You should re-allocate the
string memory to this new size and try again. It is possible that the memory to this new size and try again. For the string type it is possible that
same issue occurs again if the string has grown in the meantime. It is the same issue occurs again if the string has grown in the meantime. It is
recommended to call &VIDIOC-QUERYCTRL; first and use recommended to call &VIDIOC-QUERYCTRL; first and use
<structfield>maximum</structfield>+1 as the new <structfield>size</structfield> <structfield>maximum</structfield>+1 as the new <structfield>size</structfield>
value. It is guaranteed that that is sufficient memory. value. It is guaranteed that that is sufficient memory.
</para> </para>
<para>N-dimensional arrays are set and retrieved row-by-row. You cannot set a partial
array, all elements have to be set or retrieved. The total size is calculated
as <structfield>elems</structfield> * <structfield>elem_size</structfield>.
These values can be obtained by calling &VIDIOC-QUERY-EXT-CTRL;.</para>
<para>To change the value of a set of controls applications <para>To change the value of a set of controls applications
initialize the <structfield>id</structfield>, <structfield>size</structfield>, initialize the <structfield>id</structfield>, <structfield>size</structfield>,
<structfield>reserved2</structfield> and <structfield>reserved2</structfield> and
<structfield>value/string</structfield> fields of each &v4l2-ext-control; and <structfield>value/value64/string/ptr</structfield> fields of each &v4l2-ext-control; and
call the <constant>VIDIOC_S_EXT_CTRLS</constant> ioctl. The controls call the <constant>VIDIOC_S_EXT_CTRLS</constant> ioctl. The controls
will only be set if <emphasis>all</emphasis> control values are will only be set if <emphasis>all</emphasis> control values are
valid.</para> valid.</para>
...@@ -96,7 +103,7 @@ valid.</para> ...@@ -96,7 +103,7 @@ valid.</para>
<para>To check if a set of controls have correct values applications <para>To check if a set of controls have correct values applications
initialize the <structfield>id</structfield>, <structfield>size</structfield>, initialize the <structfield>id</structfield>, <structfield>size</structfield>,
<structfield>reserved2</structfield> and <structfield>reserved2</structfield> and
<structfield>value/string</structfield> fields of each &v4l2-ext-control; and <structfield>value/value64/string/ptr</structfield> fields of each &v4l2-ext-control; and
call the <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctl. It is up to call the <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctl. It is up to
the driver whether wrong values are automatically adjusted to a valid the driver whether wrong values are automatically adjusted to a valid
value or if an error is returned.</para> value or if an error is returned.</para>
...@@ -158,19 +165,47 @@ applications must set the array to zero.</entry> ...@@ -158,19 +165,47 @@ applications must set the array to zero.</entry>
<entry></entry> <entry></entry>
<entry>__s32</entry> <entry>__s32</entry>
<entry><structfield>value</structfield></entry> <entry><structfield>value</structfield></entry>
<entry>New value or current value.</entry> <entry>New value or current value. Valid if this control is not of
type <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and
<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is not set.</entry>
</row> </row>
<row> <row>
<entry></entry> <entry></entry>
<entry>__s64</entry> <entry>__s64</entry>
<entry><structfield>value64</structfield></entry> <entry><structfield>value64</structfield></entry>
<entry>New value or current value.</entry> <entry>New value or current value. Valid if this control is of
type <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and
<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is not set.</entry>
</row> </row>
<row> <row>
<entry></entry> <entry></entry>
<entry>char *</entry> <entry>char *</entry>
<entry><structfield>string</structfield></entry> <entry><structfield>string</structfield></entry>
<entry>A pointer to a string.</entry> <entry>A pointer to a string. Valid if this control is of
type <constant>V4L2_CTRL_TYPE_STRING</constant>.</entry>
</row>
<row>
<entry></entry>
<entry>__u8 *</entry>
<entry><structfield>p_u8</structfield></entry>
<entry>A pointer to a matrix control of unsigned 8-bit values.
Valid if this control is of type <constant>V4L2_CTRL_TYPE_U8</constant>.</entry>
</row>
<row>
<entry></entry>
<entry>__u16 *</entry>
<entry><structfield>p_u16</structfield></entry>
<entry>A pointer to a matrix control of unsigned 16-bit values.
Valid if this control is of type <constant>V4L2_CTRL_TYPE_U16</constant>.</entry>
</row>
<row>
<entry></entry>
<entry>void *</entry>
<entry><structfield>ptr</structfield></entry>
<entry>A pointer to a compound type which can be an N-dimensional array and/or a
compound type (the control's type is >= <constant>V4L2_CTRL_COMPOUND_TYPES</constant>).
Valid if <constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set for this control.
</entry>
</row> </row>
</tbody> </tbody>
</tgroup> </tgroup>
......
...@@ -152,13 +152,10 @@ a valid base address, so applications can find the corresponding Linux ...@@ -152,13 +152,10 @@ a valid base address, so applications can find the corresponding Linux
framebuffer device (see <xref linkend="osd" />).</entry> framebuffer device (see <xref linkend="osd" />).</entry>
</row> </row>
<row> <row>
<entry>&v4l2-pix-format;</entry> <entry>struct</entry>
<entry><structfield>fmt</structfield></entry> <entry><structfield>fmt</structfield></entry>
<entry></entry> <entry></entry>
<entry>Layout of the frame buffer. The <entry>Layout of the frame buffer.</entry>
<structname>v4l2_pix_format</structname> structure is defined in <xref
linkend="pixfmt" />, for clarification the fields and acceptable values
are listed below:</entry>
</row> </row>
<row> <row>
<entry></entry> <entry></entry>
...@@ -276,9 +273,8 @@ see <xref linkend="colorspaces" />.</entry> ...@@ -276,9 +273,8 @@ see <xref linkend="colorspaces" />.</entry>
<entry></entry> <entry></entry>
<entry>__u32</entry> <entry>__u32</entry>
<entry><structfield>priv</structfield></entry> <entry><structfield>priv</structfield></entry>
<entry>Reserved for additional information about custom <entry>Reserved. Drivers and applications must set this field to
(driver defined) formats. When not used drivers and applications must zero.</entry>
set this field to zero.</entry>
</row> </row>
</tbody> </tbody>
</tgroup> </tgroup>
......
...@@ -58,17 +58,16 @@ ...@@ -58,17 +58,16 @@
<para>The ioctls are used to query and configure selection rectangles.</para> <para>The ioctls are used to query and configure selection rectangles.</para>
<para> To query the cropping (composing) rectangle set &v4l2-selection; <para>To query the cropping (composing) rectangle set &v4l2-selection;
<structfield> type </structfield> field to the respective buffer type. <structfield> type </structfield> field to the respective buffer type.
Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE Do not use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is
setting the value of &v4l2-selection; <structfield>target</structfield> field setting the value of &v4l2-selection; <structfield>target</structfield> field
to <constant> V4L2_SEL_TGT_CROP </constant> (<constant> to <constant>V4L2_SEL_TGT_CROP</constant> (<constant>V4L2_SEL_TGT_COMPOSE</constant>).
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref Please refer to table <xref linkend="v4l2-selections-common" /> or <xref linkend="selection-api" />
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional for additional targets. The <structfield>flags</structfield> and <structfield>reserved
targets. The <structfield>flags</structfield> and <structfield>reserved
</structfield> fields of &v4l2-selection; are ignored and they must be filled </structfield> fields of &v4l2-selection; are ignored and they must be filled
with zeros. The driver fills the rest of the structure or with zeros. The driver fills the rest of the structure or
returns &EINVAL; if incorrect buffer type or target was used. If cropping returns &EINVAL; if incorrect buffer type or target was used. If cropping
...@@ -77,19 +76,18 @@ always equal to the bounds rectangle. Finally, the &v4l2-rect; ...@@ -77,19 +76,18 @@ always equal to the bounds rectangle. Finally, the &v4l2-rect;
<structfield>r</structfield> rectangle is filled with the current cropping <structfield>r</structfield> rectangle is filled with the current cropping
(composing) coordinates. The coordinates are expressed in driver-dependent (composing) coordinates. The coordinates are expressed in driver-dependent
units. The only exception are rectangles for images in raw formats, whose units. The only exception are rectangles for images in raw formats, whose
coordinates are always expressed in pixels. </para> coordinates are always expressed in pixels.</para>
<para> To change the cropping (composing) rectangle set the &v4l2-selection; <para>To change the cropping (composing) rectangle set the &v4l2-selection;
<structfield>type</structfield> field to the respective buffer type. Do not <structfield>type</structfield> field to the respective buffer type. Do not
use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is
setting the value of &v4l2-selection; <structfield>target</structfield> to setting the value of &v4l2-selection; <structfield>target</structfield> to
<constant>V4L2_SEL_TGT_CROP</constant> (<constant> <constant>V4L2_SEL_TGT_CROP</constant> (<constant>V4L2_SEL_TGT_COMPOSE</constant>).
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref Please refer to table <xref linkend="v4l2-selections-common" /> or <xref linkend="selection-api" />
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional for additional targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
set to the desired active area. Field &v4l2-selection; <structfield> reserved set to the desired active area. Field &v4l2-selection; <structfield> reserved
</structfield> is ignored and must be filled with zeros. The driver may adjust </structfield> is ignored and must be filled with zeros. The driver may adjust
coordinates of the requested rectangle. An application may coordinates of the requested rectangle. An application may
...@@ -149,8 +147,8 @@ On success the &v4l2-rect; <structfield>r</structfield> field contains ...@@ -149,8 +147,8 @@ On success the &v4l2-rect; <structfield>r</structfield> field contains
the adjusted rectangle. When the parameters are unsuitable the application may the adjusted rectangle. When the parameters are unsuitable the application may
modify the cropping (composing) or image parameters and repeat the cycle until modify the cropping (composing) or image parameters and repeat the cycle until
satisfactory parameters have been negotiated. If constraints flags have to be satisfactory parameters have been negotiated. If constraints flags have to be
violated at then ERANGE is returned. The error indicates that <emphasis> there violated at then ERANGE is returned. The error indicates that <emphasis>there
exist no rectangle </emphasis> that satisfies the constraints.</para> exist no rectangle</emphasis> that satisfies the constraints.</para>
<para>Selection targets and flags are documented in <xref <para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para> linkend="v4l2-selections-common"/>.</para>
......
...@@ -300,6 +300,12 @@ modulator programming see ...@@ -300,6 +300,12 @@ modulator programming see
<entry>0x00100000</entry> <entry>0x00100000</entry>
<entry>The device supports the <entry>The device supports the
<link linkend="sdr">SDR Capture</link> interface.</entry> <link linkend="sdr">SDR Capture</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_EXT_PIX_FORMAT</constant></entry>
<entry>0x00200000</entry>
<entry>The device supports the &v4l2-pix-format; extended
fields.</entry>
</row> </row>
<row> <row>
<entry><constant>V4L2_CAP_READWRITE</constant></entry> <entry><constant>V4L2_CAP_READWRITE</constant></entry>
......
<refentry id="vidioc-queryctrl"> <refentry id="vidioc-queryctrl">
<refmeta> <refmeta>
<refentrytitle>ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU</refentrytitle> <refentrytitle>ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERY_EXT_CTRL, VIDIOC_QUERYMENU</refentrytitle>
&manvol; &manvol;
</refmeta> </refmeta>
<refnamediv> <refnamediv>
<refname>VIDIOC_QUERYCTRL</refname> <refname>VIDIOC_QUERYCTRL</refname>
<refname>VIDIOC_QUERY_EXT_CTRL</refname>
<refname>VIDIOC_QUERYMENU</refname> <refname>VIDIOC_QUERYMENU</refname>
<refpurpose>Enumerate controls and menu control items</refpurpose> <refpurpose>Enumerate controls and menu control items</refpurpose>
</refnamediv> </refnamediv>
...@@ -19,6 +20,14 @@ ...@@ -19,6 +20,14 @@
<paramdef>struct v4l2_queryctrl *<parameter>argp</parameter></paramdef> <paramdef>struct v4l2_queryctrl *<parameter>argp</parameter></paramdef>
</funcprototype> </funcprototype>
</funcsynopsis> </funcsynopsis>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_query_ext_ctrl *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<funcsynopsis> <funcsynopsis>
<funcprototype> <funcprototype>
<funcdef>int <function>ioctl</function></funcdef> <funcdef>int <function>ioctl</function></funcdef>
...@@ -42,7 +51,7 @@ ...@@ -42,7 +51,7 @@
<varlistentry> <varlistentry>
<term><parameter>request</parameter></term> <term><parameter>request</parameter></term>
<listitem> <listitem>
<para>VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU</para> <para>VIDIOC_QUERYCTRL, VIDIOC_QUERY_EXT_CTRL, VIDIOC_QUERYMENU</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
...@@ -67,7 +76,7 @@ structure. The driver fills the rest of the structure or returns an ...@@ -67,7 +76,7 @@ structure. The driver fills the rest of the structure or returns an
<constant>VIDIOC_QUERYCTRL</constant> with successive <constant>VIDIOC_QUERYCTRL</constant> with successive
<structfield>id</structfield> values starting from <structfield>id</structfield> values starting from
<constant>V4L2_CID_BASE</constant> up to and exclusive <constant>V4L2_CID_BASE</constant> up to and exclusive
<constant>V4L2_CID_BASE_LASTP1</constant>. Drivers may return <constant>V4L2_CID_LASTP1</constant>. Drivers may return
<errorcode>EINVAL</errorcode> if a control in this range is not <errorcode>EINVAL</errorcode> if a control in this range is not
supported. Further applications can enumerate private controls, which supported. Further applications can enumerate private controls, which
are not defined in this specification, by starting at are not defined in this specification, by starting at
...@@ -89,9 +98,23 @@ prematurely end the enumeration).</para></footnote></para> ...@@ -89,9 +98,23 @@ prematurely end the enumeration).</para></footnote></para>
<para>When the application ORs <structfield>id</structfield> with <para>When the application ORs <structfield>id</structfield> with
<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> the driver returns the <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> the driver returns the
next supported control, or <errorcode>EINVAL</errorcode> if there is next supported non-compound control, or <errorcode>EINVAL</errorcode>
none. Drivers which do not support this flag yet always return if there is none. In addition, the <constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant>
<errorcode>EINVAL</errorcode>.</para> flag can be specified to enumerate all compound controls (i.e. controls
with type &ge; <constant>V4L2_CTRL_COMPOUND_TYPES</constant>). Specify both
<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> and
<constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> in order to enumerate
all controls, compound or not. Drivers which do not support these flags yet
always return <errorcode>EINVAL</errorcode>.</para>
<para>The <constant>VIDIOC_QUERY_EXT_CTRL</constant> ioctl was
introduced in order to better support controls that can use compound
types, and to expose additional control information that cannot be
returned in &v4l2-queryctrl; since that structure is full.</para>
<para><constant>VIDIOC_QUERY_EXT_CTRL</constant> is used in the
same way as <constant>VIDIOC_QUERYCTRL</constant>, except that the
<structfield>reserved</structfield> array must be zeroed as well.</para>
<para>Additional information is required for menu controls: the <para>Additional information is required for menu controls: the
names of the menu items. To query them applications set the names of the menu items. To query them applications set the
...@@ -142,38 +165,23 @@ string. This information is intended for the user.</entry> ...@@ -142,38 +165,23 @@ string. This information is intended for the user.</entry>
<entry>__s32</entry> <entry>__s32</entry>
<entry><structfield>minimum</structfield></entry> <entry><structfield>minimum</structfield></entry>
<entry>Minimum value, inclusive. This field gives a lower <entry>Minimum value, inclusive. This field gives a lower
bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the bound for the control. See &v4l2-ctrl-type; how the minimum value is to
lowest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> controls. be used for each possible control type. Note that this a signed 32-bit value.</entry>
For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value
gives the minimum length of the string. This length <emphasis>does not include the terminating
zero</emphasis>. It may not be valid for any other type of control, including
<constant>V4L2_CTRL_TYPE_INTEGER64</constant> controls. Note that this is a
signed value.</entry>
</row> </row>
<row> <row>
<entry>__s32</entry> <entry>__s32</entry>
<entry><structfield>maximum</structfield></entry> <entry><structfield>maximum</structfield></entry>
<entry>Maximum value, inclusive. This field gives an upper <entry>Maximum value, inclusive. This field gives an upper
bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the bound for the control. See &v4l2-ctrl-type; how the maximum value is to
highest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> be used for each possible control type. Note that this a signed 32-bit value.</entry>
controls. For <constant>V4L2_CTRL_TYPE_BITMASK</constant> controls it is the
set of usable bits.
For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the maximum value
gives the maximum length of the string. This length <emphasis>does not include the terminating
zero</emphasis>. It may not be valid for any other type of control, including
<constant>V4L2_CTRL_TYPE_INTEGER64</constant> controls. Note that this is a
signed value.</entry>
</row> </row>
<row> <row>
<entry>__s32</entry> <entry>__s32</entry>
<entry><structfield>step</structfield></entry> <entry><structfield>step</structfield></entry>
<entry><para>This field gives a step size for <entry><para>This field gives a step size for the control.
<constant>V4L2_CTRL_TYPE_INTEGER</constant> controls. For See &v4l2-ctrl-type; how the step value is to be used for each possible
<constant>V4L2_CTRL_TYPE_STRING</constant> controls this field refers to control type. Note that this an unsigned 32-bit value.
the string length that has to be a multiple of this step size. </para><para>Generally drivers should not scale hardware
It may not be valid for any other type of control, including
<constant>V4L2_CTRL_TYPE_INTEGER64</constant>
controls.</para><para>Generally drivers should not scale hardware
control values. It may be necessary for example when the control values. It may be necessary for example when the
<structfield>name</structfield> or <structfield>id</structfield> imply <structfield>name</structfield> or <structfield>id</structfield> imply
a particular unit and the hardware actually accepts only multiples of a particular unit and the hardware actually accepts only multiples of
...@@ -192,10 +200,11 @@ be always positive.</para></entry> ...@@ -192,10 +200,11 @@ be always positive.</para></entry>
<entry><structfield>default_value</structfield></entry> <entry><structfield>default_value</structfield></entry>
<entry>The default value of a <entry>The default value of a
<constant>V4L2_CTRL_TYPE_INTEGER</constant>, <constant>V4L2_CTRL_TYPE_INTEGER</constant>,
<constant>_BOOLEAN</constant> or <constant>_MENU</constant> control. <constant>_BOOLEAN</constant>, <constant>_BITMASK</constant>,
Not valid for other types of controls. Drivers reset controls only <constant>_MENU</constant> or <constant>_INTEGER_MENU</constant> control.
when the driver is loaded, not later, in particular not when the Not valid for other types of controls.
func-open; is called.</entry> Note that drivers reset controls to their default value only when the
driver is first loaded, never afterwards.</entry>
</row> </row>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
...@@ -213,6 +222,126 @@ the array to zero.</entry> ...@@ -213,6 +222,126 @@ the array to zero.</entry>
</tgroup> </tgroup>
</table> </table>
<table pgwide="1" frame="none" id="v4l2-query-ext-ctrl">
<title>struct <structname>v4l2_query_ext_ctrl</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry>Identifies the control, set by the application. See
<xref linkend="control-id" /> for predefined IDs. When the ID is ORed
with <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> the driver clears the
flag and returns the first non-compound control with a higher ID. When the
ID is ORed with <constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> the driver
clears the flag and returns the first compound control with a higher ID.
Set both to get the first control (compound or not) with a higher ID.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>Type of control, see <xref
linkend="v4l2-ctrl-type" />.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>name</structfield>[32]</entry>
<entry>Name of the control, a NUL-terminated ASCII
string. This information is intended for the user.</entry>
</row>
<row>
<entry>__s64</entry>
<entry><structfield>minimum</structfield></entry>
<entry>Minimum value, inclusive. This field gives a lower
bound for the control. See &v4l2-ctrl-type; how the minimum value is to
be used for each possible control type. Note that this a signed 64-bit value.</entry>
</row>
<row>
<entry>__s64</entry>
<entry><structfield>maximum</structfield></entry>
<entry>Maximum value, inclusive. This field gives an upper
bound for the control. See &v4l2-ctrl-type; how the maximum value is to
be used for each possible control type. Note that this a signed 64-bit value.</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>step</structfield></entry>
<entry><para>This field gives a step size for the control.
See &v4l2-ctrl-type; how the step value is to be used for each possible
control type. Note that this an unsigned 64-bit value.
</para><para>Generally drivers should not scale hardware
control values. It may be necessary for example when the
<structfield>name</structfield> or <structfield>id</structfield> imply
a particular unit and the hardware actually accepts only multiples of
said unit. If so, drivers must take care values are properly rounded
when scaling, such that errors will not accumulate on repeated
read-write cycles.</para><para>This field gives the smallest change of
an integer control actually affecting hardware. Often the information
is needed when the user can change controls by keyboard or GUI
buttons, rather than a slider. When for example a hardware register
accepts values 0-511 and the driver reports 0-65535, step should be
128.</para></entry>
</row>
<row>
<entry>__s64</entry>
<entry><structfield>default_value</structfield></entry>
<entry>The default value of a
<constant>V4L2_CTRL_TYPE_INTEGER</constant>, <constant>_INTEGER64</constant>,
<constant>_BOOLEAN</constant>, <constant>_BITMASK</constant>,
<constant>_MENU</constant>, <constant>_INTEGER_MENU</constant>,
<constant>_U8</constant> or <constant>_U16</constant> control.
Not valid for other types of controls.
Note that drivers reset controls to their default value only when the
driver is first loaded, never afterwards.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Control flags, see <xref
linkend="control-flags" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>elem_size</structfield></entry>
<entry>The size in bytes of a single element of the array.
Given a char pointer <constant>p</constant> to a 3-dimensional array you can find the
position of cell <constant>(z, y, x)</constant> as follows:
<constant>p + ((z * dims[1] + y) * dims[0] + x) * elem_size</constant>. <structfield>elem_size</structfield>
is always valid, also when the control isn't an array. For string controls
<structfield>elem_size</structfield> is equal to <structfield>maximum + 1</structfield>.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>elems</structfield></entry>
<entry>The number of elements in the N-dimensional array. If this control
is not an array, then <structfield>elems</structfield> is 1. The <structfield>elems</structfield>
field can never be 0.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>nr_of_dims</structfield></entry>
<entry>The number of dimension in the N-dimensional array. If this control
is not an array, then this field is 0.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>dims[V4L2_CTRL_MAX_DIMS]</structfield></entry>
<entry>The size of each dimension. The first <structfield>nr_of_dims</structfield>
elements of this array must be non-zero, all remaining elements must be zero.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[32]</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="v4l2-querymenu"> <table pgwide="1" frame="none" id="v4l2-querymenu">
<title>struct <structname>v4l2_querymenu</structname></title> <title>struct <structname>v4l2_querymenu</structname></title>
<tgroup cols="4"> <tgroup cols="4">
...@@ -347,11 +476,14 @@ Drivers must ignore the value passed with ...@@ -347,11 +476,14 @@ Drivers must ignore the value passed with
</row> </row>
<row> <row>
<entry><constant>V4L2_CTRL_TYPE_INTEGER64</constant></entry> <entry><constant>V4L2_CTRL_TYPE_INTEGER64</constant></entry>
<entry>n/a</entry> <entry>any</entry>
<entry>n/a</entry> <entry>any</entry>
<entry>n/a</entry> <entry>any</entry>
<entry>A 64-bit integer valued control. Minimum, maximum <entry>A 64-bit integer valued control. Minimum, maximum
and step size cannot be queried.</entry> and step size cannot be queried using <constant>VIDIOC_QUERYCTRL</constant>.
Only <constant>VIDIOC_QUERY_EXT_CTRL</constant> can retrieve the 64-bit
min/max/step values, they should be interpreted as n/a when using
<constant>VIDIOC_QUERYCTRL</constant>.</entry>
</row> </row>
<row> <row>
<entry><constant>V4L2_CTRL_TYPE_STRING</constant></entry> <entry><constant>V4L2_CTRL_TYPE_STRING</constant></entry>
...@@ -379,6 +511,26 @@ ioctl returns the name of the control class and this control type. ...@@ -379,6 +511,26 @@ ioctl returns the name of the control class and this control type.
Older drivers which do not support this feature return an Older drivers which do not support this feature return an
&EINVAL;.</entry> &EINVAL;.</entry>
</row> </row>
<row>
<entry><constant>V4L2_CTRL_TYPE_U8</constant></entry>
<entry>any</entry>
<entry>any</entry>
<entry>any</entry>
<entry>An unsigned 8-bit valued control ranging from minimum to
maximum inclusive. The step value indicates the increment between
values which are actually different on the hardware.
</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_TYPE_U16</constant></entry>
<entry>any</entry>
<entry>any</entry>
<entry>any</entry>
<entry>An unsigned 16-bit valued control ranging from minimum to
maximum inclusive. The step value indicates the increment between
values which are actually different on the hardware.
</entry>
</row>
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
...@@ -450,6 +602,14 @@ is in auto-gain mode. In such a case the hardware calculates the gain value base ...@@ -450,6 +602,14 @@ is in auto-gain mode. In such a case the hardware calculates the gain value base
the lighting conditions which can change over time. Note that setting a new value for the lighting conditions which can change over time. Note that setting a new value for
a volatile control will have no effect. The new value will just be ignored.</entry> a volatile control will have no effect. The new value will just be ignored.</entry>
</row> </row>
<row>
<entry><constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant></entry>
<entry>0x0100</entry>
<entry>This control has a pointer type, so its value has to be accessed
using one of the pointer fields of &v4l2-ext-control;. This flag is set for controls
that are an array, string, or have a compound type. In all cases you have to set a
pointer to memory containing the payload of the control.</entry>
</row>
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
......
...@@ -174,6 +174,14 @@ ...@@ -174,6 +174,14 @@
will have the ORed value of all the events generated.</para> will have the ORed value of all the events generated.</para>
</entry> </entry>
</row> </row>
<row>
<entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
<entry>5</entry>
<entry>
<para>Triggered whenever the motion detection state for one or more of the regions
changes. This event has a &v4l2-event-motion-det; associated with it.</para>
</entry>
</row>
<row> <row>
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry> <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
<entry>0x08000000</entry> <entry>0x08000000</entry>
......
...@@ -576,7 +576,7 @@ Some devices are known to have faulty MSI implementations. Usually this ...@@ -576,7 +576,7 @@ Some devices are known to have faulty MSI implementations. Usually this
is handled in the individual device driver, but occasionally it's necessary is handled in the individual device driver, but occasionally it's necessary
to handle this with a quirk. Some drivers have an option to disable use to handle this with a quirk. Some drivers have an option to disable use
of MSI. While this is a convenient workaround for the driver author, of MSI. While this is a convenient workaround for the driver author,
it is not good practise, and should not be emulated. it is not good practice, and should not be emulated.
5.4. Finding why MSIs are disabled on a device 5.4. Finding why MSIs are disabled on a device
......
...@@ -818,7 +818,7 @@ RCU pointer/list update: ...@@ -818,7 +818,7 @@ RCU pointer/list update:
list_add_tail_rcu list_add_tail_rcu
list_del_rcu list_del_rcu
list_replace_rcu list_replace_rcu
hlist_add_after_rcu hlist_add_behind_rcu
hlist_add_before_rcu hlist_add_before_rcu
hlist_add_head_rcu hlist_add_head_rcu
hlist_del_rcu hlist_del_rcu
......
...@@ -146,10 +146,6 @@ LWN.net: ...@@ -146,10 +146,6 @@ LWN.net:
Porting drivers from prior kernels to 2.6: Porting drivers from prior kernels to 2.6:
http://lwn.net/Articles/driver-porting/ http://lwn.net/Articles/driver-porting/
KernelTrap:
Occasional Linux kernel articles and developer interviews
http://kerneltrap.org/
KernelNewbies: KernelNewbies:
Documentation and assistance for new kernel programmers Documentation and assistance for new kernel programmers
http://kernelnewbies.org/ http://kernelnewbies.org/
......
...@@ -84,18 +84,42 @@ is another popular alternative. ...@@ -84,18 +84,42 @@ is another popular alternative.
2) Describe your changes. 2) Describe your changes.
Describe the technical detail of the change(s) your patch includes. Describe your problem. Whether your patch is a one-line bug fix or
5000 lines of a new feature, there must be an underlying problem that
Be as specific as possible. The WORST descriptions possible include motivated you to do this work. Convince the reviewer that there is a
things like "update driver X", "bug fix for driver X", or "this patch problem worth fixing and that it makes sense for them to read past the
includes updates for subsystem X. Please apply." first paragraph.
Describe user-visible impact. Straight up crashes and lockups are
pretty convincing, but not all bugs are that blatant. Even if the
problem was spotted during code review, describe the impact you think
it can have on users. Keep in mind that the majority of Linux
installations run kernels from secondary stable trees or
vendor/product-specific trees that cherry-pick only specific patches
from upstream, so include anything that could help route your change
downstream: provoking circumstances, excerpts from dmesg, crash
descriptions, performance regressions, latency spikes, lockups, etc.
Quantify optimizations and trade-offs. If you claim improvements in
performance, memory consumption, stack footprint, or binary size,
include numbers that back them up. But also describe non-obvious
costs. Optimizations usually aren't free but trade-offs between CPU,
memory, and readability; or, when it comes to heuristics, between
different workloads. Describe the expected downsides of your
optimization so that the reviewer can weigh costs against benefits.
Once the problem is established, describe what you are actually doing
about it in technical detail. It's important to describe the change
in plain English for the reviewer to verify that the code is behaving
as you intend it to.
The maintainer will thank you if you write your patch description in a The maintainer will thank you if you write your patch description in a
form which can be easily pulled into Linux's source code management form which can be easily pulled into Linux's source code management
system, git, as a "commit log". See #15, below. system, git, as a "commit log". See #15, below.
If your description starts to get long, that's a sign that you probably Solve only one problem per patch. If your description starts to get
need to split up your patch. See #3, next. long, that's a sign that you probably need to split up your patch.
See #3, next.
When you submit or resubmit a patch or patch series, include the When you submit or resubmit a patch or patch series, include the
complete patch description and justification for it. Don't just complete patch description and justification for it. Don't just
...@@ -396,13 +420,13 @@ you are responsible for last-minute changes. Example : ...@@ -396,13 +420,13 @@ you are responsible for last-minute changes. Example :
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
This practise is particularly helpful if you maintain a stable branch and This practice is particularly helpful if you maintain a stable branch and
want at the same time to credit the author, track changes, merge the fix, want at the same time to credit the author, track changes, merge the fix,
and protect the submitter from complaints. Note that under no circumstances and protect the submitter from complaints. Note that under no circumstances
can you change the author's identity (the From header), as it is the one can you change the author's identity (the From header), as it is the one
which appears in the changelog. which appears in the changelog.
Special note to back-porters: It seems to be a common and useful practise Special note to back-porters: It seems to be a common and useful practice
to insert an indication of the origin of a patch at the top of the commit to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance, message (just after the subject line) to facilitate tracking. For instance,
here's what we see in 2.6-stable : here's what we see in 2.6-stable :
......
ARM Cache Coherent Network
==========================
CCN-504 is a ring-bus interconnect consisting of 11 crosspoints
(XPs), with each crosspoint supporting up to two device ports,
so nodes (devices) 0 and 1 are connected to crosspoint 0,
nodes 2 and 3 to crosspoint 1 etc.
PMU (perf) driver
-----------------
The CCN driver registers a perf PMU driver, which provides
description of available events and configuration options
in sysfs, see /sys/bus/event_source/devices/ccn*.
The "format" directory describes format of the config, config1
and config2 fields of the perf_event_attr structure. The "events"
directory provides configuration templates for all documented
events, that can be used with perf tool. For example "xp_valid_flit"
is an equivalent of "type=0x8,event=0x4". Other parameters must be
explicitly specified. For events originating from device, "node"
defines its index. All crosspoint events require "xp" (index),
"port" (device port number) and "vc" (virtual channel ID) and
"dir" (direction). Watchpoints (special "event" value 0xfe) also
require comparator values ("cmp_l" and "cmp_h") and "mask", being
index of the comparator mask.
Masks are defined separately from the event description
(due to limited number of the config values) in the "cmp_mask"
directory, with first 8 configurable by user and additional
4 hardcoded for the most frequent use cases.
Cycle counter is described by a "type" value 0xff and does
not require any other settings.
Example of perf tool use:
/ # perf list | grep ccn
ccn/cycles/ [Kernel PMU event]
<...>
ccn/xp_valid_flit/ [Kernel PMU event]
<...>
/ # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \
sleep 1
The driver does not support sampling, therefore "perf record" will
not work. Also notice that only single cpu is being selected
("-C 0") - this is because perf framework does not support
"non-CPU related" counters (yet?) so system-wide session ("-a")
would try (and in most cases fail) to set up the same event
per each CPU.
...@@ -53,8 +53,8 @@ Kirkwood family ...@@ -53,8 +53,8 @@ Kirkwood family
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage: http://www.marvell.com/embedded-processors/kirkwood/ Homepage: http://www.marvell.com/embedded-processors/kirkwood/
Core: Feroceon ARMv5 compatible Core: Feroceon ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-kirkwood Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: arch/arm/plat-orion Linux kernel plat directory: none
Discovery family Discovery family
---------------- ----------------
...@@ -83,7 +83,9 @@ EBU Armada family ...@@ -83,7 +83,9 @@ EBU Armada family
88F6710 88F6710
88F6707 88F6707
88F6W11 88F6W11
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Armada 375 Flavors: Armada 375 Flavors:
88F6720 88F6720
...@@ -100,8 +102,7 @@ EBU Armada family ...@@ -100,8 +102,7 @@ EBU Armada family
MV78460 MV78460
NOTE: not to be confused with the non-SMP 78xx0 SoCs NOTE: not to be confused with the non-SMP 78xx0 SoCs
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
No public datasheet available.
Core: Sheeva ARMv7 compatible Core: Sheeva ARMv7 compatible
...@@ -135,7 +136,9 @@ Dove family (application processor) ...@@ -135,7 +136,9 @@ Dove family (application processor)
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage: http://www.marvell.com/application-processors/armada-500/ Homepage: http://www.marvell.com/application-processors/armada-500/
Core: ARMv7 compatible Core: ARMv7 compatible
Directory: arch/arm/mach-dove
Directory: arch/arm/mach-mvebu (DT enabled platforms)
arch/arm/mach-dove (non-DT enabled platforms)
PXA 2xx/3xx/93x/95x family PXA 2xx/3xx/93x/95x family
-------------------------- --------------------------
...@@ -253,10 +256,10 @@ Berlin family (Digital Entertainment) ...@@ -253,10 +256,10 @@ Berlin family (Digital Entertainment)
Long-term plans Long-term plans
--------------- ---------------
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
Marvell EBU (Engineering Business Unit) in a single mach-<foo> Business Unit) in a single mach-<foo> directory. The plat-orion/
directory. The plat-orion/ would therefore disappear. would therefore disappear.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa * Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ would therefore disappear. directory. The plat-pxa/ would therefore disappear.
......
...@@ -13,8 +13,6 @@ Introduction ...@@ -13,8 +13,6 @@ Introduction
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
- S3C64XX: S3C6400 and S3C6410 - S3C64XX: S3C6400 and S3C6410
- S5P6440
- S5PC100
- S5PC110 / S5PV210 - S5PC110 / S5PV210
...@@ -34,8 +32,6 @@ Configuration ...@@ -34,8 +32,6 @@ Configuration
A number of configurations are supplied, as there is no current way of A number of configurations are supplied, as there is no current way of
unifying all the SoCs into one kernel. unifying all the SoCs into one kernel.
s5p6440_defconfig - S5P6440 specific default configuration
s5pc100_defconfig - S5PC100 specific default configuration
s5pc110_defconfig - S5PC110 specific default configuration s5pc110_defconfig - S5PC110 specific default configuration
s5pv210_defconfig - S5PV210 specific default configuration s5pv210_defconfig - S5PV210 specific default configuration
...@@ -67,13 +63,6 @@ Layout changes ...@@ -67,13 +63,6 @@ Layout changes
where to simplify the include and dependency issues involved with having where to simplify the include and dependency issues involved with having
so many different platform directories. so many different platform directories.
It was decided to remove plat-s5pc1xx as some of the support was already
in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
the only user was the S5PC100. The S5PC100 specific items where moved to
arch/arm/mach-s5pc100.
Port Contributors Port Contributors
----------------- -----------------
......
...@@ -68,7 +68,6 @@ BEGIN { ...@@ -68,7 +68,6 @@ BEGIN {
while (getline line < ARGV[1] > 0) { while (getline line < ARGV[1] > 0) {
if (line ~ /\#define.*_MASK/ && if (line ~ /\#define.*_MASK/ &&
!(line ~ /S5PC100_EPLL_MASK/) &&
!(line ~ /USB_SIG_MASK/)) { !(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields) splitdefine(line, fields)
name = fields[0] name = fields[0]
......
...@@ -168,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met: ...@@ -168,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met:
the kernel image will be entered must be initialised by software at a the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state. higher exception level to prevent execution in an UNKNOWN state.
For systems with a GICv3 interrupt controller:
- If EL3 is present:
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- If the kernel is entered at EL1:
ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
The requirements described above for CPU mode, caches, MMUs, architected The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level. enter the kernel in the same exception level.
......
...@@ -24,64 +24,27 @@ Please note that implementation details can be changed. ...@@ -24,64 +24,27 @@ Please note that implementation details can be changed.
a page/swp_entry may be charged (usage += PAGE_SIZE) at a page/swp_entry may be charged (usage += PAGE_SIZE) at
mem_cgroup_charge_anon() mem_cgroup_try_charge()
Called at new page fault and Copy-On-Write.
mem_cgroup_try_charge_swapin()
Called at do_swap_page() (page fault on swap entry) and swapoff.
Followed by charge-commit-cancel protocol. (With swap accounting)
At commit, a charge recorded in swap_cgroup is removed.
mem_cgroup_charge_file()
Called at add_to_page_cache()
mem_cgroup_cache_charge_swapin()
Called at shmem's swapin.
mem_cgroup_prepare_migration()
Called before migration. "extra" charge is done and followed by
charge-commit-cancel protocol.
At commit, charge against oldpage or newpage will be committed.
2. Uncharge 2. Uncharge
a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by
mem_cgroup_uncharge_page() mem_cgroup_uncharge()
Called when an anonymous page is fully unmapped. I.e., mapcount goes Called when a page's refcount goes down to 0.
to 0. If the page is SwapCache, uncharge is delayed until
mem_cgroup_uncharge_swapcache().
mem_cgroup_uncharge_cache_page()
Called when a page-cache is deleted from radix-tree. If the page is
SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache().
mem_cgroup_uncharge_swapcache()
Called when SwapCache is removed from radix-tree. The charge itself
is moved to swap_cgroup. (If mem+swap controller is disabled, no
charge to swap occurs.)
mem_cgroup_uncharge_swap() mem_cgroup_uncharge_swap()
Called when swp_entry's refcnt goes down to 0. A charge against swap Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears. disappears.
mem_cgroup_end_migration(old, new)
At success of migration old is uncharged (if necessary), a charge
to new page is committed. At failure, charge to old page is committed.
3. charge-commit-cancel 3. charge-commit-cancel
In some case, we can't know this "charge" is valid or not at charging Memcg pages are charged in two steps:
(because of races). mem_cgroup_try_charge()
To handle such case, there are charge-commit-cancel functions. mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
mem_cgroup_try_charge_XXX
mem_cgroup_commit_charge_XXX
mem_cgroup_cancel_charge_XXX
these are used in swap-in and migration.
At try_charge(), there are no flags to say "this page is charged". At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE. at this point, usage += PAGE_SIZE.
At commit(), the function checks the page should be charged or not At commit(), the page is associated with the memcg.
and set flags or avoid charging.(usage -= PAGE_SIZE)
At cancel(), simply usage -= PAGE_SIZE. At cancel(), simply usage -= PAGE_SIZE.
...@@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. ...@@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
Anonymous page is newly allocated at Anonymous page is newly allocated at
- page fault into MAP_ANONYMOUS mapping. - page fault into MAP_ANONYMOUS mapping.
- Copy-On-Write. - Copy-On-Write.
It is charged right after it's allocated before doing any page table
related operations. Of course, it's uncharged when another page is used
for the fault address.
At freeing anonymous page (by exit() or munmap()), zap_pte() is called
and pages for ptes are freed one by one.(see mm/memory.c). Uncharges
are done at page_remove_rmap() when page_mapcount() goes down to 0.
Another page freeing is by page-reclaim (vmscan.c) and anonymous
pages are swapped out. In this case, the page is marked as
PageSwapCache(). uncharge() routine doesn't uncharge the page marked
as SwapCache(). It's delayed until __delete_from_swap_cache().
4.1 Swap-in. 4.1 Swap-in.
At swap-in, the page is taken from swap-cache. There are 2 cases. At swap-in, the page is taken from swap-cache. There are 2 cases.
...@@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. ...@@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
(b) If the SwapCache has been mapped by processes, it has been (b) If the SwapCache has been mapped by processes, it has been
charged already. charged already.
This swap-in is one of the most complicated work. In do_swap_page(),
following events occur when pte is unchanged.
(1) the page (SwapCache) is looked up.
(2) lock_page()
(3) try_charge_swapin()
(4) reuse_swap_page() (may call delete_swap_cache())
(5) commit_charge_swapin()
(6) swap_free().
Considering following situation for example.
(A) The page has not been charged before (2) and reuse_swap_page()
doesn't call delete_from_swap_cache().
(B) The page has not been charged before (2) and reuse_swap_page()
calls delete_from_swap_cache().
(C) The page has been charged before (2) and reuse_swap_page() doesn't
call delete_from_swap_cache().
(D) The page has been charged before (2) and reuse_swap_page() calls
delete_from_swap_cache().
memory.usage/memsw.usage changes to this page/swp_entry will be
Case (A) (B) (C) (D)
Event
Before (2) 0/ 1 0/ 1 1/ 1 1/ 1
===========================================
(3) +1/+1 +1/+1 +1/+1 +1/+1
(4) - 0/ 0 - -1/ 0
(5) 0/-1 0/ 0 -1/-1 0/ 0
(6) - 0/-1 - 0/-1
===========================================
Result 1/ 1 1/ 1 1/ 1 1/ 1
In any cases, charges to this page should be 1/ 1.
4.2 Swap-out. 4.2 Swap-out.
At swap-out, typical state transition is below. At swap-out, typical state transition is below.
...@@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. ...@@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
swp_entry's refcnt -= 1. swp_entry's refcnt -= 1.
At (b), the page is marked as SwapCache and not uncharged.
At (d), the page is removed from SwapCache and a charge in page_cgroup
is moved to swap_cgroup.
Finally, at task exit, Finally, at task exit,
(e) zap_pte() is called and swp_entry's refcnt -=1 -> 0. (e) zap_pte() is called and swp_entry's refcnt -=1 -> 0.
Here, a charge in swap_cgroup disappears.
5. Page Cache 5. Page Cache
Page Cache is charged at Page Cache is charged at
- add_to_page_cache_locked(). - add_to_page_cache_locked().
uncharged at
- __remove_from_page_cache().
The logic is very clear. (About migration, see below) The logic is very clear. (About migration, see below)
Note: __remove_from_page_cache() is called by remove_from_page_cache() Note: __remove_from_page_cache() is called by remove_from_page_cache()
and __remove_mapping(). and __remove_mapping().
6. Shmem(tmpfs) Page Cache 6. Shmem(tmpfs) Page Cache
Memcg's charge/uncharge have special handlers of shmem. The best way The best way to understand shmem's page state transition is to read
to understand shmem's page state transition is to read mm/shmem.c. mm/shmem.c.
But brief explanation of the behavior of memcg around shmem will be But brief explanation of the behavior of memcg around shmem will be
helpful to understand the logic. helpful to understand the logic.
...@@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. ...@@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
It's charged when... It's charged when...
- A new page is added to shmem's radix-tree. - A new page is added to shmem's radix-tree.
- A swp page is read. (move a charge from swap_cgroup to page_cgroup) - A swp page is read. (move a charge from swap_cgroup to page_cgroup)
It's uncharged when
- A page is removed from radix-tree and not SwapCache.
- When SwapCache is removed, a charge is moved to swap_cgroup.
- When swp_entry's refcnt goes down to 0, a charge in swap_cgroup
disappears.
7. Page Migration 7. Page Migration
One of the most complicated functions is page-migration-handler.
Memcg has 2 routines. Assume that we are migrating a page's contents mem_cgroup_migrate()
from OLDPAGE to NEWPAGE.
Usual migration logic is..
(a) remove the page from LRU.
(b) allocate NEWPAGE (migration target)
(c) lock by lock_page().
(d) unmap all mappings.
(e-1) If necessary, replace entry in radix-tree.
(e-2) move contents of a page.
(f) map all mappings again.
(g) pushback the page to LRU.
(-) OLDPAGE will be freed.
Before (g), memcg should complete all necessary charge/uncharge to
NEWPAGE/OLDPAGE.
The point is....
- If OLDPAGE is anonymous, all charges will be dropped at (d) because
try_to_unmap() drops all mapcount and the page will not be
SwapCache.
- If OLDPAGE is SwapCache, charges will be kept at (g) because
__delete_from_swap_cache() isn't called at (e-1)
- If OLDPAGE is page-cache, charges will be kept at (g) because
remove_from_swap_cache() isn't called at (e-1)
memcg provides following hooks.
- mem_cgroup_prepare_migration(OLDPAGE)
Called after (b) to account a charge (usage += PAGE_SIZE) against
memcg which OLDPAGE belongs to.
- mem_cgroup_end_migration(OLDPAGE, NEWPAGE)
Called after (f) before (g).
If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already
charged, a charge by prepare_migration() is automatically canceled.
If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE.
But zap_pte() (by exit or munmap) can be called while migration,
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
8. LRU 8. LRU
Each memcg has its own private LRU. Now, its handling is under global Each memcg has its own private LRU. Now, its handling is under global
......
...@@ -106,6 +106,11 @@ which paths. ...@@ -106,6 +106,11 @@ which paths.
The path number in the range 0 ... (<num_paths> - 1). The path number in the range 0 ... (<num_paths> - 1).
Expressed in hexadecimal (WITHOUT any prefix like 0x). Expressed in hexadecimal (WITHOUT any prefix like 0x).
R<n>,<m>
This parameter allows repetitive patterns to be loaded quickly. <n> and <m>
are hexadecimal numbers. The last <n> mappings are repeated in the next <m>
slots.
Status Status
====== ======
...@@ -124,3 +129,10 @@ Create a switch device with 64kB region size: ...@@ -124,3 +129,10 @@ Create a switch device with 64kB region size:
Set mappings for the first 7 entries to point to devices switch0, switch1, Set mappings for the first 7 entries to point to devices switch0, switch1,
switch2, switch0, switch1, switch2, switch1: switch2, switch0, switch1, switch2, switch1:
dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1 dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
Set repetitive mapping. This command:
dmsetup message switch 0 set_region_mappings 1000:1 :2 R2,10
is equivalent to:
dmsetup message switch 0 set_region_mappings 1000:1 :2 :1 :2 :1 :2 :1 :2 \
:1 :2 :1 :2 :1 :2 :1 :2 :1 :2
Adapteva Platforms Device Tree Bindings
---------------------------------------
Parallella board
Required root node properties:
- compatible = "adapteva,parallella";
...@@ -86,3 +86,9 @@ Interrupt controllers: ...@@ -86,3 +86,9 @@ Interrupt controllers:
compatible = "arm,versatile-sic"; compatible = "arm,versatile-sic";
interrupt-controller; interrupt-controller;
#interrupt-cells = <1>; #interrupt-cells = <1>;
Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
Marvell Armada 38x CA9 MPcore SoC Controller
============================================
Required properties:
- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
- reg: should be the register base and length as documented in the
datasheet for the CA9 MPcore SoC Control registers
mpcore-soc-ctrl@20d20 {
compatible = "marvell,armada-380-mpcore-soc-ctrl";
reg = <0x20d20 0x6c>;
};
* Power Management Controller (PMC) * Power Management Controller (PMC)
Required properties: Required properties:
- compatible: Should be "atmel,at91rm9200-pmc" - compatible: Should be "atmel,<chip>-pmc".
<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
at91sam9x5, sama5d3
- reg: Should contain PMC registers location and length - reg: Should contain PMC registers location and length
Examples: Examples:
......
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpus" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
};
};
ARM Broadcom STB platforms Device Tree Bindings
-----------------------------------------------
Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
SoC shall have the following DT organization:
Required root node properties:
- compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
example:
/ {
#address-cells = <2>;
#size-cells = <2>;
model = "Broadcom STB (bcm7445)";
compatible = "brcm,bcm7445", "brcm,brcmstb";
Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
example:
rdb {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges = <0 0x00 0xf0000000 0x1000000>;
sun_top_ctrl: syscon@404000 {
compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
reg = <0x404000 0x51c>;
};
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
reg = <0x3e2400 0x5b4>;
};
hif_continuation: syscon@452000 {
compatible = "brcm,bcm7445-hif-continuation", "syscon";
reg = <0x452000 0x100>;
};
};
Lastly, nodes that allow for support of SMP initialization and reboot are
required:
smpboot
-------
Required properties:
- compatible
The string "brcm,brcmstb-smpboot".
- syscon-cpu
A phandle / integer array property which lets the BSP know the location
of certain CPU power-on registers.
The layout of the property is as follows:
o a phandle to the "hif_cpubiuctrl" syscon node
o offset to the base CPU power zone register
o offset to the base CPU reset register
- syscon-cont
A phandle pointing to the syscon node which describes the CPU boot
continuation registers.
o a phandle to the "hif_continuation" syscon node
example:
smpboot {
compatible = "brcm,brcmstb-smpboot";
syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
syscon-cont = <&hif_continuation>;
};
reboot
-------
Required properties
- compatible
The string property "brcm,brcmstb-reboot".
- syscon
A phandle / integer array that points to the syscon node which describes
the general system reset registers.
o a phandle to "sun_top_ctrl"
o offset to the "reset source enable" register
o offset to the "software master reset" register
example:
reboot {
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};
* ARM CCN (Cache Coherent Network)
Required properties:
- compatible: (standard compatible string) should be one of:
"arm,ccn-504"
"arm,ccn-508"
- reg: (standard registers property) physical address and size
(16MB) of the configuration registers block
- interrupts: (standard interrupt property) single interrupt
generated by the control block
Example:
ccn@0x2000000000 {
compatible = "arm,ccn-504";
reg = <0x20 0x00000000 0 0x1000000>;
interrupts = <0 181 4>;
};
========================================================
Secondary CPU enable-method "marvell,berlin-smp" binding
========================================================
This document describes the "marvell,berlin-smp" method for enabling secondary
CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should
be defined in the "cpus" node.
Enable method name: "marvell,berlin-smp"
Compatible machines: "marvell,berlin2" and "marvell,berlin2q"
Compatible CPUs: "marvell,pj4b" and "arm,cortex-a9"
Related properties: (none)
Note:
This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
"marvell,berlin-cpu-ctrl"[1].
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "marvell,berlin-smp";
cpu@0 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <0>;
};
cpu@1 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
};
};
--
[1] arm/marvell,berlin.txt
...@@ -152,7 +152,9 @@ nodes to be present and contain the properties described below. ...@@ -152,7 +152,9 @@ nodes to be present and contain the properties described below.
"arm,cortex-a7" "arm,cortex-a7"
"arm,cortex-a8" "arm,cortex-a8"
"arm,cortex-a9" "arm,cortex-a9"
"arm,cortex-a12"
"arm,cortex-a15" "arm,cortex-a15"
"arm,cortex-a17"
"arm,cortex-a53" "arm,cortex-a53"
"arm,cortex-a57" "arm,cortex-a57"
"arm,cortex-m0" "arm,cortex-m0"
...@@ -163,6 +165,7 @@ nodes to be present and contain the properties described below. ...@@ -163,6 +165,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r4" "arm,cortex-r4"
"arm,cortex-r5" "arm,cortex-r5"
"arm,cortex-r7" "arm,cortex-r7"
"brcm,brahma-b15"
"faraday,fa526" "faraday,fa526"
"intel,sa110" "intel,sa110"
"intel,sa1100" "intel,sa1100"
...@@ -184,6 +187,7 @@ nodes to be present and contain the properties described below. ...@@ -184,6 +187,7 @@ nodes to be present and contain the properties described below.
can be one of: can be one of:
"allwinner,sun6i-a31" "allwinner,sun6i-a31"
"arm,psci" "arm,psci"
"brcm,brahma-b15"
"marvell,armada-375-smp" "marvell,armada-375-smp"
"marvell,armada-380-smp" "marvell,armada-380-smp"
"marvell,armada-xp-smp" "marvell,armada-xp-smp"
......
* ARM Generic Interrupt Controller, version 3
AArch64 SMP cores are often associated with a GICv3, providing Private
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
Software Generated Interrupts (SGI), and Locality-specific Peripheral
Interrupts (LPI).
Main node required properties:
- compatible : should at least contain "arm,gic-v3".
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. Must be a single cell with a value of at least 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts. Other values are reserved for future use.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = edge triggered
4 = level triggered
Cells 4 and beyond are reserved for future use. When the 1st cell
has a value of 0 or 1, cells 4 and beyond act as padding, and may be
ignored. It is recommended that padding cells have a value of 0.
- reg : Specifies base physical address(s) and size of the GIC
registers, in the following order:
- GIC Distributor interface (GICD)
- GIC Redistributors (GICR), one range per redistributor region
- GIC CPU interface (GICC)
- GIC Hypervisor interface (GICH)
- GIC Virtual CPU interface (GICV)
GICC, GICH and GICV are optional.
- interrupts : Interrupt source of the VGIC maintenance interrupt.
Optional
- redistributor-stride : If using padding pages, specifies the stride
of consecutive redistributors. Must be a multiple of 64kB.
- #redistributor-regions: The number of independent contiguous regions
occupied by the redistributors. Required if more than one such
region is present.
Examples:
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x0 0x2f000000 0 0x10000>, // GICD
<0x0 0x2f100000 0 0x200000>, // GICR
<0x0 0x2c000000 0 0x2000>, // GICC
<0x0 0x2c010000 0 0x2000>, // GICH
<0x0 0x2c020000 0 0x2000>; // GICV
interrupts = <1 9 4>;
};
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
reg = <0x0 0x2c010000 0 0x10000>, // GICD
<0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31
<0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63
<0x0 0x2c040000 0 0x2000>, // GICC
<0x0 0x2c060000 0 0x2000>, // GICH
<0x0 0x2c080000 0 0x2000>; // GICV
interrupts = <1 9 4>;
};
...@@ -16,6 +16,7 @@ Main node required properties: ...@@ -16,6 +16,7 @@ Main node required properties:
"arm,cortex-a9-gic" "arm,cortex-a9-gic"
"arm,cortex-a7-gic" "arm,cortex-a7-gic"
"arm,arm11mp-gic" "arm,arm11mp-gic"
"brcm,brahma-b15-gic"
- interrupt-controller : Identifies the node as an interrupt controller - interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an - #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3. interrupt source. The type shall be a <u32> and the value shall be 3.
......
...@@ -31,6 +31,17 @@ Example: ...@@ -31,6 +31,17 @@ Example:
reboot-offset = <0x4>; reboot-offset = <0x4>;
}; };
-----------------------------------------------------------------------
Hisilicon CPU controller
Required properties:
- compatible : "hisilicon,cpuctrl"
- reg : Register address and size
The clock registers and power registers of secondary cores are defined
in CPU controller, especially in HIX5HD2 SoC.
-----------------------------------------------------------------------
PCTRL: Peripheral misc control register PCTRL: Peripheral misc control register
Required Properties: Required Properties:
......
...@@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are: ...@@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are:
... ...
} }
* Marvell Berlin CPU control bindings
CPU control register allows various operations on CPUs, like resetting them
independently.
Required properties:
- compatible: should be "marvell,berlin-cpu-ctrl"
- reg: address and length of the register set
Example:
cpu-ctrl@f7dd0000 {
compatible = "marvell,berlin-cpu-ctrl";
reg = <0xf7dd0000 0x10000>;
};
* Marvell Berlin2 chip control binding * Marvell Berlin2 chip control binding
Marvell Berlin SoCs have a chip control register set providing several Marvell Berlin SoCs have a chip control register set providing several
......
Mediatek MT6589 Platforms Device Tree Bindings
Boards with a SoC of the Mediatek MT6589 shall have the following property:
Required root node property:
compatible: must contain "mediatek,mt6589"
...@@ -10,6 +10,7 @@ Required properties: ...@@ -10,6 +10,7 @@ Required properties:
- compatible : Should be "ti,irq-crossbar" - compatible : Should be "ti,irq-crossbar"
- reg: Base address and the size of the crossbar registers. - reg: Base address and the size of the crossbar registers.
- ti,max-irqs: Total number of irqs available at the interrupt controller. - ti,max-irqs: Total number of irqs available at the interrupt controller.
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
- ti,reg-size: Size of a individual register in bytes. Every individual - ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4. register is assumed to be of same size. Valid sizes are 1, 2, 4.
- ti,irqs-reserved: List of the reserved irq lines that are not muxed using - ti,irqs-reserved: List of the reserved irq lines that are not muxed using
...@@ -17,11 +18,46 @@ Required properties: ...@@ -17,11 +18,46 @@ Required properties:
so crossbar bar driver should not consider them as free so crossbar bar driver should not consider them as free
lines. lines.
Optional properties:
- ti,irqs-skip: This is similar to "ti,irqs-reserved", but these are for
SOC-specific hard-wiring of those irqs which unexpectedly bypasses the
crossbar. These irqs have a crossbar register, but still cannot be used.
- ti,irqs-safe-map: integer which maps to a safe configuration to use
when the interrupt controller irq is unused (when not provided, default is 0)
Examples: Examples:
crossbar_mpu: @4a020000 { crossbar_mpu: @4a020000 {
compatible = "ti,irq-crossbar"; compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>; reg = <0x4a002a48 0x130>;
ti,max-irqs = <160>; ti,max-irqs = <160>;
ti,max-crossbar-sources = <400>;
ti,reg-size = <2>; ti,reg-size = <2>;
ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>; ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
ti,irqs-skip = <10 133 139 140>;
}; };
Consumer:
========
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/arm/gic.txt for further details.
An interrupt consumer on an SoC using crossbar will use:
interrupts = <GIC_SPI request_number interrupt_level>
When the request number is between 0 to that described by
"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
request_number is greater than "ti,max-crossbar-sources", then it is mapped as a
quirky hardware mapping direct to GIC.
Example:
device_x@0x4a023000 {
/* Crossbar 8 used */
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
...
};
device_y@0x4a033000 {
/* Direct mapped GIC SPI 1 used */
interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>;
...
};
...@@ -129,6 +129,9 @@ Boards: ...@@ -129,6 +129,9 @@ Boards:
- AM437x GP EVM - AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43" compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
- AM437x SK EVM: AM437x StarterKit Evaluation Module
compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
- DRA742 EVM: Software Development Board for DRA742 - DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
......
OMAP PRCM bindings
Power Reset and Clock Manager lists the device clocks and clockdomains under
a DT hierarchy. Each TI SoC can have multiple PRCM entities listed for it,
each describing one module and the clock hierarchy under it. see [1] for
documentation about the individual clock/clockdomain nodes.
[1] Documentation/devicetree/bindings/clock/ti/*
Required properties:
- compatible: Must be one of:
"ti,am3-prcm"
"ti,am3-scrm"
"ti,am4-prcm"
"ti,am4-scrm"
"ti,omap2-prcm"
"ti,omap2-scrm"
"ti,omap3-prm"
"ti,omap3-cm"
"ti,omap3-scrm"
"ti,omap4-cm1"
"ti,omap4-prm"
"ti,omap4-cm2"
"ti,omap4-scrm"
"ti,omap5-prm"
"ti,omap5-cm-core-aon"
"ti,omap5-scrm"
"ti,omap5-cm-core"
"ti,dra7-prm"
"ti,dra7-cm-core-aon"
"ti,dra7-cm-core"
- reg: Contains PRCM module register address range
(base address and length)
- clocks: clocks for this module
- clockdomains: clockdomains for this module
Example:
cm: cm@48004000 {
compatible = "ti,omap3-cm";
reg = <0x48004000 0x4000>;
cm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
};
cm_clockdomains: clockdomains {
};
}
&cm_clocks {
omap2_32k_fck: omap_32k_fck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
};
};
&cm_clockdomains {
core_l3_clkdm: core_l3_clkdm {
compatible = "ti,clockdomain";
clocks = <&sdrc_ick>;
};
};
...@@ -14,14 +14,21 @@ Required properties: ...@@ -14,14 +14,21 @@ Required properties:
for exynos4412/5250 controllers. for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for Must be "samsung,exynos-adc-v2" for
future controllers. future controllers.
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
- reg: Contains ADC register address range (base address and - reg: Contains ADC register address range (base address and
length) and the address of the phy enable register. length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The - interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller format is being dependent on which interrupt controller
the Samsung device uses. the Samsung device uses.
- #io-channel-cells = <1>; As ADC has multiple outputs - #io-channel-cells = <1>; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock. - clocks From common clock bindings: handles to clocks specified
- clock-names From common clock binding: Shall be "adc". in "clock-names" property, in the same order.
- clock-names From common clock bindings: list of clock input names
used by ADC block:
- "adc" : ADC bus clock
- "sclk" : ADC special clock (only for Exynos3250 and
compatible ADC block)
- vdd-supply VDD input supply. - vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree. Note: child nodes can be added for auto probing from device tree.
...@@ -41,6 +48,20 @@ adc: adc@12D10000 { ...@@ -41,6 +48,20 @@ adc: adc@12D10000 {
vdd-supply = <&buck5_reg>; vdd-supply = <&buck5_reg>;
}; };
Example: adding device info in dtsi file for Exynos3250 with additional sclk
adc: adc@126C0000 {
compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
#io-channel-cells = <1>;
io-channel-ranges;
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
clock-names = "adc", "sclk";
vdd-supply = <&buck5_reg>;
};
Example: Adding child nodes in dts file Example: Adding child nodes in dts file
......
...@@ -7,6 +7,8 @@ Properties: ...@@ -7,6 +7,8 @@ Properties:
- "samsung,exynos4212-pmu" - for Exynos4212 SoC, - "samsung,exynos4212-pmu" - for Exynos4212 SoC,
- "samsung,exynos4412-pmu" - for Exynos4412 SoC, - "samsung,exynos4412-pmu" - for Exynos4412 SoC,
- "samsung,exynos5250-pmu" - for Exynos5250 SoC, - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC. - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
second value must be always "syscon". second value must be always "syscon".
......
SPEAr Misc configuration
===========================
SPEAr SOCs have some miscellaneous registers which are used to configure
few properties of different peripheral controllers.
misc node required properties:
- compatible Should be "st,spear1340-misc", "syscon".
- reg: Address range of misc space upto 8K
...@@ -30,6 +30,8 @@ board-specific compatible values: ...@@ -30,6 +30,8 @@ board-specific compatible values:
nvidia,seaboard nvidia,seaboard
nvidia,ventana nvidia,ventana
nvidia,whistler nvidia,whistler
toradex,apalis_t30
toradex,apalis_t30-eval
toradex,colibri_t20-512 toradex,colibri_t20-512
toradex,iris toradex,iris
......
Xilinx Zynq EP107 Emulation Platform board Xilinx Zynq Platforms Device Tree Bindings
This board is an emulation platform for the Zynq product which is Boards with Zynq-7000 SOC based on an ARM Cortex A9 processor
based on an ARM Cortex A9 processor. shall have the following properties.
Required root node properties: Required root node properties:
- compatible = "xlnx,zynq-ep107"; - compatible = "xlnx,zynq-7000";
Clock bindings for ARM Integrator Core Module clocks Clock bindings for ARM Integrator and Versatile Core Module clocks
Auxilary Oscillator Clock Auxilary Oscillator Clock
...@@ -12,7 +12,7 @@ parent node. ...@@ -12,7 +12,7 @@ parent node.
Required properties: Required properties:
- compatible: must be "arm,integrator-cm-auxosc" - compatible: must be "arm,integrator-cm-auxosc" or "arm,versatile-cm-auxosc"
- #clock-cells: must be <0> - #clock-cells: must be <0>
Optional properties: Optional properties:
......
* Samsung Audio Subsystem Clock Controller
The Samsung Audio Subsystem clock controller generates and supplies clocks
to Audio Subsystem block available in the S5PV210 and compatible SoCs.
Required Properties:
- compatible: should be "samsung,s5pv210-audss-clock".
- reg: physical base address and length of the controller's register set.
- #clock-cells: should be 1.
- clocks:
- hclk: AHB bus clock of the Audio Subsystem.
- xxti: Optional fixed rate PLL reference clock, parent of mout_audss. If
not specified (i.e. xusbxti is used for PLL reference), it is fixed to
a clock named "xxti".
- fout_epll: Input PLL to the AudioSS block, parent of mout_audss.
- iiscdclk0: Optional external i2s clock, parent of mout_i2s. If not
specified, it is fixed to a clock named "iiscdclk0".
- sclk_audio0: Audio bus clock, parent of mout_i2s.
- clock-names: Aliases for the above clocks. They should be "hclk",
"xxti", "fout_epll", "iiscdclk0", and "sclk_audio0" respectively.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/s5pv210-audss-clk.h header and can be used in device
tree sources.
Example: Clock controller node.
clk_audss: clock-controller@c0900000 {
compatible = "samsung,s5pv210-audss-clock";
reg = <0xc0900000 0x1000>;
#clock-cells = <1>;
clock-names = "hclk", "xxti",
"fout_epll", "sclk_audio0";
clocks = <&clocks DOUT_HCLKP>, <&xxti>,
<&clocks FOUT_EPLL>, <&clocks SCLK_AUDIO0>;
};
Example: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
i2s0: i2s@03830000 {
/* ... */
clock-names = "iis", "i2s_opclk0",
"i2s_opclk1";
clocks = <&clk_audss CLK_I2S>, <&clk_audss CLK_I2S>,
<&clk_audss CLK_DOUT_AUD_BUS>;
/* ... */
};
* Clock bindings for Freescale i.MX1 CPUs
Required properties:
- compatible: Should be "fsl,imx1-ccm".
- reg: Address and length of the register set.
- #clock-cells: Should be <1>.
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h
for the full list of i.MX1 clock IDs.
Examples:
clks: ccm@0021b000 {
#clock-cells = <1>;
compatible = "fsl,imx1-ccm";
reg = <0x0021b000 0x1000>;
};
pwm: pwm@00208000 {
#pwm-cells = <2>;
compatible = "fsl,imx1-pwm";
reg = <0x00208000 0x1000>;
interrupts = <34>;
clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>;
clock-names = "ipg", "per";
};
* Clock bindings for Freescale i.MX21
Required properties:
- compatible : Should be "fsl,imx21-ccm".
- reg : Address and length of the register set.
- interrupts : Should contain CCM interrupt.
- #clock-cells: Should be <1>.
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h
for the full list of i.MX21 clock IDs.
Examples:
clks: ccm@10027000{
compatible = "fsl,imx21-ccm";
reg = <0x10027000 0x800>;
#clock-cells = <1>;
};
uart1: serial@1000a000 {
compatible = "fsl,imx21-uart";
reg = <0x1000a000 0x1000>;
interrupts = <20>;
clocks = <&clks IMX21_CLK_UART1_IPG_GATE>,
<&clks IMX21_CLK_PER1>;
clock-names = "ipg", "per";
status = "disabled";
};
...@@ -7,117 +7,22 @@ Required properties: ...@@ -7,117 +7,22 @@ Required properties:
- #clock-cells: Should be <1> - #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. The following is a full list of i.MX27 ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h
clocks and IDs. for the full list of i.MX27 clock IDs.
Clock ID
-----------------------
dummy 0
ckih 1
ckil 2
mpll 3
spll 4
mpll_main2 5
ahb 6
ipg 7
nfc_div 8
per1_div 9
per2_div 10
per3_div 11
per4_div 12
vpu_sel 13
vpu_div 14
usb_div 15
cpu_sel 16
clko_sel 17
cpu_div 18
clko_div 19
ssi1_sel 20
ssi2_sel 21
ssi1_div 22
ssi2_div 23
clko_en 24
ssi2_ipg_gate 25
ssi1_ipg_gate 26
slcdc_ipg_gate 27
sdhc3_ipg_gate 28
sdhc2_ipg_gate 29
sdhc1_ipg_gate 30
scc_ipg_gate 31
sahara_ipg_gate 32
rtc_ipg_gate 33
pwm_ipg_gate 34
owire_ipg_gate 35
lcdc_ipg_gate 36
kpp_ipg_gate 37
iim_ipg_gate 38
i2c2_ipg_gate 39
i2c1_ipg_gate 40
gpt6_ipg_gate 41
gpt5_ipg_gate 42
gpt4_ipg_gate 43
gpt3_ipg_gate 44
gpt2_ipg_gate 45
gpt1_ipg_gate 46
gpio_ipg_gate 47
fec_ipg_gate 48
emma_ipg_gate 49
dma_ipg_gate 50
cspi3_ipg_gate 51
cspi2_ipg_gate 52
cspi1_ipg_gate 53
nfc_baud_gate 54
ssi2_baud_gate 55
ssi1_baud_gate 56
vpu_baud_gate 57
per4_gate 58
per3_gate 59
per2_gate 60
per1_gate 61
usb_ahb_gate 62
slcdc_ahb_gate 63
sahara_ahb_gate 64
lcdc_ahb_gate 65
vpu_ahb_gate 66
fec_ahb_gate 67
emma_ahb_gate 68
emi_ahb_gate 69
dma_ahb_gate 70
csi_ahb_gate 71
brom_ahb_gate 72
ata_ahb_gate 73
wdog_ipg_gate 74
usb_ipg_gate 75
uart6_ipg_gate 76
uart5_ipg_gate 77
uart4_ipg_gate 78
uart3_ipg_gate 79
uart2_ipg_gate 80
uart1_ipg_gate 81
ckih_div1p5 82
fpm 83
mpll_osc_sel 84
mpll_sel 85
spll_gate 86
mshc_div 87
rtic_ipg_gate 88
mshc_ipg_gate 89
rtic_ahb_gate 90
mshc_baud_gate 91
Examples: Examples:
clks: ccm@10027000{
compatible = "fsl,imx27-ccm";
reg = <0x10027000 0x1000>;
#clock-cells = <1>;
};
clks: ccm@10027000{ uart1: serial@1000a000 {
compatible = "fsl,imx27-ccm"; compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x10027000 0x1000>; reg = <0x1000a000 0x1000>;
#clock-cells = <1>; interrupts = <20>;
}; clocks = <&clks IMX27_CLK_UART1_IPG_GATE>,
<&clks IMX27_CLK_PER1_GATE>;
uart1: serial@1000a000 { clock-names = "ipg", "per";
compatible = "fsl,imx27-uart", "fsl,imx21-uart"; status = "disabled";
reg = <0x1000a000 0x1000>; };
interrupts = <20>;
clocks = <&clks 81>, <&clks 61>;
clock-names = "ipg", "per";
status = "disabled";
};
...@@ -3,14 +3,15 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms ...@@ -3,14 +3,15 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
Required properties: Required properties:
- compatible : shall be one of the following: - compatible : shall be one of the following:
"marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
- reg : Address and length of the clock complex register set - reg : Address and length of the clock complex register set, followed
by address and length of the PMU DFS registers
- #clock-cells : should be set to 1. - #clock-cells : should be set to 1.
- clocks : shall be the input parent clock phandle for the clock. - clocks : shall be the input parent clock phandle for the clock.
cpuclk: clock-complex@d0018700 { cpuclk: clock-complex@d0018700 {
#clock-cells = <1>; #clock-cells = <1>;
compatible = "marvell,armada-xp-cpu-clock"; compatible = "marvell,armada-xp-cpu-clock";
reg = <0xd0018700 0xA0>; reg = <0xd0018700 0xA0>, <0x1c054 0x10>;
clocks = <&coreclk 1>; clocks = <&coreclk 1>;
} }
......
* Samsung S5P6442/S5PC110/S5PV210 Clock Controller
Samsung S5P6442, S5PC110 and S5PV210 SoCs contain integrated clock
controller, which generates and supplies clock to various controllers
within the SoC.
Required Properties:
- compatible: should be one of following:
- "samsung,s5pv210-clock" : for clock controller of Samsung
S5PC110/S5PV210 SoCs,
- "samsung,s5p6442-clock" : for clock controller of Samsung
S5P6442 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/s5pv210.h header and can be used in device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xxti": external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti": external crystal oscillator connected to XUSBXTI and XUSBXTO
pins of the SoC,
A subset of above clocks available on given board shall be specified in
board device tree, including the system base clock, as selected by XOM[0]
pin of the SoC. Refer to generic fixed rate clock bindings
documentation[1] for more information how to specify these clocks.
[1] Documentation/devicetree/bindings/clock/fixed-clock.txt
Example: Clock controller node:
clock: clock-controller@7e00f000 {
compatible = "samsung,s5pv210-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
};
Example: Required external clocks:
xxti: clock-xxti {
compatible = "fixed-clock";
clock-output-names = "xxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
xusbxti: clock-xusbxti {
compatible = "fixed-clock";
clock-output-names = "xusbxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
Example: UART controller node that consumes the clock generated by the clock
controller (refer to the standard clock bindings for information about
"clocks" and "clock-names" properties):
uart0: serial@e2900000 {
compatible = "samsung,s5pv210-uart";
reg = <0xe2900000 0x400>;
interrupt-parent = <&vic1>;
interrupts = <10>;
clock-names = "uart", "clk_uart_baud0",
"clk_uart_baud1";
clocks = <&clocks UART0>, <&clocks UART0>,
<&clocks SCLK_UART0>;
status = "disabled";
};
...@@ -47,6 +47,7 @@ The full ID of peripheral types can be found below. ...@@ -47,6 +47,7 @@ The full ID of peripheral types can be found below.
20 ASRC 20 ASRC
21 ESAI 21 ESAI
22 SSI Dual FIFO (needs firmware ver >= 2) 22 SSI Dual FIFO (needs firmware ver >= 2)
23 Shared ASRC
The third cell specifies the transfer priority as below. The third cell specifies the transfer priority as below.
......
* Freescale MPC512x and MPC8308 DMA Controller
The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
blocks of memory contents between memory and peripherals or
from memory to memory.
Refer to "Generic DMA Controller and DMA request bindings" in
the dma/dma.txt file for a more detailed description of binding.
Required properties:
- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma";
- reg: should contain the DMA controller registers location and length;
- interrupt for the DMA controller: syntax of interrupt client node
is described in interrupt-controller/interrupts.txt file.
- #dma-cells: the length of the DMA specifier, must be <1>.
Each channel of this DMA controller has a peripheral request line,
the assignment is fixed in hardware. This one cell
in dmas property of a client device represents the channel number.
Example:
dma0: dma@14000 {
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
#dma-cells = <1>;
};
DMA clients must use the format described in dma/dma.txt file.
* Renesas "Type-AXI" NBPFAXI* DMA controllers
* DMA controller
Required properties
- compatible: must be one of
"renesas,nbpfaxi64dmac1b4"
"renesas,nbpfaxi64dmac1b8"
"renesas,nbpfaxi64dmac1b16"
"renesas,nbpfaxi64dmac4b4"
"renesas,nbpfaxi64dmac4b8"
"renesas,nbpfaxi64dmac4b16"
"renesas,nbpfaxi64dmac8b4"
"renesas,nbpfaxi64dmac8b8"
"renesas,nbpfaxi64dmac8b16"
- #dma-cells: must be 2: the first integer is a terminal number, to which this
slave is connected, the second one is flags. Flags is a bitmask
with the following bits defined:
#define NBPF_SLAVE_RQ_HIGH 1
#define NBPF_SLAVE_RQ_LOW 2
#define NBPF_SLAVE_RQ_LEVEL 4
Optional properties:
You can use dma-channels and dma-requests as described in dma.txt, although they
won't be used, this information is derived from the compatibility string.
Example:
dma: dma-controller@48000000 {
compatible = "renesas,nbpfaxi64dmac8b4";
reg = <0x48000000 0x400>;
interrupts = <0 12 0x4
0 13 0x4
0 14 0x4
0 15 0x4
0 16 0x4
0 17 0x4
0 18 0x4
0 19 0x4>;
#dma-cells = <2>;
dma-channels = <8>;
dma-requests = <8>;
};
* DMA client
Required properties:
dmas and dma-names are required, as described in dma.txt.
Example:
#include <dt-bindings/dma/nbpfaxi.h>
...
dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)
&dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>;
dma-names = "rx", "tx";
此差异已折叠。
此差异已折叠。
...@@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter ...@@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter
Required properties; Required properties;
- compatible: must be "nxp,tda998x" - compatible: must be "nxp,tda998x"
- reg: I2C address
Optional properties: Optional properties:
- interrupts: interrupt number and trigger type - interrupts: interrupt number and trigger type
default: polling default: polling
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册