Merge branch 'master' into for-next

Sync with Linus' tree so that patches against newer codebase can be applied.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
Jiri Kosina 2016-04-18 11:18:55 +02:00
commit 9938b04472
17915 changed files with 1320089 additions and 707228 deletions
.mailmapCREDITS
Documentation
ABI
CodingStyleDMA-API-HOWTO.txtDMA-API.txtDMA-attributes.txt
DocBook
HOWTOIPMI.txtIntel-IOMMU.txtMakefile
RCU/Design
SubmittingPatches
accounting
acpi
arm

View file

@ -21,6 +21,7 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
Andrew Morton <akpm@linux-foundation.org>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andy Adamson <andros@citi.umich.edu>
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
Archit Taneja <archit@ti.com>
Arnaud Patard <arnaud.patard@rtp-net.org>
Arnd Bergmann <arnd@arndb.de>
@ -32,6 +33,7 @@ Björn Steinbrink <B.Steinbrink@gmx.de>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Christoph Hellwig <hch@lst.de>
Christophe Ricard <christophe.ricard@gmail.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
David Brownell <david-b@pacbell.net>

20
CREDITS
View file

@ -534,6 +534,7 @@ N: NeilBrown
E: neil@brown.name
P: 4096R/566281B9 1BC6 29EB D390 D870 7B5F 497A 39EC 9EDD 5662 81B9
D: NFSD Maintainer 2000-2007
D: MD Maintainer 2001-2016
N: Zach Brown
E: zab@zabbo.net
@ -1507,6 +1508,14 @@ S: 312/107 Canberra Avenue
S: Griffith, ACT 2603
S: Australia
N: Andreas Herrmann
E: herrmann.der.user@gmail.com
E: herrmann.der.user@googlemail.com
D: Key developer of x86/AMD64
D: Author of AMD family 15h processor power monitoring driver
D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver
S: Germany
N: Sebastian Hetze
E: she@lunetix.de
D: German Linux Documentation,
@ -1847,6 +1856,16 @@ S: Korte Heul 95
S: 1403 ND BUSSUM
S: The Netherlands
N: Martin Kepplinger
E: martink@posteo.de
E: martin.kepplinger@theobroma-systems.com
W: http://www.martinkepplinger.com
D: mma8452 accelerators iio driver
D: Kernel cleanups
S: Garnisonstraße 26
S: 4020 Linz
S: Austria
N: Karl Keyte
E: karl@koft.com
D: Disk usage statistics and modifications to line printer driver
@ -3035,6 +3054,7 @@ D: PLX USB338x driver
D: PCA9634 driver
D: Option GTM671WFS
D: Fintek F81216A
D: AD5761 iio driver
D: Various kernel hacks
S: Qtechnology A/S
S: Valby Langgade 142

View file

@ -1,29 +0,0 @@
rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file is deprecated and scheduled to be removed in 2014,
because its not possible to express the 'soft and hard block'
state of the rfkill driver.
Values: A numeric value.
0: RFKILL_STATE_SOFT_BLOCKED
transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
the driver's control.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file is deprecated because there no longer is a way to
claim just control over a single rfkill instance.
This file is scheduled to be removed in 2012.
Values: 0: Kernel handles events

View file

@ -1,7 +1,7 @@
What: /sys/class/gpio/
Date: July 2008
KernelVersion: 2.6.27
Contact: David Brownell <dbrownell@users.sourceforge.net>
Contact: Linus Walleij <linusw@kernel.org>
Description:
As a Kconfig option, individual GPIO signals may be accessed from
@ -26,3 +26,5 @@ Description:
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
This ABI is deprecated and will be removed after 2020. It is
replaced with the GPIO character device.

View file

@ -0,0 +1,13 @@
rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file was deprecated because there no longer was a way to
claim just control over a single rfkill instance.
This file was scheduled to be removed in 2012, and was removed
in 2016.
Values: 0: Kernel handles events

View file

@ -100,4 +100,5 @@ Description:
Users: libraw1394
libdc1394
tools like jujuutils, fwhack, ...
libhinawa
tools like linux-firewire-utils, fwhack, ...

View file

@ -27,3 +27,17 @@ Description: The mapping of which primary/sub channels are bound to which
Virtual Processors.
Format: <channel's child_relid:the bound cpu's number>
Users: tools/hv/lsvmbus
What: /sys/bus/vmbus/devices/vmbus_*/device
Date: Dec. 2015
KernelVersion: 4.5
Contact: K. Y. Srinivasan <kys@microsoft.com>
Description: The 16 bit device ID of the device
Users: tools/hv/lsvmbus and user level RDMA libraries
What: /sys/bus/vmbus/devices/vmbus_*/vendor
Date: Dec. 2015
KernelVersion: 4.5
Contact: K. Y. Srinivasan <kys@microsoft.com>
Description: The 16 bit vendor ID of the device
Users: tools/hv/lsvmbus and user level RDMA libraries

View file

@ -2,9 +2,8 @@ rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
For the deprecated /sys/class/rfkill/*/state and
/sys/class/rfkill/*/claim knobs of this interface look in
Documentation/ABI/obsolete/sysfs-class-rfkill.
For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
Documentation/ABI/removed/sysfs-class-rfkill.
What: /sys/class/rfkill
Date: 09-Jul-2007
@ -42,6 +41,28 @@ Values: A numeric value.
1: true
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file was scheduled to be removed in 2014, but due to its
large number of users it will be sticking around for a bit
longer. Despite it being marked as stabe, the newer "hard" and
"soft" interfaces should be preffered, since it is not possible
to express the 'soft and hard block' state of the rfkill driver
through this interface. There will likely be another attempt to
remove it in the future.
Values: A numeric value.
0: RFKILL_STATE_SOFT_BLOCKED
transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
the driver's control.
What: /sys/class/rfkill/rfkill[0-9]+/hard
Date: 12-March-2010
KernelVersion v2.6.34

View file

@ -0,0 +1,87 @@
What: /sys/fs/orangefs/perf_counters/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Counters and settings for various caches.
Read only.
What: /sys/fs/orangefs/perf_counter_reset
Date: June 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
echo a 0 or a 1 into perf_counter_reset to
reset all the counters in
/sys/fs/orangefs/perf_counters
except ones with PINT_PERF_PRESERVE set.
What: /sys/fs/orangefs/perf_time_interval_secs
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Length of perf counter intervals in
seconds.
What: /sys/fs/orangefs/perf_history_size
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
The perf_counters cache statistics have N, or
perf_history_size, samples. The default is
one.
Every perf_time_interval_secs the (first)
samples are reset.
If N is greater than one, the "current" set
of samples is reset, and the samples from the
other N-1 intervals remain available.
What: /sys/fs/orangefs/op_timeout_secs
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Service operation timeout in seconds.
What: /sys/fs/orangefs/slot_timeout_secs
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
"Slot" timeout in seconds. A "slot"
is an indexed buffer in the shared
memory segment used for communication
between the kernel module and userspace.
Slots are requested and waited for,
the wait times out after slot_timeout_secs.
What: /sys/fs/orangefs/acache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Attribute cache configurable settings.
What: /sys/fs/orangefs/ncache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Name cache configurable settings.
What: /sys/fs/orangefs/capcache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Capability cache configurable settings.
What: /sys/fs/orangefs/ccache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Credential cache configurable settings.

View file

@ -0,0 +1,21 @@
What: /config/iio
Date: October 2015
KernelVersion: 4.4
Contact: linux-iio@vger.kernel.org
Description:
This represents Industrial IO configuration entry point
directory. It contains sub-groups corresponding to IIO
objects.
What: /config/iio/triggers
Date: October 2015
KernelVersion: 4.4
Description:
Industrial IO software triggers directory.
What: /config/iio/triggers/hrtimers
Date: October 2015
KernelVersion: 4.4
Description:
High resolution timers directory. Creating a directory here
will result in creating a hrtimer trigger in the IIO subsystem.

View file

@ -0,0 +1,22 @@
What: /config/rdma_cm
Date: November 29, 2015
KernelVersion: 4.4.0
Description: Interface is used to configure RDMA-cable HCAs in respect to
RDMA-CM attributes.
Attributes are visible only when configfs is mounted. To mount
configfs in /config directory use:
# mount -t configfs none /config/
In order to set parameters related to a specific HCA, a directory
for this HCA has to be created:
mkdir -p /config/rdma_cm/<hca>
What: /config/rdma_cm/<hca>/ports/<port-num>/default_roce_mode
Date: November 29, 2015
KernelVersion: 4.4.0
Description: RDMA-CM based connections from HCA <hca> at port <port-num>
will be initiated with this RoCE type as default.
The possible RoCE types are either "IB/RoCE v1" or "RoCE v2".
This parameter has RW access.

View file

@ -10,3 +10,5 @@ Description:
isoc_mult - 0..2 (hs/ss only)
isoc_maxburst - 0..15 (ss only)
buflen - buffer length
bulk_qlen - depth of queue for bulk
iso_qlen - depth of queue for iso

View file

@ -0,0 +1,6 @@
What: /config/usb-gadget/gadget/functions/tcm.name
Date: Dec 2015
KernelVersion: 4.5
Description:
There are no attributes because all the configuration
is performed in the "target" subsystem of configfs.

View file

@ -0,0 +1,26 @@
What: /dev/gpiochip[0-9]+
Date: November 2015
KernelVersion: 4.4
Contact: linux-gpio@vger.kernel.org
Description:
The character device files /dev/gpiochip* are the interface
between GPIO chips and userspace.
The ioctl(2)-based ABI is defined and documented in
[include/uapi]<linux/gpio.h>.
The following file operations are supported:
open(2)
Currently the only useful flags are O_RDWR.
ioctl(2)
Initiate various actions.
See the inline documentation in [include/uapi]<linux/gpio.h>
for descriptions of all ioctls.
close(2)
Stops and free up the I/O contexts that was associated
with the file descriptor.
Users: TBD

View file

@ -27,6 +27,7 @@ Description:
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
[[^]MAY_EXEC]
fsmagic:= hex value

View file

@ -496,8 +496,11 @@ Description:
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
90kohm_to_gnd: connected to ground via a 90kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
125kohm_to_gnd: connected to ground via an 125kOhm resistor,
500kohm_to_gnd: connected to ground via a 500kOhm resistor,
640kohm_to_gnd: connected to ground via a 640kOhm resistor,
three_state: left floating.
For a list of available output power down options read
outX_powerdown_mode_available. If Y is not present the
@ -1491,3 +1494,10 @@ Description:
This ABI is especially applicable for humidity sensors
to heatup the device and get rid of any condensation
in some humidity environment
What: /sys/bus/iio/devices/iio:deviceX/in_ph_raw
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) pH reading of a substance as a negative
base-10 logarithm of hydrodium ions in a litre of water.

View file

@ -0,0 +1,54 @@
What: /sys/bus/iio/devices/iio:deviceX/tia_resistanceY
/sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the resistance and the capacitance settings for the
Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
Rf2 and Cf2 values.
What: /sys/bus/iio/devices/iio:deviceX/tia_separate_en
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Enable or disable separate settings for the TransImpedance
Amplifier above, when disabled both values are set by the
first channel.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get measured values from the ADC for these stages. Y is the
specific LED number. The values are expressed in 24-bit twos
complement.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get differential values from the ADC for these stages. Y is the
specific LED number. The values are expressed in 24-bit twos
complement for the specified LEDs.
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_offset
/sys/bus/iio/devices/iio:deviceX/out_current_ledY_ambient_offset
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the offset cancellation DAC setting for these
stages. The values are expressed in 5-bit sign-magnitude.
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the LED current for the specified LED. Y is the
specific LED number.

View file

@ -0,0 +1,24 @@
What: /sys/bus/iio/devices/iio:deviceX/in_allow_async_readout
Date: December 2015
KernelVersion: 4.4
Contact: linux-iio@vger.kernel.org
Description:
By default (value '0'), the capture thread checks for the Conversion
Ready Flag to being set prior to committing a new value to the sample
buffer. This synchronizes the in-chip conversion rate with the
in-driver readout rate at the cost of an additional register read.
Writing '1' will remove the polling for the Conversion Ready Flags to
save the additional i2c transaction, which will improve the bandwidth
available for reading data. However, samples can be occasionally skipped
or repeated, depending on the beat between the capture and conversion
rates.
What: /sys/bus/iio/devices/iio:deviceX/in_shunt_resistor
Date: December 2015
KernelVersion: 4.4
Contact: linux-iio@vger.kernel.org
Description:
The value of the shunt resistor may be known only at runtime fom an
eeprom content read by a client application. This attribute allows to
set its value in ohms.

View file

@ -0,0 +1,15 @@
What: /sys/bus/iio/devices/iio:deviceX/meas_conf
What: /sys/bus/iio/devices/iio:deviceX/meas_conf_available
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
Current configuration and available configurations
for the bias current.
normal - Normal measurement configurations (default)
positivebias - Positive bias configuration
negativebias - Negative bias configuration
disabled - Only available on HMC5983. Disables magnetic
sensor and enables temperature sensor.
Note: The effect of this configuration may vary
according to the device. For exact documentation
check the device's datasheet.

View file

@ -5,3 +5,12 @@ Description:
Specifies the hardware conversion mode used. The three
available modes are "normal", "high-speed" and "low-power",
where the last is the default mode.
What: /sys/bus/iio/devices/iio:deviceX/out_conversion_mode
KernelVersion: 4.6
Contact: linux-iio@vger.kernel.org
Description:
Specifies the hardware conversion mode used within DAC.
The two available modes are "high-power" and "low-power",
where "low-power" mode is the default mode.

View file

@ -134,19 +134,21 @@ Description:
enabled for the device. Developer can write y/Y/1 or n/N/0 to
the file to enable/disable the feature.
What: /sys/bus/usb/devices/.../power/usb3_hardware_lpm
Date: June 2015
What: /sys/bus/usb/devices/.../power/usb3_hardware_lpm_u1
/sys/bus/usb/devices/.../power/usb3_hardware_lpm_u2
Date: November 2015
Contact: Kevin Strasser <kevin.strasser@linux.intel.com>
Lu Baolu <baolu.lu@linux.intel.com>
Description:
If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
in to a xHCI host which supports link PM, it will check if U1
and U2 exit latencies have been set in the BOS descriptor; if
the check is is passed and the host supports USB3 hardware LPM,
the check is passed and the host supports USB3 hardware LPM,
USB3 hardware LPM will be enabled for the device and the USB
device directory will contain a file named
power/usb3_hardware_lpm. The file holds a string value (enable
or disable) indicating whether or not USB3 hardware LPM is
enabled for the device.
device directory will contain two files named
power/usb3_hardware_lpm_u1 and power/usb3_hardware_lpm_u2. These
files hold a string value (enable or disable) indicating whether
or not USB3 hardware LPM U1 or U2 is enabled for the device.
What: /sys/bus/usb/devices/.../removable
Date: February 2012
@ -187,6 +189,17 @@ Description:
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.
What: /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit
Date: November 2015
Contact: Lu Baolu <baolu.lu@linux.intel.com>
Description:
Some USB3.0 devices are not friendly to USB3 LPM. usb3_lpm_permit
attribute allows enabling/disabling usb3 lpm of a port. It takes
effect both before and after a usb device is enumerated. Supported
values are "0" if both u1 and u2 are NOT permitted, "u1" if only u1
is permitted, "u2" if only u2 is permitted, "u1_u2" if both u1 and
u2 are permitted.
What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
Date: May 2013
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>

View file

@ -159,7 +159,7 @@ Description: read only
Decimal value of the Per Process MMIO space length.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_off
What: /sys/class/cxl/<afu>m/pp_mmio_off (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -183,7 +183,7 @@ Description: read only
Identifies the revision level of the PSL.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/base_image
What: /sys/class/cxl/<card>/base_image (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -193,7 +193,7 @@ Description: read only
during the initial program load.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/image_loaded
What: /sys/class/cxl/<card>/image_loaded (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -201,7 +201,7 @@ Description: read only
onto the card.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/load_image_on_perst
What: /sys/class/cxl/<card>/load_image_on_perst (not in a guest)
Date: December 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
@ -224,7 +224,7 @@ Description: write only
to reload the FPGA depending on load_image_on_perst.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/perst_reloads_same_image
What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest)
Date: July 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write

View file

@ -0,0 +1,16 @@
What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/ndevs/<gid-index>
Date: November 29, 2015
KernelVersion: 4.4.0
Contact: linux-rdma@vger.kernel.org
Description: The net-device's name associated with the GID resides
at index <gid-index>.
What: /sys/class/infiniband/<hca>/ports/<port-number>/gid_attrs/types/<gid-index>
Date: November 29, 2015
KernelVersion: 4.4.0
Contact: linux-rdma@vger.kernel.org
Description: The RoCE type of the associated GID resides at index <gid-index>.
This could either be "IB/RoCE v1" for IB and RoCE v1 based GODs
or "RoCE v2" for RoCE v2 based GIDs.

View file

@ -1,4 +1,20 @@
What: /sys/class/net/<iface>/batman-adv/throughput_override
Date: Feb 2014
Contact: Antonio Quartulli <antonio@meshcoding.com>
description:
Defines the throughput value to be used by B.A.T.M.A.N. V
when estimating the link throughput using this interface.
If the value is set to 0 then batman-adv will try to
estimate the throughput by itself.
What: /sys/class/net/<iface>/batman-adv/elp_interval
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the interval in milliseconds in which batman
sends its probing packets for link quality measurements.
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
@ -12,4 +28,3 @@ Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>
currently is associated with.

View file

@ -19,6 +19,25 @@ Description:
Set to 0 to pad all frames. Set greater than tx_max to
disable all padding.
What: /sys/class/net/<iface>/cdc_ncm/ndp_to_end
Date: Dec 2015
KernelVersion: 4.5
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Boolean attribute showing the status of the "NDP to
end" quirk. Defaults to 'N', except for devices
already known to need it enabled.
The "NDP to end" quirk makes the driver place the NDP
(the packet index table) after the payload. The NCM
specification does not mandate this, but some devices
are known to be more restrictive. Write 'Y' to this
attribute for temporary testing of a suspect device
failing to work with the default driver settings.
A device entry should be added to the driver if this
quirk is found to be required.
What: /sys/class/net/<iface>/cdc_ncm/rx_max
Date: May 2014
KernelVersion: 3.16

View file

@ -8,7 +8,7 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <antonio@meshcoding.com>
Contact: Antonio Quartulli <a@unstable.cc>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
@ -70,7 +70,7 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/isolation_mark
Date: Nov 2013
Contact: Antonio Quartulli <antonio@meshcoding.com>
Contact: Antonio Quartulli <a@unstable.cc>
Description:
Defines the isolation mark (and its bitmask) which
is used to classify clients as "isolated" by the

View file

@ -0,0 +1,23 @@
What: /sys/class/net/<iface>/qmi/raw_ip
Date: Dec 2015
KernelVersion: 4.4
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Boolean. Default: 'N'
Set this to 'Y' to change the network device link
framing from '802.3' to 'raw-ip'.
The netdev will change to reflect the link framing
mode. The netdev is an ordinary ethernet device in
'802.3' mode, and the driver expects to exchange
frames with an ethernet header over the USB link. The
netdev is a headerless p-t-p device in 'raw-ip' mode,
and the driver expects to echange IPv4 or IPv6 packets
without any L2 header over the USB link.
Userspace is in full control of firmware configuration
through the delegation of the QMI protocol. Userspace
is responsible for coordination of driver and firmware
link framing mode, changing this setting to 'Y' if the
firmware is configured for 'raw-ip' mode.

View file

@ -0,0 +1,15 @@
What: /sys/class/rc/rcN/wakeup_data
Date: Mar 2016
KernelVersion: 4.6
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns the stored CIR wakeup sequence.
It starts with a pulse, followed by a space, pulse etc.
All values are in microseconds.
The same format can be used to store a wakeup sequence
in the Nuvoton chip by writing to this file.
Note: Some systems reset the stored wakeup sequence to a
factory default on each boot. On such systems store the
wakeup sequence in a file and set it on boot using e.g.
a udev rule.

View file

@ -0,0 +1,51 @@
What: /sys/class/watchdog/watchdogn/bootstatus
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It contains status of the watchdog
device at boot. It is equivalent to WDIOC_GETBOOTSTATUS of
ioctl interface.
What: /sys/class/watchdog/watchdogn/identity
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It contains identity string of
watchdog device.
What: /sys/class/watchdog/watchdogn/nowayout
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. While reading, it gives '1' if that
device supports nowayout feature else, it gives '0'.
What: /sys/class/watchdog/watchdogn/state
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It gives active/inactive status of
watchdog device.
What: /sys/class/watchdog/watchdogn/status
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It contains watchdog device's
internal status bits. It is equivalent to WDIOC_GETSTATUS
of ioctl interface.
What: /sys/class/watchdog/watchdogn/timeleft
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It contains value of time left for
reset generation. It is equivalent to WDIOC_GETTIMELEFT of
ioctl interface.
What: /sys/class/watchdog/watchdogn/timeout
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It is read to know about current
value of timeout programmed.

View file

@ -271,3 +271,72 @@ Description: Parameters for the CPU cache attributes
- WriteBack: data is written only to the cache line and
the modified cache line is written to main
memory only when it is replaced
What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/unthrottle
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/powercap
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/supply_fault
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overcurrent
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
'cpuX/cpufreq/throttle_stats' directory contains the CPU frequency
throttle stat attributes for the chip. The throttle stats of a cpu
is common across all the cpus belonging to a chip. Below are the
throttle attributes exported in the 'throttle_stats' directory:
- turbo_stat : This file gives the total number of times the max
frequency is throttled to lower frequency in turbo (at and above
nominal frequency) range of frequencies.
- sub_turbo_stat : This file gives the total number of times the
max frequency is throttled to lower frequency in sub-turbo(below
nominal frequency) range of frequencies.
- unthrottle : This file gives the total number of times the max
frequency is unthrottled after being throttled.
- powercap : This file gives the total number of times the max
frequency is throttled due to 'Power Capping'.
- overtemp : This file gives the total number of times the max
frequency is throttled due to 'CPU Over Temperature'.
- supply_fault : This file gives the total number of times the
max frequency is throttled due to 'Power Supply Failure'.
- overcurrent : This file gives the total number of times the
max frequency is throttled due to 'Overcurrent'.
- occ_reset : This file gives the total number of times the max
frequency is throttled due to 'OCC Reset'.
The sysfs attributes representing different throttle reasons like
powercap, overtemp, supply_fault, overcurrent and occ_reset map to
the reasons provided by OCC firmware for throttling the frequency.
What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/turbo_stat
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/sub_turbo_stat
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/unthrottle
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/powercap
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overtemp
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/supply_fault
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overcurrent
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
'policyX/throttle_stats' directory and all the attributes are same as
the /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory and
attributes which give the frequency throttle information of the chip.

View file

@ -0,0 +1,12 @@
What: /sys/bus/scsi/drivers/st/debug_flag
Date: October 2015
Kernel Version: ?.?
Contact: shane.seymour@hpe.com
Description:
This file allows you to turn debug output from the st driver
off if you write a '0' to the file or on if you write a '1'.
Note that debug output requires that the module be compiled
with the #define DEBUG set to a non-zero value (this is the
default). If DEBUG is set to 0 then this file will not
appear in sysfs as its presence is conditional upon debug
output support being compiled into the module.

View file

@ -179,3 +179,19 @@ Description: This file controls the USB 3 functionality, valid values are:
Note that toggling this value requires a reboot for changes to
take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/cooling_method
Date: 2016
KernelVersion: 4.6
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the Cooling Method feature.
Reading this file prints two values, the first is the actual cooling method
and the second is the maximum cooling method supported.
When the maximum cooling method is ONE, valid values are:
* 0 -> Maximum Performance
* 1 -> Battery Optimized
When the maximum cooling method is TWO, valid values are:
* 0 -> Maximum Performance
* 1 -> Performance
* 2 -> Battery Optimized
Users: KToshiba

View file

@ -0,0 +1,100 @@
What: /sys/firmware/qemu_fw_cfg/
Date: August 2015
Contact: Gabriel Somlo <somlo@cmu.edu>
Description:
Several different architectures supported by QEMU (x86, arm,
sun4*, ppc/mac) are provisioned with a firmware configuration
(fw_cfg) device, originally intended as a way for the host to
provide configuration data to the guest firmware. Starting
with QEMU v2.4, arbitrary fw_cfg file entries may be specified
by the user on the command line, which makes fw_cfg additionally
useful as an out-of-band, asynchronous mechanism for providing
configuration data to the guest userspace.
The authoritative guest-side hardware interface documentation
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
in the QEMU source tree.
=== SysFS fw_cfg Interface ===
The fw_cfg sysfs interface described in this document is only
intended to display discoverable blobs (i.e., those registered
with the file directory), as there is no way to determine the
presence or size of "legacy" blobs (with selector keys between
0x0002 and 0x0018) programmatically.
All fw_cfg information is shown under:
/sys/firmware/qemu_fw_cfg/
The only legacy blob displayed is the fw_cfg device revision:
/sys/firmware/qemu_fw_cfg/rev
--- Discoverable fw_cfg blobs by selector key ---
All discoverable blobs listed in the fw_cfg file directory are
displayed as entries named after their unique selector key
value, e.g.:
/sys/firmware/qemu_fw_cfg/by_key/32
/sys/firmware/qemu_fw_cfg/by_key/33
/sys/firmware/qemu_fw_cfg/by_key/34
...
Each such fw_cfg sysfs entry has the following values exported
as attributes:
name : The 56-byte nul-terminated ASCII string used as the
blob's 'file name' in the fw_cfg directory.
size : The length of the blob, as given in the fw_cfg
directory.
key : The value of the blob's selector key as given in the
fw_cfg directory. This value is the same as used in
the parent directory name.
raw : The raw bytes of the blob, obtained by selecting the
entry via the control register, and reading a number
of bytes equal to the blob size from the data
register.
--- Listing fw_cfg blobs by file name ---
While the fw_cfg device does not impose any specific naming
convention on the blobs registered in the file directory,
QEMU developers have traditionally used path name semantics
to give each blob a descriptive name. For example:
"bootorder"
"genroms/kvmvapic.bin"
"etc/e820"
"etc/boot-fail-wait"
"etc/system-states"
"etc/table-loader"
"etc/acpi/rsdp"
"etc/acpi/tables"
"etc/smbios/smbios-tables"
"etc/smbios/smbios-anchor"
...
In addition to the listing by unique selector key described
above, the fw_cfg sysfs driver also attempts to build a tree
of directories matching the path name components of fw_cfg
blob names, ending in symlinks to the by_key entry for each
"basename", as illustrated below (assume current directory is
/sys/firmware):
qemu_fw_cfg/by_name/bootorder -> ../by_key/38
qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
...
Construction of the directory tree and symlinks is done on a
"best-effort" basis, as there is no guarantee that components
of fw_cfg blob names are always "well behaved". I.e., there is
the possibility that a symlink (basename) will conflict with
a dirname component of another fw_cfg blob, in which case the
creation of the offending /sys/firmware/qemu_fw_cfg/by_name
entry will be skipped.
The authoritative list of entries will continue to be found
under the /sys/firmware/qemu_fw_cfg/by_key directory.

View file

@ -87,8 +87,28 @@ Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the checkpoint timing.
What: /sys/fs/f2fs/<disk>/idle_interval
Date: January 2016
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the idle timing.
What: /sys/fs/f2fs/<disk>/ra_nid_pages
Date: October 2015
Contact: "Chao Yu" <chao2.yu@samsung.com>
Description:
Controls the count of nid pages to be readaheaded.
What: /sys/fs/f2fs/<disk>/dirty_nats_ratio
Date: January 2016
Contact: "Chao Yu" <chao2.yu@samsung.com>
Description:
Controls dirty nat entries ratio threshold, if current
ratio exceeds configured threshold, checkpoint will
be triggered for flushing dirty nat entries.
What: /sys/fs/f2fs/<disk>/lifetime_write_kbytes
Date: January 2016
Contact: "Shuoran Liu" <liushuoran@huawei.com>
Description:
Shows total written kbytes issued to disk.

View file

@ -33,7 +33,7 @@ Description:
The object directory contains subdirectories for each function
that is patched within the object.
What: /sys/kernel/livepatch/<patch>/<object>/<function>
What: /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
Date: Nov 2014
KernelVersion: 3.19.0
Contact: live-patching@vger.kernel.org
@ -41,4 +41,8 @@ Description:
The function directory contains attributes regarding the
properties and state of the patched function.
The directory name contains the patched function name and a
sympos number corresponding to the nth occurrence of the symbol
name in kallsyms for the patched object.
There are currently no such attributes.

View file

@ -0,0 +1,97 @@
What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains either 0 or 1 and indicates if the DMA channel is a
low priority (0) or high priority (1) channel.
What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains 0..15 and indicates the weight of the channel among
equal priority channels during round robin scheduling.
What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains the platform specific cycle value to wait after a
reset command is issued. If the value is chosen too short,
then the HW will issue a reset failure interrupt. The value
is platform specific and should not be changed without
consultance.
What: /sys/devices/platform/hidma-mgmt*/dma_channels
/sys/devices/platform/QCOM8060:*/dma_channels
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains the number of dma channels supported by one instance
of HIDMA hardware. The value may change from chip to chip.
What: /sys/devices/platform/hidma-mgmt*/hw_version_major
/sys/devices/platform/QCOM8060:*/hw_version_major
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Version number major for the hardware.
What: /sys/devices/platform/hidma-mgmt*/hw_version_minor
/sys/devices/platform/QCOM8060:*/hw_version_minor
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Version number minor for the hardware.
What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions
/sys/devices/platform/QCOM8060:*/max_rd_xactions
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains a value between 0 and 31. Maximum number of
read transactions that can be issued back to back.
Choosing a higher number gives better performance but
can also cause performance reduction to other peripherals
sharing the same bus.
What: /sys/devices/platform/hidma-mgmt*/max_read_request
/sys/devices/platform/QCOM8060:*/max_read_request
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Size of each read request. The value needs to be a power
of two and can be between 128 and 1024.
What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions
/sys/devices/platform/QCOM8060:*/max_wr_xactions
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains a value between 0 and 31. Maximum number of
write transactions that can be issued back to back.
Choosing a higher number gives better performance but
can also cause performance reduction to other peripherals
sharing the same bus.
What: /sys/devices/platform/hidma-mgmt*/max_write_request
/sys/devices/platform/QCOM8060:*/max_write_request
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Size of each write request. The value needs to be a power
of two and can be between 128 and 1024.

View file

@ -0,0 +1,18 @@
What: /sys/devices/platform/<i2c-demux-name>/available_masters
Date: January 2016
KernelVersion: 4.6
Contact: Wolfram Sang <wsa@the-dreams.de>
Description:
Reading the file will give you a list of masters which can be
selected for a demultiplexed bus. The format is
"<index>:<name>". Example from a Renesas Lager board:
0:/i2c@e6500000 1:/i2c@e6508000
What: /sys/devices/platform/<i2c-demux-name>/current_master
Date: January 2016
KernelVersion: 4.6
Contact: Wolfram Sang <wsa@the-dreams.de>
Description:
This file selects/shows the active I2C master for a demultiplexed
bus. It uses the <index> value from the file 'available_masters'.

View file

@ -430,7 +430,7 @@ The rationale for using gotos is:
return result;
}
A common type of bug to be aware of it "one err bugs" which look like this:
A common type of bug to be aware of is "one err bugs" which look like this:
err:
kfree(foo->bar);
@ -640,7 +640,7 @@ Things to avoid when using macros:
do { \
if (blah(x) < 0) \
return -EBUGGERED; \
} while(0)
} while (0)
is a _very_ bad idea. It looks like a function call but exits the "calling"
function; don't break the internal parsers of those who will read the code.

View file

@ -951,16 +951,6 @@ to "Closing".
alignment constraints (e.g. the alignment constraints about 64-bit
objects).
3) Supporting multiple types of IOMMUs
If your architecture needs to support multiple types of IOMMUs, you
can use include/linux/asm-generic/dma-mapping-common.h. It's a
library to support the DMA API with multiple types of IOMMUs. Lots
of architectures (x86, powerpc, sh, alpha, ia64, microblaze and
sparc) use it. Choose one to see how it can be used. If you need to
support multiple types of IOMMUs in a single system, the example of
x86 or powerpc helps.
Closing
This document, and the API itself, would not be in its current

View file

@ -141,19 +141,6 @@ memory back to the pool before you destroy it.
Part Ic - DMA addressing limitations
------------------------------------
int
dma_supported(struct device *dev, u64 mask)
Checks to see if the device can support DMA to the memory described by
mask.
Returns: 1 if it can and 0 if it can't.
Notes: This routine merely tests to see if the mask is possible. It
won't change the current mask settings. It is more intended as an
internal API for use by the platform than an external API for use by
driver writers.
int
dma_set_mask_and_coherent(struct device *dev, u64 mask)
@ -249,7 +236,7 @@ are guaranteed also to be cache line boundaries).
DMA_TO_DEVICE synchronisation must be done after the last modification
of the memory region by the software and before it is handed off to
the driver. Once this primitive is used, memory covered by this
the device. Once this primitive is used, memory covered by this
primitive should be treated as read-only by the device. If the device
may write to it at any point, it should be DMA_BIDIRECTIONAL (see
below).

View file

@ -100,3 +100,29 @@ allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifying this attribute the allocated buffer is forced to be contiguous
also in physical memory.
DMA_ATTR_ALLOC_SINGLE_PAGES
---------------------------
This is a hint to the DMA-mapping subsystem that it's probably not worth
the time to try to allocate memory to in a way that gives better TLB
efficiency (AKA it's not worth trying to build the mapping out of larger
pages). You might want to specify this if:
- You know that the accesses to this memory won't thrash the TLB.
You might know that the accesses are likely to be sequential or
that they aren't sequential but it's unlikely you'll ping-pong
between many addresses that are likely to be in different physical
pages.
- You know that the penalty of TLB misses while accessing the
memory will be small enough to be inconsequential. If you are
doing a heavy operation like decryption or decompression this
might be the case.
- You know that the DMA mapping is fairly transitory. If you expect
the mapping to have a short lifetime then it may be worth it to
optimize allocation (avoid coming up with large pages) instead of
getting the slight performance win of larger pages.
Setting this hint doesn't guarantee that you won't get huge pages, but it
means that we won't try quite as hard to get them.
NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
though ARM64 patches will likely be posted soon.

View file

@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
include Documentation/DocBook/media/Makefile
@ -50,8 +50,7 @@ pdfdocs: $(PDF)
HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
htmldocs: $(HTML)
$(call build_main_index)
$(call build_images)
$(call cmd,build_main_index)
$(call install_media_images)
MAN := $(patsubst %.xml, %.9, $(BOOKS))
@ -139,7 +138,8 @@ quiet_cmd_db2pdf = PDF $@
index = index.html
main_idx = $(obj)/$(index)
build_main_index = rm -rf $(main_idx); \
quiet_cmd_build_main_index = HTML $(main_idx)
cmd_build_main_index = rm -rf $(main_idx); \
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
cat $(HTML) >> $(main_idx)
@ -227,6 +227,10 @@ dochelp:
@echo ' mandocs - man pages'
@echo ' installmandocs - install man pages generated by mandocs'
@echo ' cleandocs - clean all generated DocBook files'
@echo
@echo 'make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs s1.xml s2.xml'
@echo ' valid values for DOCBOOKS are: $(DOCBOOKS)'
###
# Temporary files left by various tools

View file

@ -348,10 +348,7 @@
<para>type:
<itemizedlist>
<listitem>
<para>blkcipher for synchronous block ciphers</para>
</listitem>
<listitem>
<para>ablkcipher for asynchronous block ciphers</para>
<para>skcipher for symmetric key ciphers</para>
</listitem>
<listitem>
<para>cipher for single block ciphers that may be used with
@ -484,6 +481,9 @@
<listitem>
<para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para>
</listitem>
<listitem>
<para>CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher</para>
</listitem>
<listitem>
<para>CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
@ -597,7 +597,7 @@ kernel crypto API | IPSEC Layer
v v
+-----------+ +-----------+
| | | |
| ablkcipher| | ahash |
| skcipher | | ahash |
| (ctr) | ---+ | (ghash) |
+-----------+ | +-----------+
|
@ -658,7 +658,7 @@ kernel crypto API | IPSEC Layer
<listitem>
<para>
The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API
The GCM AEAD cipher type implementation now invokes the SKCIPHER API
with the instantiated CTR(AES) cipher handle.
</para>
@ -669,7 +669,7 @@ kernel crypto API | IPSEC Layer
</para>
<para>
That means that the ABLKCIPHER implementation of CTR(AES) only
That means that the SKCIPHER implementation of CTR(AES) only
implements the CTR block chaining mode. After performing the block
chaining operation, the CIPHER implementation of AES is invoked.
</para>
@ -677,7 +677,7 @@ kernel crypto API | IPSEC Layer
<listitem>
<para>
The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
cipher handle to encrypt one block.
</para>
</listitem>
@ -706,7 +706,7 @@ kernel crypto API | IPSEC Layer
<para>
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
ASCII art picture above applies as well with the difference that only
step (4) is used and the ABLKCIPHER block chaining mode is CBC.
step (4) is used and the SKCIPHER block chaining mode is CBC.
</para>
</sect2>
@ -904,15 +904,14 @@ kernel crypto API | Caller
</sect2>
</sect1>
<sect1><title>Multi-Block Ciphers [BLKCIPHER] [ABLKCIPHER]</title>
<sect1><title>Multi-Block Ciphers</title>
<para>
Example of transformations: cbc(aes), ecb(arc4), ...
</para>
<para>
This section describes the multi-block cipher transformation
implementations for both synchronous [BLKCIPHER] and
asynchronous [ABLKCIPHER] case. The multi-block ciphers are
implementations. The multi-block ciphers are
used for transformations which operate on scatterlists of
data supplied to the transformation functions. They output
the result into a scatterlist of data as well.
@ -921,16 +920,15 @@ kernel crypto API | Caller
<sect2><title>Registration Specifics</title>
<para>
The registration of [BLKCIPHER] or [ABLKCIPHER] algorithms
The registration of multi-block cipher algorithms
is one of the most standard procedures throughout the crypto API.
</para>
<para>
Note, if a cipher implementation requires a proper alignment
of data, the caller should use the functions of
crypto_blkcipher_alignmask() or crypto_ablkcipher_alignmask()
respectively to identify a memory alignment mask. The kernel
crypto API is able to process requests that are unaligned.
crypto_skcipher_alignmask() to identify a memory alignment mask.
The kernel crypto API is able to process requests that are unaligned.
This implies, however, additional overhead as the kernel
crypto API needs to perform the realignment of the data which
may imply moving of data.
@ -945,14 +943,13 @@ kernel crypto API | Caller
<para>
Please refer to the single block cipher description for schematics
of the block cipher usage. The usage patterns are exactly the same
for [ABLKCIPHER] and [BLKCIPHER] as they are for plain [CIPHER].
of the block cipher usage.
</para>
</sect2>
<sect2><title>Specifics Of Asynchronous Multi-Block Cipher</title>
<para>
There are a couple of specifics to the [ABLKCIPHER] interface.
There are a couple of specifics to the asynchronous interface.
</para>
<para>
@ -1692,7 +1689,28 @@ read(opfd, out, outlen);
!Finclude/linux/crypto.h cipher_alg
!Finclude/crypto/rng.h rng_alg
</sect1>
<sect1><title>Asynchronous Block Cipher API</title>
<sect1><title>Symmetric Key Cipher API</title>
!Pinclude/crypto/skcipher.h Symmetric Key Cipher API
!Finclude/crypto/skcipher.h crypto_alloc_skcipher
!Finclude/crypto/skcipher.h crypto_free_skcipher
!Finclude/crypto/skcipher.h crypto_has_skcipher
!Finclude/crypto/skcipher.h crypto_skcipher_ivsize
!Finclude/crypto/skcipher.h crypto_skcipher_blocksize
!Finclude/crypto/skcipher.h crypto_skcipher_setkey
!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm
!Finclude/crypto/skcipher.h crypto_skcipher_encrypt
!Finclude/crypto/skcipher.h crypto_skcipher_decrypt
</sect1>
<sect1><title>Symmetric Key Cipher Request Handle</title>
!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle
!Finclude/crypto/skcipher.h crypto_skcipher_reqsize
!Finclude/crypto/skcipher.h skcipher_request_set_tfm
!Finclude/crypto/skcipher.h skcipher_request_alloc
!Finclude/crypto/skcipher.h skcipher_request_free
!Finclude/crypto/skcipher.h skcipher_request_set_callback
!Finclude/crypto/skcipher.h skcipher_request_set_crypt
</sect1>
<sect1><title>Asynchronous Block Cipher API - Deprecated</title>
!Pinclude/linux/crypto.h Asynchronous Block Cipher API
!Finclude/linux/crypto.h crypto_alloc_ablkcipher
!Finclude/linux/crypto.h crypto_free_ablkcipher
@ -1704,7 +1722,7 @@ read(opfd, out, outlen);
!Finclude/linux/crypto.h crypto_ablkcipher_encrypt
!Finclude/linux/crypto.h crypto_ablkcipher_decrypt
</sect1>
<sect1><title>Asynchronous Cipher Request Handle</title>
<sect1><title>Asynchronous Cipher Request Handle - Deprecated</title>
!Pinclude/linux/crypto.h Asynchronous Cipher Request Handle
!Finclude/linux/crypto.h crypto_ablkcipher_reqsize
!Finclude/linux/crypto.h ablkcipher_request_set_tfm
@ -1733,10 +1751,9 @@ read(opfd, out, outlen);
!Finclude/crypto/aead.h aead_request_free
!Finclude/crypto/aead.h aead_request_set_callback
!Finclude/crypto/aead.h aead_request_set_crypt
!Finclude/crypto/aead.h aead_request_set_assoc
!Finclude/crypto/aead.h aead_request_set_ad
</sect1>
<sect1><title>Synchronous Block Cipher API</title>
<sect1><title>Synchronous Block Cipher API - Deprecated</title>
!Pinclude/linux/crypto.h Synchronous Block Cipher API
!Finclude/linux/crypto.h crypto_alloc_blkcipher
!Finclude/linux/crypto.h crypto_free_blkcipher
@ -1761,19 +1778,6 @@ read(opfd, out, outlen);
!Finclude/linux/crypto.h crypto_cipher_setkey
!Finclude/linux/crypto.h crypto_cipher_encrypt_one
!Finclude/linux/crypto.h crypto_cipher_decrypt_one
</sect1>
<sect1><title>Synchronous Message Digest API</title>
!Pinclude/linux/crypto.h Synchronous Message Digest API
!Finclude/linux/crypto.h crypto_alloc_hash
!Finclude/linux/crypto.h crypto_free_hash
!Finclude/linux/crypto.h crypto_has_hash
!Finclude/linux/crypto.h crypto_hash_blocksize
!Finclude/linux/crypto.h crypto_hash_digestsize
!Finclude/linux/crypto.h crypto_hash_init
!Finclude/linux/crypto.h crypto_hash_update
!Finclude/linux/crypto.h crypto_hash_final
!Finclude/linux/crypto.h crypto_hash_digest
!Finclude/linux/crypto.h crypto_hash_setkey
</sect1>
<sect1><title>Message Digest Algorithm Definitions</title>
!Pinclude/crypto/hash.h Message Digest Algorithm Definitions
@ -1825,15 +1829,36 @@ read(opfd, out, outlen);
!Finclude/crypto/rng.h crypto_alloc_rng
!Finclude/crypto/rng.h crypto_rng_alg
!Finclude/crypto/rng.h crypto_free_rng
!Finclude/crypto/rng.h crypto_rng_generate
!Finclude/crypto/rng.h crypto_rng_get_bytes
!Finclude/crypto/rng.h crypto_rng_reset
!Finclude/crypto/rng.h crypto_rng_seedsize
!Cinclude/crypto/rng.h
</sect1>
<sect1><title>Asymmetric Cipher API</title>
!Pinclude/crypto/akcipher.h Generic Public Key API
!Finclude/crypto/akcipher.h akcipher_alg
!Finclude/crypto/akcipher.h akcipher_request
!Finclude/crypto/akcipher.h crypto_alloc_akcipher
!Finclude/crypto/akcipher.h crypto_free_akcipher
!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key
!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key
</sect1>
<sect1><title>Asymmetric Cipher Request Handle</title>
!Finclude/crypto/akcipher.h akcipher_request_alloc
!Finclude/crypto/akcipher.h akcipher_request_free
!Finclude/crypto/akcipher.h akcipher_request_set_callback
!Finclude/crypto/akcipher.h akcipher_request_set_crypt
!Finclude/crypto/akcipher.h crypto_akcipher_maxsize
!Finclude/crypto/akcipher.h crypto_akcipher_encrypt
!Finclude/crypto/akcipher.h crypto_akcipher_decrypt
!Finclude/crypto/akcipher.h crypto_akcipher_sign
!Finclude/crypto/akcipher.h crypto_akcipher_verify
</sect1>
</chapter>
<chapter id="Code"><title>Code Examples</title>
<sect1><title>Code Example For Asynchronous Block Cipher Operation</title>
<sect1><title>Code Example For Symmetric Key Cipher Operation</title>
<programlisting>
struct tcrypt_result {
@ -1842,15 +1867,15 @@ struct tcrypt_result {
};
/* tie all data structures together */
struct ablkcipher_def {
struct skcipher_def {
struct scatterlist sg;
struct crypto_ablkcipher *tfm;
struct ablkcipher_request *req;
struct crypto_skcipher *tfm;
struct skcipher_request *req;
struct tcrypt_result result;
};
/* Callback function */
static void test_ablkcipher_cb(struct crypto_async_request *req, int error)
static void test_skcipher_cb(struct crypto_async_request *req, int error)
{
struct tcrypt_result *result = req-&gt;data;
@ -1862,15 +1887,15 @@ static void test_ablkcipher_cb(struct crypto_async_request *req, int error)
}
/* Perform cipher operation */
static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk,
int enc)
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
int enc)
{
int rc = 0;
if (enc)
rc = crypto_ablkcipher_encrypt(ablk-&gt;req);
rc = crypto_skcipher_encrypt(sk-&gt;req);
else
rc = crypto_ablkcipher_decrypt(ablk-&gt;req);
rc = crypto_skcipher_decrypt(sk-&gt;req);
switch (rc) {
case 0:
@ -1878,52 +1903,52 @@ static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk,
case -EINPROGRESS:
case -EBUSY:
rc = wait_for_completion_interruptible(
&amp;ablk-&gt;result.completion);
if (!rc &amp;&amp; !ablk-&gt;result.err) {
reinit_completion(&amp;ablk-&gt;result.completion);
&amp;sk-&gt;result.completion);
if (!rc &amp;&amp; !sk-&gt;result.err) {
reinit_completion(&amp;sk-&gt;result.completion);
break;
}
default:
pr_info("ablkcipher encrypt returned with %d result %d\n",
rc, ablk-&gt;result.err);
pr_info("skcipher encrypt returned with %d result %d\n",
rc, sk-&gt;result.err);
break;
}
init_completion(&amp;ablk-&gt;result.completion);
init_completion(&amp;sk-&gt;result.completion);
return rc;
}
/* Initialize and trigger cipher operation */
static int test_ablkcipher(void)
static int test_skcipher(void)
{
struct ablkcipher_def ablk;
struct crypto_ablkcipher *ablkcipher = NULL;
struct ablkcipher_request *req = NULL;
struct skcipher_def sk;
struct crypto_skcipher *skcipher = NULL;
struct skcipher_request *req = NULL;
char *scratchpad = NULL;
char *ivdata = NULL;
unsigned char key[32];
int ret = -EFAULT;
ablkcipher = crypto_alloc_ablkcipher("cbc-aes-aesni", 0, 0);
if (IS_ERR(ablkcipher)) {
pr_info("could not allocate ablkcipher handle\n");
return PTR_ERR(ablkcipher);
skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
if (IS_ERR(skcipher)) {
pr_info("could not allocate skcipher handle\n");
return PTR_ERR(skcipher);
}
req = ablkcipher_request_alloc(ablkcipher, GFP_KERNEL);
req = skcipher_request_alloc(skcipher, GFP_KERNEL);
if (IS_ERR(req)) {
pr_info("could not allocate request queue\n");
ret = PTR_ERR(req);
goto out;
}
ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
test_ablkcipher_cb,
&amp;ablk.result);
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
test_skcipher_cb,
&amp;sk.result);
/* AES 256 with random key */
get_random_bytes(&amp;key, 32);
if (crypto_ablkcipher_setkey(ablkcipher, key, 32)) {
if (crypto_skcipher_setkey(skcipher, key, 32)) {
pr_info("key could not be set\n");
ret = -EAGAIN;
goto out;
@ -1945,26 +1970,26 @@ static int test_ablkcipher(void)
}
get_random_bytes(scratchpad, 16);
ablk.tfm = ablkcipher;
ablk.req = req;
sk.tfm = skcipher;
sk.req = req;
/* We encrypt one block */
sg_init_one(&amp;ablk.sg, scratchpad, 16);
ablkcipher_request_set_crypt(req, &amp;ablk.sg, &amp;ablk.sg, 16, ivdata);
init_completion(&amp;ablk.result.completion);
sg_init_one(&amp;sk.sg, scratchpad, 16);
skcipher_request_set_crypt(req, &amp;sk.sg, &amp;sk.sg, 16, ivdata);
init_completion(&amp;sk.result.completion);
/* encrypt data */
ret = test_ablkcipher_encdec(&amp;ablk, 1);
ret = test_skcipher_encdec(&amp;sk, 1);
if (ret)
goto out;
pr_info("Encryption triggered successfully\n");
out:
if (ablkcipher)
crypto_free_ablkcipher(ablkcipher);
if (skcipher)
crypto_free_skcipher(skcipher);
if (req)
ablkcipher_request_free(req);
skcipher_request_free(req);
if (ivdata)
kfree(ivdata);
if (scratchpad)
@ -1974,77 +1999,6 @@ out:
</programlisting>
</sect1>
<sect1><title>Code Example For Synchronous Block Cipher Operation</title>
<programlisting>
static int test_blkcipher(void)
{
struct crypto_blkcipher *blkcipher = NULL;
char *cipher = "cbc(aes)";
// AES 128
charkey =
"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef";
chariv =
"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef";
unsigned int ivsize = 0;
char *scratchpad = NULL; // holds plaintext and ciphertext
struct scatterlist sg;
struct blkcipher_desc desc;
int ret = -EFAULT;
blkcipher = crypto_alloc_blkcipher(cipher, 0, 0);
if (IS_ERR(blkcipher)) {
printk("could not allocate blkcipher handle for %s\n", cipher);
return -PTR_ERR(blkcipher);
}
if (crypto_blkcipher_setkey(blkcipher, key, strlen(key))) {
printk("key could not be set\n");
ret = -EAGAIN;
goto out;
}
ivsize = crypto_blkcipher_ivsize(blkcipher);
if (ivsize) {
if (ivsize != strlen(iv))
printk("IV length differs from expected length\n");
crypto_blkcipher_set_iv(blkcipher, iv, ivsize);
}
scratchpad = kmalloc(crypto_blkcipher_blocksize(blkcipher), GFP_KERNEL);
if (!scratchpad) {
printk("could not allocate scratchpad for %s\n", cipher);
goto out;
}
/* get some random data that we want to encrypt */
get_random_bytes(scratchpad, crypto_blkcipher_blocksize(blkcipher));
desc.flags = 0;
desc.tfm = blkcipher;
sg_init_one(&amp;sg, scratchpad, crypto_blkcipher_blocksize(blkcipher));
/* encrypt data in place */
crypto_blkcipher_encrypt(&amp;desc, &amp;sg, &amp;sg,
crypto_blkcipher_blocksize(blkcipher));
/* decrypt data in place
* crypto_blkcipher_decrypt(&amp;desc, &amp;sg, &amp;sg,
*/ crypto_blkcipher_blocksize(blkcipher));
printk("Cipher operation completed\n");
return 0;
out:
if (blkcipher)
crypto_free_blkcipher(blkcipher);
if (scratchpad)
kzfree(scratchpad);
return ret;
}
</programlisting>
</sect1>
<sect1><title>Code Example For Use of Operational State Memory With SHASH</title>
<programlisting>

View file

@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mc.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h
@ -238,83 +239,32 @@ X!Isound/sound_firmware.c
!Iinclude/media/videobuf2-memops.h
</sect1>
<sect1><title>Digital TV (DVB) devices</title>
!Idrivers/media/dvb-core/dvb_ca_en50221.h
!Idrivers/media/dvb-core/dvb_frontend.h
<sect1><title>Digital TV Common functions</title>
!Idrivers/media/dvb-core/dvb_math.h
!Idrivers/media/dvb-core/dvb_ringbuffer.h
!Idrivers/media/dvb-core/dvbdev.h
<sect1><title>Digital TV Demux API</title>
<para>The kernel demux API defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware
independent demux layer. It is only of interest for Digital TV
device driver writers. The header file for this API is named
<constant>demux.h</constant> and located in
<constant>drivers/media/dvb-core</constant>.</para>
<para>The demux API should be implemented for each demux in the
system. It is used to select the TS source of a demux and to manage
the demux resources. When the demux client allocates a resource via
the demux API, it receives a pointer to the API of that
resource.</para>
<para>Each demux receives its TS input from a DVB front-end or from
memory, as set via this demux API. In a system with more than one
front-end, the API can be used to select one of the DVB front-ends
as a TS source for a demux, unless this is fixed in the HW platform.
The demux API only controls front-ends regarding to their connections
with demuxes; the APIs used to set the other front-end parameters,
such as tuning, are not defined in this document.</para>
<para>The functions that implement the abstract interface demux should
be defined static or module private and registered to the Demux
core for external access. It is not necessary to implement every
function in the struct <constant>dmx_demux</constant>. For example,
a demux interface might support Section filtering, but not PES
filtering. The API client is expected to check the value of any
function pointer before calling the function: the value of NULL means
that the &#8220;function is not available&#8221;.</para>
<para>Whenever the functions of the demux API modify shared data,
the possibilities of lost update and race condition problems should
be addressed, e.g. by protecting parts of code with mutexes.</para>
<para>Note that functions called from a bottom half context must not
sleep. Even a simple memory allocation without using GFP_ATOMIC can
result in a kernel thread being put to sleep if swapping is needed.
For example, the Linux kernel calls the functions of a network device
interface from a bottom half context. Thus, if a demux API function
is called from network device code, the function must not sleep.
</para>
</sect1>
<section id="demux_callback_api">
<title>Demux Callback API</title>
<para>This kernel-space API comprises the callback functions that
deliver filtered data to the demux client. Unlike the other DVB
kABIs, these functions are provided by the client and called from
the demux code.</para>
<para>The function pointers of this abstract interface are not
packed into a structure as in the other demux APIs, because the
callback functions are registered and used independent of each
other. As an example, it is possible for the API client to provide
several callback functions for receiving TS packets and no
callbacks for PES packets or sections.</para>
<para>The functions that implement the callback API need not be
re-entrant: when a demux driver calls one of these functions,
the driver is not allowed to call the function again before
the original call returns. If a callback is triggered by a
hardware interrupt, it is recommended to use the Linux
&#8220;bottom half&#8221; mechanism or start a tasklet instead of
making the callback function call directly from a hardware
interrupt.</para>
<para>This mechanism is implemented by
<link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and
<link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para>
</section>
</sect1>
<sect1><title>Digital TV Frontend kABI</title>
!Pdrivers/media/dvb-core/dvb_frontend.h Digital TV Frontend
!Idrivers/media/dvb-core/dvb_frontend.h
</sect1>
<sect1><title>Digital TV Demux kABI</title>
!Pdrivers/media/dvb-core/demux.h Digital TV Demux
<sect1><title>Demux Callback API</title>
!Pdrivers/media/dvb-core/demux.h Demux Callback
</sect1>
!Idrivers/media/dvb-core/demux.h
</sect1>
</sect1>
<sect1><title>Digital TV Conditional Access kABI</title>
!Idrivers/media/dvb-core/dvb_ca_en50221.h
</sect1>
</sect1>
<sect1><title>Remote Controller devices</title>
!Iinclude/media/rc-core.h
!Iinclude/media/lirc_dev.h
</sect1>
<sect1><title>Media Controller devices</title>
!Pinclude/media/media-device.h Media Controller
!Iinclude/media/media-device.h
!Iinclude/media/media-devnode.h
!Iinclude/media/media-entity.h
@ -419,7 +369,7 @@ X!Ilib/fonts/fonts.c
!Iinclude/linux/input-polldev.h
!Edrivers/input/input-polldev.c
</sect1>
<sect1><title>Matrix keyboars/keypads</title>
<sect1><title>Matrix keyboards/keypads</title>
!Iinclude/linux/input/matrix_keypad.h
</sect1>
<sect1><title>Sparse keymap support</title>

File diff suppressed because it is too large Load diff

File diff suppressed because it is too large Load diff

View file

@ -458,7 +458,7 @@
.scan_type = {
.sign = 's',
.realbits = 12,
.storgebits = 16,
.storagebits = 16,
.shift = 4,
.endianness = IIO_LE,
},

View file

@ -199,8 +199,10 @@ DVB_DOCUMENTED = \
#
install_media_images = \
$(Q)-mkdir $(MEDIA_OBJ_DIR)/media_api; \
cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
$(Q)if [ "x$(findstring media_api.xml,$(DOCBOOKS))" != "x" ]; then \
mkdir -p $(MEDIA_OBJ_DIR)/media_api; \
cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api; \
fi
$(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
$(Q)base64 -d $< >$@

View file

@ -76,7 +76,7 @@ int main(void)
<para>NOTE: While it is possible to directly call the Kernel code like the
above example, it is strongly recommended to use
<ulink url="http://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>,
<ulink url="https://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>,
as it provides abstraction to work with the supported digital TV standards
and provides methods for usual operations like program scanning and to
read/write channel descriptor files.</para>

View file

@ -3,7 +3,7 @@
</para>
<para>NOTE: This section is out of date, and the code below won't even
compile. Please refer to the
<ulink url="http://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>
<ulink url="https://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>
for updated/recommended examples.
</para>

View file

@ -32,7 +32,7 @@ and filtering several section and PES data streams at the same time.
new standard Linux DVB API. As a commitment to the development of
terminals based on open standards, Nokia and Convergence made it
available to all Linux developers and published it on
<ulink url="http://www.linuxtv.org/" /> in September 2000.
<ulink url="https://linuxtv.org" /> in September 2000.
Convergence is the maintainer of the Linux DVB API. Together with the
LinuxTV community (i.e. you, the reader of this document), the Linux DVB
API will be constantly reviewed and improved. With the Linux driver for

View file

@ -5,7 +5,7 @@
* This program can be used and distributed without restrictions.
*
* This program is provided with the V4L2 API
* see http://linuxtv.org/docs.php for more information
* see https://linuxtv.org/docs.php for more information
*/
#include &lt;stdio.h&gt;

View file

@ -2666,7 +2666,7 @@ is useful to display images captured with V4L2 devices.</para>
<para>V4L2 does not support digital terrestrial, cable or
satellite broadcast. A separate project aiming at digital receivers
exists. You can find its homepage at <ulink
url="http://linuxtv.org">http://linuxtv.org</ulink>. The Linux DVB API
url="https://linuxtv.org">https://linuxtv.org</ulink>. The Linux DVB API
has no connection to the V4L2 API except that drivers for hybrid
hardware may support both.</para>
</section>

View file

@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-force-key-frame">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant>&nbsp;</entry>
<entry>button</entry>
</row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders.
This is a general, codec-agnostic keyframe control.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
@ -5069,6 +5077,46 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry>
<entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Configures the IT Content Type
of the transmitted video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. The
enum&nbsp;v4l2_dv_it_content_type defines the possible content types:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant>&nbsp;</entry>
<entry>Graphics content. Pixel data should be passed unfiltered and without
analog reconstruction.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant>&nbsp;</entry>
<entry>Photo content. The content is derived from digital still pictures.
The content should be passed through with minimal scaling and picture
enhancements.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant>&nbsp;</entry>
<entry>Cinema content.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant>&nbsp;</entry>
<entry>Game content. Audio and video latency should be minimized.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant>&nbsp;</entry>
<entry>No IT Content information is available and the ITC bit in the AVI
InfoFrame is set to 0.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
<entry>bitmask</entry>
@ -5098,6 +5146,16 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry>
<entry>enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Reads the IT Content Type
of the received video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. See
<constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

View file

@ -699,7 +699,7 @@ linkend="v4l2-buf-type" /></entry>
buffer. It depends on the negotiated data format and may change with
each buffer for compressed variable size data like JPEG images.
Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.
refers to a capture stream, applications when it refers to an output stream.
If the application sets this to 0 for an output stream, then
<structfield>bytesused</structfield> will be set to the size of the
buffer (see the <structfield>length</structfield> field of this struct) by
@ -720,14 +720,14 @@ linkend="buffer-flags" />.</entry>
<entry>Indicates the field order of the image in the
buffer, see <xref linkend="v4l2-field" />. This field is not used when
the buffer contains VBI data. Drivers must set it when
<structfield>type</structfield> refers to an input stream,
<structfield>type</structfield> refers to a capture stream,
applications when it refers to an output stream.</entry>
</row>
<row>
<entry>struct timeval</entry>
<entry><structfield>timestamp</structfield></entry>
<entry></entry>
<entry><para>For input streams this is time when the first data
<entry><para>For capture streams this is time when the first data
byte was captured, as returned by the
<function>clock_gettime()</function> function for the relevant
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
@ -866,7 +866,7 @@ must set this to 0.</entry>
<entry></entry>
<entry>The number of bytes occupied by data in the plane
(its payload). Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.
refers to a capture stream, applications when it refers to an output stream.
If the application sets this to 0 for an output stream, then
<structfield>bytesused</structfield> will be set to the size of the
plane (see the <structfield>length</structfield> field of this struct)
@ -919,7 +919,7 @@ must set this to 0.</entry>
<entry></entry>
<entry>Offset in bytes to video data in the plane.
Drivers must set this field when <structfield>type</structfield>
refers to an input stream, applications when it refers to an output stream.
refers to a capture 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

View file

@ -58,21 +58,36 @@
<title>Media device model</title>
<para>Discovering a device internal topology, and configuring it at runtime,
is one of the goals of the media controller API. To achieve this, hardware
devices are modelled as an oriented graph of building blocks called entities
connected through pads.</para>
<para>An entity is a basic media hardware or software building block. It can
correspond to a large variety of logical blocks such as physical hardware
devices (CMOS sensor for instance), logical hardware devices (a building
block in a System-on-Chip image processing pipeline), DMA channels or
physical connectors.</para>
<para>A pad is a connection endpoint through which an entity can interact
with other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should not
be confused with physical pins at chip boundaries.</para>
<para>A link is a point-to-point oriented connection between two pads,
either on the same entity or on different entities. Data flows from a source
pad to a sink pad.</para>
devices and Linux Kernel interfaces are modelled as graph objects on
an oriented graph. The object types that constitute the graph are:</para>
<itemizedlist>
<listitem><para>An <emphasis role="bold">entity</emphasis>
is a basic media hardware or software building block. It can correspond to
a large variety of logical blocks such as physical hardware devices
(CMOS sensor for instance), logical hardware devices (a building block in
a System-on-Chip image processing pipeline), DMA channels or physical
connectors.</para></listitem>
<listitem><para>An <emphasis role="bold">interface</emphasis>
is a graph representation of a Linux Kernel userspace API interface,
like a device node or a sysfs file that controls one or more entities
in the graph.</para></listitem>
<listitem><para>A <emphasis role="bold">pad</emphasis>
is a data connection endpoint through which an entity can interact with
other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should
not be confused with physical pins at chip boundaries.</para></listitem>
<listitem><para>A <emphasis role="bold">data link</emphasis>
is a point-to-point oriented connection between two pads, either on the
same entity or on different entities. Data flows from a source pad to a
sink pad.</para></listitem>
<listitem><para>An <emphasis role="bold">interface link</emphasis>
is a point-to-point bidirectional control connection between a Linux
Kernel interface and an entity.m</para></listitem>
</itemizedlist>
</section>
<!-- All non-ioctl specific data types go here. -->
&sub-media-types;
</chapter>
<appendix id="media-user-func">
@ -83,6 +98,7 @@
&sub-media-func-ioctl;
<!-- All ioctls go here. -->
&sub-media-ioc-device-info;
&sub-media-ioc-g-topology;
&sub-media-ioc-enum-entities;
&sub-media-ioc-enum-links;
&sub-media-ioc-setup-link;

View file

@ -59,15 +59,6 @@
<para>Entity IDs can be non-contiguous. Applications must
<emphasis>not</emphasis> try to enumerate entities by calling
MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error.</para>
<para>Two or more entities that share a common non-zero
<structfield>group_id</structfield> value are considered as logically
grouped. Groups are used to report
<itemizedlist>
<listitem><para>ALSA, VBI and video nodes that carry the same media
stream</para></listitem>
<listitem><para>lens and flash controllers associated with a sensor</para></listitem>
</itemizedlist>
</para>
<table pgwide="1" frame="none" id="media-entity-desc">
<title>struct <structname>media_entity_desc</structname></title>
@ -106,7 +97,7 @@
<entry><structfield>revision</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity revision in a driver/hardware specific format.</entry>
<entry>Entity revision. Always zero (obsolete)</entry>
</row>
<row>
<entry>__u32</entry>
@ -120,7 +111,7 @@
<entry><structfield>group_id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity group ID</entry>
<entry>Entity group ID. Always zero (obsolete)</entry>
</row>
<row>
<entry>__u16</entry>
@ -171,97 +162,6 @@
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-type">
<title>Media entity types</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE</constant></entry>
<entry>Unknown device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
<entry>V4L video, radio or vbi device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_FB</constant></entry>
<entry>Frame buffer device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_ALSA</constant></entry>
<entry>ALSA card</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
<entry>DVB frontend devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
<entry>DVB demux devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
<entry>DVB DVR devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
<entry>DVB CAM devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
<entry>DVB network devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
<entry>Unknown V4L sub-device</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
<entry>Video sensor</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
<entry>Flash controller</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
<entry>Lens controller</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
<entry>Video decoder, the basic function of the video decoder is to
accept analogue video from a wide variety of sources such as
broadcast, DVD players, cameras and video cassette recorders, in
either NTSC, PAL or HD format and still occasionally SECAM, separate
it into its component parts, luminance and chrominance, and output
it in some digital video standard, with appropriate embedded timing
signals.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
<entry>TV and/or radio tuner</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-flag">
<title>Media entity flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry>
<entry>Default entity for its type. Used to discover the default
audio, VBI and video devices, the default camera sensor, ...</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>

View file

@ -118,35 +118,6 @@
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-pad-flag">
<title>Media pad flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_PAD_FL_SINK</constant></entry>
<entry>Input pad, relative to the entity. Input pads sink data and
are targets of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry>
<entry>Output pad, relative to the entity. Output pads source data
and are origins of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry>
<entry>If this flag is set and the pad is linked to any other
pad, then at least one of those links must be enabled for the
entity to be able to stream. There could be temporary reasons
(e.g. device configuration dependent) for the pad to need
enabled links even when this flag isn't set; the absence of the
flag doesn't imply there is none.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-link-desc">
<title>struct <structname>media_link_desc</structname></title>
<tgroup cols="3">
@ -171,33 +142,6 @@
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-link-flag">
<title>Media link flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry>
<entry>The link is enabled and can be used to transfer media data.
When two or more links target a sink pad, only one of them can be
enabled at a time.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry>
<entry>The link enabled state can't be modified at runtime. An
immutable link is always enabled.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry>
<entry>The link enabled state can be modified during streaming. This
flag is set by drivers and is read-only for applications.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and
<constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para>
</refsect1>
<refsect1>

View file

@ -0,0 +1,391 @@
<refentry id="media-g-topology">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_G_TOPOLOGY</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_G_TOPOLOGY</refname>
<refpurpose>Enumerate the graph topology and graph element properties</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct media_v2_topology *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_G_TOPOLOGY</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The typical usage of this ioctl is to call it twice.
On the first call, the structure defined at &media-v2-topology; should
be zeroed. At return, if no errors happen, this ioctl will return the
<constant>topology_version</constant> and the total number of entities,
interfaces, pads and links.</para>
<para>Before the second call, the userspace should allocate arrays to
store the graph elements that are desired, putting the pointers to them
at the ptr_entities, ptr_interfaces, ptr_links and/or ptr_pads, keeping
the other values untouched.</para>
<para>If the <constant>topology_version</constant> remains the same, the
ioctl should fill the desired arrays with the media graph elements.</para>
<table pgwide="1" frame="none" id="media-v2-topology">
<title>struct <structname>media_v2_topology</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u64</entry>
<entry><structfield>topology_version</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Version of the media graph topology. When the graph is
created, this field starts with zero. Every time a graph
element is added or removed, this field is
incremented.</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>num_entities</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Number of entities in the graph</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>ptr_entities</structfield></entry>
<entry></entry>
<entry></entry>
<entry>A pointer to a memory area where the entities array
will be stored, converted to a 64-bits integer.
It can be zero. if zero, the ioctl won't store the
entities. It will just update
<constant>num_entities</constant></entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>num_interfaces</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Number of interfaces in the graph</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>ptr_interfaces</structfield></entry>
<entry></entry>
<entry></entry>
<entry>A pointer to a memory area where the interfaces array
will be stored, converted to a 64-bits integer.
It can be zero. if zero, the ioctl won't store the
interfaces. It will just update
<constant>num_interfaces</constant></entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>num_pads</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Total number of pads in the graph</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>ptr_pads</structfield></entry>
<entry></entry>
<entry></entry>
<entry>A pointer to a memory area where the pads array
will be stored, converted to a 64-bits integer.
It can be zero. if zero, the ioctl won't store the
pads. It will just update
<constant>num_pads</constant></entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>num_links</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Total number of data and interface links in the graph</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>ptr_links</structfield></entry>
<entry></entry>
<entry></entry>
<entry>A pointer to a memory area where the links array
will be stored, converted to a 64-bits integer.
It can be zero. if zero, the ioctl won't store the
links. It will just update
<constant>num_links</constant></entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-v2-entity">
<title>struct <structname>media_v2_entity</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Unique ID for the entity.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>name</structfield>[64]</entry>
<entry></entry>
<entry></entry>
<entry>Entity name as an UTF-8 NULL-terminated string.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>function</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity main function, see <xref linkend="media-entity-type" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[12]</entry>
<entry>Reserved for future extensions. Drivers and applications must
set this array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-v2-interface">
<title>struct <structname>media_v2_interface</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Unique ID for the interface.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>intf_type</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Interface type, see <xref linkend="media-intf-type" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Interface flags. Currently unused.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry></entry>
<entry></entry>
<entry>Reserved for future extensions. Drivers and applications must
set this array to zero.</entry>
</row>
<row>
<entry>struct media_v2_intf_devnode</entry>
<entry><structfield>devnode</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Used only for device node interfaces. See <xref linkend="media-v2-intf-devnode" /> for details..</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-v2-intf-devnode">
<title>struct <structname>media_v2_interface</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Device node major number.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Device node minor number.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-v2-pad">
<title>struct <structname>media_v2_pad</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Unique ID for the pad.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>entity_id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Unique ID for the entity where this pad belongs.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Pad flags, see <xref linkend="media-pad-flag" /> for more details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry></entry>
<entry></entry>
<entry>Reserved for future extensions. Drivers and applications must
set this array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-v2-link">
<title>struct <structname>media_v2_pad</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Unique ID for the pad.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>source_id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>
<para>On pad to pad links: unique ID for the source pad.</para>
<para>On interface to entity links: unique ID for the interface.</para>
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>sink_id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>
<para>On pad to pad links: unique ID for the sink pad.</para>
<para>On interface to entity links: unique ID for the entity.</para>
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Link flags, see <xref linkend="media-link-flag" /> for more details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[5]</entry>
<entry></entry>
<entry></entry>
<entry>Reserved for future extensions. Drivers and applications must
set this array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENOSPC</errorcode></term>
<listitem>
<para>This is returned when either one or more of the num_entities,
num_interfaces, num_links or num_pads are non-zero and are smaller
than the actual number of elements inside the graph. This may happen
if the <constant>topology_version</constant> changed when compared
to the last time this ioctl was called. Userspace should usually
free the area for the pointers, zero the struct elements and call
this ioctl again.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

View file

@ -0,0 +1,315 @@
<section id="media-controller-types">
<title>Types and flags used to represent the media graph elements</title>
<table frame="none" pgwide="1" id="media-entity-type">
<title>Media entity types</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_F_UNKNOWN</constant> and <constant>MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN</constant></entry>
<entry>Unknown entity. That generally indicates that
a driver didn't initialize properly the entity, with is a Kernel bug</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IO_V4L</constant></entry>
<entry>Data streaming input and/or output entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IO_VBI</constant></entry>
<entry>V4L VBI streaming input or output entity</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IO_SWRADIO</constant></entry>
<entry>V4L Software Digital Radio (SDR) streaming input or output entity</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IO_DTV</constant></entry>
<entry>DVB Digital TV streaming input or output entity</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_DTV_DEMOD</constant></entry>
<entry>Digital TV demodulator entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_TS_DEMUX</constant></entry>
<entry>MPEG Transport stream demux entity. Could be implemented on hardware or in Kernelspace by the Linux DVB subsystem.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_DTV_CA</constant></entry>
<entry>Digital TV Conditional Access module (CAM) entity</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_DTV_NET_DECAP</constant></entry>
<entry>Digital TV network ULE/MLE desencapsulation entity. Could be implemented on hardware or in Kernelspace</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_CONN_RF</constant></entry>
<entry>Connector for a Radio Frequency (RF) signal.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_CONN_SVIDEO</constant></entry>
<entry>Connector for a S-Video signal.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_CONN_COMPOSITE</constant></entry>
<entry>Connector for a RGB composite signal.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_CAM_SENSOR</constant></entry>
<entry>Camera video sensor entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_FLASH</constant></entry>
<entry>Flash controller entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_LENS</constant></entry>
<entry>Lens controller entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_ATV_DECODER</constant></entry>
<entry>Analog video decoder, the basic function of the video decoder
is to accept analogue video from a wide variety of sources such as
broadcast, DVD players, cameras and video cassette recorders, in
either NTSC, PAL, SECAM or HD format, separating the stream
into its component parts, luminance and chrominance, and output
it in some digital video standard, with appropriate timing
signals.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_TUNER</constant></entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner,
with consists on a PLL tuning stage that converts radio
frequency (RF) signal into an Intermediate Frequency (IF).
Modern tuners have internally IF-PLL decoders for audio
and video, but older models have those stages implemented
on separate entities.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry>
<entry>IF-PLL video decoder. It receives the IF from a PLL
and decodes the analog TV video signal. This is commonly
found on some very old analog tuners, like Philips MK3
designs. They all contain a tda9887 (or some software
compatible similar chip, like tda9885). Those devices
use a different I2C address than the tuner PLL.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry>
<entry>IF-PLL sound decoder. It receives the IF from a PLL
and decodes the analog TV audio signal. This is commonly
found on some very old analog hardware, like Micronas
msp3400, Philips tda9840, tda985x, etc. Those devices
use a different I2C address than the tuner PLL and
should be controlled together with the IF-PLL video
decoder.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_CAPTURE</constant></entry>
<entry>Audio Capture Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_PLAYBACK</constant></entry>
<entry>Audio Playback Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_MIXER</constant></entry>
<entry>Audio Mixer Function Entity.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-flag">
<title>Media entity flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry>
<entry>Default entity for its type. Used to discover the default
audio, VBI and video devices, the default camera sensor, ...</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_FL_CONNECTOR</constant></entry>
<entry>The entity represents a data conector</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-intf-type">
<title>Media interface types</title>
<tgroup cols="3">
<colspec colname="c1"/>
<colspec colname="c2"/>
<colspec colname="c3"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_INTF_T_DVB_FE</constant></entry>
<entry>Device node interface for the Digital TV frontend</entry>
<entry>typically, /dev/dvb/adapter?/frontend?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_DVB_DEMUX</constant></entry>
<entry>Device node interface for the Digital TV demux</entry>
<entry>typically, /dev/dvb/adapter?/demux?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_DVB_DVR</constant></entry>
<entry>Device node interface for the Digital TV DVR</entry>
<entry>typically, /dev/dvb/adapter?/dvr?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_DVB_CA</constant></entry>
<entry>Device node interface for the Digital TV Conditional Access</entry>
<entry>typically, /dev/dvb/adapter?/ca?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_DVB_FE</constant></entry>
<entry>Device node interface for the Digital TV network control</entry>
<entry>typically, /dev/dvb/adapter?/net?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_V4L_VIDEO</constant></entry>
<entry>Device node interface for video (V4L)</entry>
<entry>typically, /dev/video?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_V4L_VBI</constant></entry>
<entry>Device node interface for VBI (V4L)</entry>
<entry>typically, /dev/vbi?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_V4L_RADIO</constant></entry>
<entry>Device node interface for radio (V4L)</entry>
<entry>typically, /dev/vbi?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_V4L_SUBDEV</constant></entry>
<entry>Device node interface for a V4L subdevice</entry>
<entry>typically, /dev/v4l-subdev?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_V4L_SWRADIO</constant></entry>
<entry>Device node interface for Software Defined Radio (V4L)</entry>
<entry>typically, /dev/swradio?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_CAPTURE</constant></entry>
<entry>Device node interface for ALSA PCM Capture</entry>
<entry>typically, /dev/snd/pcmC?D?c</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_PLAYBACK</constant></entry>
<entry>Device node interface for ALSA PCM Playback</entry>
<entry>typically, /dev/snd/pcmC?D?p</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_CONTROL</constant></entry>
<entry>Device node interface for ALSA Control</entry>
<entry>typically, /dev/snd/controlC?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_COMPRESS</constant></entry>
<entry>Device node interface for ALSA Compress</entry>
<entry>typically, /dev/snd/compr?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_RAWMIDI</constant></entry>
<entry>Device node interface for ALSA Raw MIDI</entry>
<entry>typically, /dev/snd/midi?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_HWDEP</constant></entry>
<entry>Device node interface for ALSA Hardware Dependent</entry>
<entry>typically, /dev/snd/hwC?D?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_SEQUENCER</constant></entry>
<entry>Device node interface for ALSA Sequencer</entry>
<entry>typically, /dev/snd/seq</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_TIMER</constant></entry>
<entry>Device node interface for ALSA Timer</entry>
<entry>typically, /dev/snd/timer</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-pad-flag">
<title>Media pad flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_PAD_FL_SINK</constant></entry>
<entry>Input pad, relative to the entity. Input pads sink data and
are targets of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry>
<entry>Output pad, relative to the entity. Output pads source data
and are origins of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_MUST_CONNECT</constant></entry>
<entry>If this flag is set and the pad is linked to any other
pad, then at least one of those links must be enabled for the
entity to be able to stream. There could be temporary reasons
(e.g. device configuration dependent) for the pad to need
enabled links even when this flag isn't set; the absence of the
flag doesn't imply there is none.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and
<constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para>
<table frame="none" pgwide="1" id="media-link-flag">
<title>Media link flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry>
<entry>The link is enabled and can be used to transfer media data.
When two or more links target a sink pad, only one of them can be
enabled at a time.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry>
<entry>The link enabled state can't be modified at runtime. An
immutable link is always enabled.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry>
<entry>The link enabled state can be modified during streaming. This
flag is set by drivers and is read-only for applications.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_LINK_TYPE</constant></entry>
<entry><para>This is a bitmask that defines the type of the link.
Currently, two types of links are supported:</para>
<para><constant>MEDIA_LNK_FL_DATA_LINK</constant>
if the link is between two pads</para>
<para><constant>MEDIA_LNK_FL_INTERFACE_LINK</constant>
if the link is between an interface and an entity</para></entry>
</row>
</tbody>
</tgroup>
</table>
</section>

View file

@ -0,0 +1,49 @@
<refentry id="V4L2-PIX-FMT-Y12I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12I ('Y12I')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel, but with
pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a
24-bit word in the little-endian order. On a little-endian machine these pixels
can be deinterlaced using</para>
<para>
<programlisting>
__u8 *buf;
left0 = 0xfff &amp; *(__u16 *)buf;
right0 = *(__u16 *)(buf + 1) >> 4;
</programlisting>
</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes</title>
<formalpara>
<title>Bit-packed representation</title>
<para>pixels cross the byte boundary and have a ratio of 3 bytes for each
interleaved pixel.
<informaltable frame="all">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>Y'<subscript>0left[7:0]</subscript></entry>
<entry>Y'<subscript>0right[3:0]</subscript>Y'<subscript>0left[11:8]</subscript></entry>
<entry>Y'<subscript>0right[11:4]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View file

@ -0,0 +1,80 @@
<refentry id="V4L2-PIX-FMT-Y8I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y8I ('Y8I ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y8I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 8 bits per pixel, but with
pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g.
the R200 RealSense camera stores pixel from the left sensor in lower and from
the right sensor in the higher 8 bits.</para>
<example>
<title><constant>V4L2_PIX_FMT_Y8I</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00left</subscript></entry>
<entry>Y'<subscript>00right</subscript></entry>
<entry>Y'<subscript>01left</subscript></entry>
<entry>Y'<subscript>01right</subscript></entry>
<entry>Y'<subscript>02left</subscript></entry>
<entry>Y'<subscript>02right</subscript></entry>
<entry>Y'<subscript>03left</subscript></entry>
<entry>Y'<subscript>03right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10left</subscript></entry>
<entry>Y'<subscript>10right</subscript></entry>
<entry>Y'<subscript>11left</subscript></entry>
<entry>Y'<subscript>11right</subscript></entry>
<entry>Y'<subscript>12left</subscript></entry>
<entry>Y'<subscript>12right</subscript></entry>
<entry>Y'<subscript>13left</subscript></entry>
<entry>Y'<subscript>13right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20left</subscript></entry>
<entry>Y'<subscript>20right</subscript></entry>
<entry>Y'<subscript>21left</subscript></entry>
<entry>Y'<subscript>21right</subscript></entry>
<entry>Y'<subscript>22left</subscript></entry>
<entry>Y'<subscript>22right</subscript></entry>
<entry>Y'<subscript>23left</subscript></entry>
<entry>Y'<subscript>23right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30left</subscript></entry>
<entry>Y'<subscript>30right</subscript></entry>
<entry>Y'<subscript>31left</subscript></entry>
<entry>Y'<subscript>31right</subscript></entry>
<entry>Y'<subscript>32left</subscript></entry>
<entry>Y'<subscript>32right</subscript></entry>
<entry>Y'<subscript>33left</subscript></entry>
<entry>Y'<subscript>33right</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View file

@ -1,35 +1,43 @@
<refentry id="V4L2-PIX-FMT-YUV420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and
<constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous
in memory.</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cb data
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
in the third plane.</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV420M</constant> and
<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>

View file

@ -0,0 +1,166 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname>
<refpurpose>Planar formats with &frac12; horizontal resolution, also
known as YUV and YVU 4:2:2</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data
constitutes the second plane which is half the width of the Y plane (and of the
image). Each Cb belongs to two pixels. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV422M</constant> and
<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;6:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;6:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View file

@ -0,0 +1,177 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname>
<refpurpose>Planar formats with full horizontal resolution, also
known as YUV and YVU 4:4:4</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data
constitutes the second plane which is the same width and height as the Y plane
(and as the image). The Cr data, just like the Cb plane, is in the third plane.
</para>
<para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have the same number of pad bytes after their rows.</para>
<para><constant>V4L2_PIX_FMT_YUV444M</constant> and
<constant>V4L2_PIX_FMT_YUV444M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YUV444M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;8:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;12:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>1</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>2</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>3</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View file

@ -1,154 +0,0 @@
<refentry id="V4L2-PIX-FMT-YVU420M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
with planes non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.
The Y plane is first. The Y plane has one byte per pixel. The Cr data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cr belongs to four
pixels, a two-by-two square of the image. For example,
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cr
and Cb planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View file

@ -0,0 +1,81 @@
<refentry id="V4L2-PIX-FMT-Z16">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Z16 ('Z16 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Z16</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a 16-bit format, representing depth data. Each pixel is a
distance to the respective point in the image coordinates. Distance unit can
vary and has to be negotiated with the device separately. Each pixel is stored
in a 16-bit word in the little endian byte order.
</para>
<example>
<title><constant>V4L2_PIX_FMT_Z16</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Z<subscript>00low</subscript></entry>
<entry>Z<subscript>00high</subscript></entry>
<entry>Z<subscript>01low</subscript></entry>
<entry>Z<subscript>01high</subscript></entry>
<entry>Z<subscript>02low</subscript></entry>
<entry>Z<subscript>02high</subscript></entry>
<entry>Z<subscript>03low</subscript></entry>
<entry>Z<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Z<subscript>10low</subscript></entry>
<entry>Z<subscript>10high</subscript></entry>
<entry>Z<subscript>11low</subscript></entry>
<entry>Z<subscript>11high</subscript></entry>
<entry>Z<subscript>12low</subscript></entry>
<entry>Z<subscript>12high</subscript></entry>
<entry>Z<subscript>13low</subscript></entry>
<entry>Z<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Z<subscript>20low</subscript></entry>
<entry>Z<subscript>20high</subscript></entry>
<entry>Z<subscript>21low</subscript></entry>
<entry>Z<subscript>21high</subscript></entry>
<entry>Z<subscript>22low</subscript></entry>
<entry>Z<subscript>22high</subscript></entry>
<entry>Z<subscript>23low</subscript></entry>
<entry>Z<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Z<subscript>30low</subscript></entry>
<entry>Z<subscript>30high</subscript></entry>
<entry>Z<subscript>31low</subscript></entry>
<entry>Z<subscript>31high</subscript></entry>
<entry>Z<subscript>32low</subscript></entry>
<entry>Z<subscript>32high</subscript></entry>
<entry>Z<subscript>33low</subscript></entry>
<entry>Z<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

View file

@ -1620,6 +1620,8 @@ information.</para>
&sub-y10b;
&sub-y16;
&sub-y16-be;
&sub-y8i;
&sub-y12i;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;
@ -1628,7 +1630,8 @@ information.</para>
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yvu420m;
&sub-yuv422m;
&sub-yuv444m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;
@ -1641,6 +1644,14 @@ information.</para>
&sub-m420;
</section>
<section id="depth-formats">
<title>Depth Formats</title>
<para>Depth data provides distance to points, mapped onto the image plane
</para>
&sub-z16;
</section>
<section>
<title>Compressed Formats</title>

View file

@ -151,6 +151,16 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>4.5</revnumber>
<date>2015-10-29</date>
<authorinitials>rr</authorinitials>
<revremark>Extend vidioc-g-ext-ctrls;. Replace ctrl_class with a new
union with ctrl_class and which. Which is used to select the current value of
the control or the default value.
</revremark>
</revision>
<revision>
<revnumber>4.4</revnumber>
<date>2015-05-26</date>

View file

@ -58,7 +58,7 @@
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link> or <link
linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in
addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
addition to the &VIDIOC-REQBUFS; ioctl, when a tighter
control over buffers is required. This ioctl can be called multiple times to
create buffers of different sizes.</para>
@ -71,30 +71,28 @@ zeroed.</para>
<para>The <structfield>format</structfield> field specifies the image format
that the buffers must be able to handle. The application has to fill in this
&v4l2-format;. Usually this will be done using the
<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl()
to ensure that the requested format is supported by the driver. Unsupported
formats will result in an error.</para>
&v4l2-format;. Usually this will be done using the &VIDIOC-TRY-FMT; or &VIDIOC-G-FMT; ioctls
to ensure that the requested format is supported by the driver.
Based on the format's <structfield>type</structfield> field the requested buffer
size (for single-planar) or plane sizes (for multi-planar formats) will be
used for the allocated buffers. The driver may return an error if the size(s)
are not supported by the hardware (usually because they are too small).</para>
<para>The buffers created by this ioctl will have as minimum size the size
defined by the <structfield>format.pix.sizeimage</structfield> field. If the
defined by the <structfield>format.pix.sizeimage</structfield> field (or the
corresponding fields for other format types). Usually if the
<structfield>format.pix.sizeimage</structfield> field is less than the minimum
required for the given format, then <structfield>sizeimage</structfield> will be
increased by the driver to that minimum to allocate the buffers. If it is
larger, then the value will be used as-is. The same applies to the
<structfield>sizeimage</structfield> field of the
<structname>v4l2_plane_pix_format</structname> structure in the case of
multiplanar formats.</para>
required for the given format, then an error will be returned since drivers will
typically not allow this. If it is larger, then the value will be used as-is.
In other words, the driver may reject the requested size, but if it is accepted
the driver will use it unchanged.</para>
<para>When the ioctl is called with a pointer to this structure the driver
will attempt to allocate up to the requested number of buffers and store the
actual number allocated and the starting index in the
<structfield>count</structfield> and the <structfield>index</structfield> fields
respectively. On return <structfield>count</structfield> can be smaller than
the number requested. The driver may also increase buffer sizes if required,
however, it will not update <structfield>sizeimage</structfield> field values.
The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that
information.</para>
the number requested.</para>
<table pgwide="1" frame="none" id="v4l2-create-buffers">
<title>struct <structname>v4l2_create_buffers</structname></title>

View file

@ -99,7 +99,7 @@ if the driver supports writing registers to the device.</para>
<para>We recommended the <application>v4l2-dbg</application>
utility over calling this ioctl directly. It is available from the
LinuxTV v4l-dvb repository; see <ulink
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
url="https://linuxtv.org/repo/">https://linuxtv.org/repo/</ulink> for
access instructions.</para>
<!-- Note for convenience vidioc-dbg-g-register.sgml

View file

@ -117,7 +117,7 @@ However when a driver supports these ioctls it must also support
<para>We recommended the <application>v4l2-dbg</application>
utility over calling these ioctls directly. It is available from the
LinuxTV v4l-dvb repository; see <ulink
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
url="https://linuxtv.org/repo/">https://linuxtv.org/repo/</ulink> for
access instructions.</para>
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml

View file

@ -198,7 +198,7 @@ video4linux-list@redhat.com on 17 Oct 2002
<constant>V4L2_STD_ATSC_16_VSB</constant> are U.S. terrestrial digital
TV standards. Presently the V4L2 API does not support digital TV. See
also the Linux DVB API at <ulink
url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
url="https://linuxtv.org">https://linuxtv.org</ulink>.</para>
<para><programlisting>
#define V4L2_STD_PAL_BG (V4L2_STD_PAL_B |\
V4L2_STD_PAL_B1 |\

View file

@ -61,7 +61,7 @@ must belong to the same control class.</para>
<para>Applications must always fill in the
<structfield>count</structfield>,
<structfield>ctrl_class</structfield>,
<structfield>which</structfield>,
<structfield>controls</structfield> and
<structfield>reserved</structfield> fields of &v4l2-ext-controls;, and
initialize the &v4l2-ext-control; array pointed to by the
@ -109,7 +109,7 @@ the driver whether wrong values are automatically adjusted to a valid
value or if an error is returned.</para>
<para>When the <structfield>id</structfield> or
<structfield>ctrl_class</structfield> is invalid drivers return an
<structfield>which</structfield> is invalid drivers return an
&EINVAL;. When the value is out of bounds drivers can choose to take
the closest valid value or return an &ERANGE;, whatever seems more
appropriate. In the first case the new value is set in
@ -223,7 +223,12 @@ Valid if <constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set for this control
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>union</entry>
<entry>(anonymous)</entry>
</row>
<row>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>ctrl_class</structfield></entry>
<entry>The control class to which all controls belong, see
@ -233,6 +238,23 @@ belong to any control class. Whether drivers support this can be tested by setti
<structfield>ctrl_class</structfield> to 0 and calling <constant>VIDIOC_TRY_EXT_CTRLS</constant>
with a <structfield>count</structfield> of 0. If that succeeds, then the driver
supports this feature.</entry>
</row>
<row>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>which</structfield></entry>
<entry><para>Which value of the control to get/set/try. <constant>V4L2_CTRL_WHICH_CUR_VAL</constant>
will return the current value of the control and <constant>V4L2_CTRL_WHICH_DEF_VAL</constant> will
return the default value of the control. Please note that you can only get the default value of the
control, you cannot set or try it.</para>
<para>For backwards compatibility you can also use a control class here (see
<xref linkend="ctrl-class" />). In that case all controls have to belong to that
control class. This usage is deprecated, instead just use <constant>V4L2_CTRL_WHICH_CUR_VAL</constant>.
There are some very old drivers that do not yet support <constant>V4L2_CTRL_WHICH_CUR_VAL</constant>
and that require a control class here. You can test for such drivers by setting ctrl_class to
<constant>V4L2_CTRL_WHICH_CUR_VAL</constant> and calling VIDIOC_TRY_EXT_CTRLS with a count of 0.
If that fails, then the driver does not support <constant>V4L2_CTRL_WHICH_CUR_VAL</constant>.</para>
</entry>
</row>
<row>
<entry>__u32</entry>
@ -390,7 +412,7 @@ These controls are described in <xref linkend="rf-tuner-controls" />.</entry>
<listitem>
<para>The &v4l2-ext-control; <structfield>id</structfield>
is invalid, the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
<structfield>which</structfield> is invalid, or the &v4l2-ext-control;
<structfield>value</structfield> was inappropriate (e.g. the given menu
index is not supported by the driver). This error code is
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and

View file

@ -60,9 +60,19 @@ input</refpurpose>
automatically, similar to sensing the video standard. To do so, applications
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the
timings structure.
timings structure.</para>
If the timings could not be detected because there was no signal, then
<para>Please note that drivers shall <emphasis>not</emphasis> switch timings automatically
if new timings are detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERY_DV_TIMINGS</constant>.
The reason is that new timings usually mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERY_DV_TIMINGS</constant>,
and if the detected timings are valid they will have to stop streaming, set the new
timings, allocate new buffers and start streaming again.</para>
<para>If the timings could not be detected because there was no signal, then
<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
it was unstable and the receiver could not lock to the signal, then
<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,

View file

@ -59,6 +59,16 @@ then the driver will return V4L2_STD_UNKNOWN. When detection is not
possible or fails, the set must contain all standards supported by the
current video input or output.</para>
<para>Please note that drivers shall <emphasis>not</emphasis> switch the video standard
automatically if a new video standard is detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERYSTD</constant>.
The reason is that a new video standard can mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERYSTD</constant>,
and if the detected video standard is valid they will have to stop streaming, set the new
standard, allocate new buffers and start streaming again.</para>
</refsect1>
<refsect1>

View file

@ -19,10 +19,10 @@
<!ENTITY cs-def "<colspec colname='c1' colwidth='3*' /><colspec colname='c2' colwidth='1*' /><colspec colname='c3' colwidth='4*' /><spanspec spanname='hspan' namest='c1' nameend='c3' />">
<!-- Video for Linux mailing list address. -->
<!ENTITY v4l-ml "<ulink url='http://www.linuxtv.org/lists.php'>http://www.linuxtv.org/lists.php</ulink>">
<!ENTITY v4l-ml "<ulink url='https://linuxtv.org/lists.php'>https://linuxtv.org/lists.php</ulink>">
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
<!ENTITY v4l-dvb "<ulink url='https://linuxtv.org/repo/'>https://linuxtv.org/repo/</ulink>">
<!ENTITY dash-ent-8 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-12 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
@ -91,7 +91,7 @@
components, like mixers, PCM capture, PCM playback, etc, which
are controlled via ALSA API.</para>
<para>For additional information and for the latest development code,
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
see: <ulink url="https://linuxtv.org">https://linuxtv.org</ulink>.</para>
<para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
</preface>

View file

@ -162,12 +162,15 @@
<sect1 id="Basic_defines">
<title>Basic defines</title>
<para>
At least you have to provide a mtd structure and
a storage for the ioremap'ed chip address.
You can allocate the mtd structure using kmalloc
or you can allocate it statically.
In case of static allocation you have to allocate
a nand_chip structure too.
At least you have to provide a nand_chip structure
and a storage for the ioremap'ed chip address.
You can allocate the nand_chip structure using
kmalloc or you can allocate it statically.
The NAND chip structure embeds an mtd structure
which will be registered to the MTD subsystem.
You can extract a pointer to the mtd structure
from a nand_chip pointer using the nand_to_mtd()
helper.
</para>
<para>
Kmalloc based example
@ -180,7 +183,6 @@ static void __iomem *baseaddr;
Static example
</para>
<programlisting>
static struct mtd_info board_mtd;
static struct nand_chip board_chip;
static void __iomem *baseaddr;
</programlisting>
@ -235,7 +237,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
<programlisting>
static void board_hwcontrol(struct mtd_info *mtd, int cmd)
{
struct nand_chip *this = (struct nand_chip *) mtd->priv;
struct nand_chip *this = mtd_to_nand(mtd);
switch(cmd){
case NAND_CTL_SETCLE: this->IO_ADDR_W |= CLE_ADRR_BIT; break;
case NAND_CTL_CLRCLE: this->IO_ADDR_W &amp;= ~CLE_ADRR_BIT; break;
@ -274,13 +276,15 @@ static int __init board_init (void)
int err = 0;
/* Allocate memory for MTD device structure and private data */
board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
if (!board_mtd) {
this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
if (!this) {
printk ("Unable to allocate NAND MTD device structure.\n");
err = -ENOMEM;
goto out;
}
board_mtd = nand_to_mtd(this);
/* map physical address */
baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if (!baseaddr) {
@ -289,11 +293,6 @@ static int __init board_init (void)
goto out_mtd;
}
/* Get pointer to private data */
this = (struct nand_chip *) ();
/* Link the private data with the MTD structure */
board_mtd->priv = this;
/* Set address of NAND IO lines */
this->IO_ADDR_R = baseaddr;
this->IO_ADDR_W = baseaddr;
@ -317,7 +316,7 @@ static int __init board_init (void)
out_ior:
iounmap(baseaddr);
out_mtd:
kfree (board_mtd);
kfree (this);
out:
return err;
}
@ -343,7 +342,7 @@ static void __exit board_cleanup (void)
iounmap(baseaddr);
/* Free the MTD device structure */
kfree (board_mtd);
kfree (mtd_to_nand(board_mtd));
}
module_exit(board_cleanup);
#endif
@ -399,7 +398,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<programlisting>
static void board_select_chip (struct mtd_info *mtd, int chip)
{
struct nand_chip *this = (struct nand_chip *) mtd->priv;
struct nand_chip *this = mtd_to_nand(mtd);
/* Deselect all chips */
this->IO_ADDR_R &amp;= ~BOARD_NAND_ADDR_MASK;

View file

@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
or SET_INTERFACE.
</para></warning></listitem></varlistentry>
<varlistentry><term>USBDEVFS_DROP_PRIVILEGES</term>
<listitem><para>This is used to relinquish the ability
to do certain operations which are considered to be
privileged on a usbfs file descriptor.
This includes claiming arbitrary interfaces, resetting
a device on which there are currently claimed interfaces
from other users, and issuing USBDEVFS_IOCTL calls.
The ioctl parameter is a 32 bit mask of interfaces
the user is allowed to claim on this file descriptor.
You may issue this ioctl more than one time to narrow
said mask.
</para></listitem></varlistentry>
</variablelist>
</sect2>

View file

@ -68,7 +68,7 @@ For common questions and answers about the GPL, please see:
Documentation
------------
-------------
The Linux kernel source tree has a large range of documents that are
invaluable for learning how to interact with the kernel community. When
@ -187,7 +187,7 @@ apply a patch.
If you do not know where you want to start, but you want to look for
some task to start doing to join into the kernel development community,
go to the Linux Kernel Janitor's project:
http://kernelnewbies.org/KernelJanitors
http://kernelnewbies.org/KernelJanitors
It is a great place to start. It describes a list of relatively simple
problems that need to be cleaned up and fixed within the Linux kernel
source tree. Working with the developers in charge of this project, you
@ -209,7 +209,7 @@ tools. One such tool that is particularly recommended is the Linux
Cross-Reference project, which is able to present source code in a
self-referential, indexed webpage format. An excellent up-to-date
repository of the kernel code may be found at:
http://lxr.linux.no/+trees
http://lxr.free-electrons.com/
The development process
@ -250,11 +250,6 @@ process is as follows:
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- Known regressions in each release are periodically posted to the
linux-kernel mailing list. The goal is to reduce the length of
that list to zero before declaring the kernel to be "ready," but, in
the real world, a small number of regressions often remain at
release time.
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
@ -263,7 +258,7 @@ mailing list about kernel releases:
preconceived timeline."
4.x.y -stable kernel tree
---------------------------
-------------------------
Kernels with 3-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 4.x kernel.
@ -286,7 +281,7 @@ documents what kinds of changes are acceptable for the -stable tree, and
how the release process works.
4.x -git patches
------------------
----------------
These are daily snapshots of Linus' kernel tree which are managed in a
git repository (hence the name.) These patches are usually released
daily and represent the current state of Linus' tree. They are more
@ -318,7 +313,7 @@ accepted, or rejected. Most of these patchwork sites are listed at
http://patchwork.kernel.org/.
4.x -next kernel tree for integration tests
---------------------------------------------
-------------------------------------------
Before updates from subsystem trees are merged into the mainline 4.x
tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are

View file

@ -587,7 +587,7 @@ used to control it:
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x ifnum_to_use=n
nowayout=x ifnum_to_use=n panic_wdt_timeout=<t>
ifnum_to_use specifies which interface the watchdog timer should use.
The default is -1, which means to pick the first one registered.
@ -597,7 +597,9 @@ is the amount of seconds before the reset that the pre-timeout panic will
occur (if pretimeout is zero, then pretimeout will not be enabled). Note
that the pretimeout is the time before the final timeout. So if the
timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout
will occur in 40 second (10 seconds before the timeout).
will occur in 40 second (10 seconds before the timeout). The panic_wdt_timeout
is the value of timeout which is set on kernel panic, in order to let actions
such as kdump to occur during panic.
The action may be "reset", "power_cycle", or "power_off", and
specifies what to do when the timer times out, and defaults to
@ -634,6 +636,7 @@ for configuring the watchdog:
ipmi_watchdog.preop=<preop type>
ipmi_watchdog.start_now=x
ipmi_watchdog.nowayout=x
ipmi_watchdog.panic_wdt_timeout=<t>
The options are the same as the module parameter options.

View file

@ -3,7 +3,7 @@ Linux IOMMU Support
The architecture spec can be obtained from the below location.
http://www.intel.com/technology/virtualization/
http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
This guide gives a quick cheat sheet for some basic understanding.

View file

@ -1,4 +1,4 @@
subdir-y := accounting auxdisplay blackfin connector \
filesystems filesystems ia64 laptops mic misc-devices \
networking pcmcia prctl ptp spi timers vDSO video4linux \
networking pcmcia prctl ptp timers vDSO video4linux \
watchdog

Binary file not shown.

After

(image error) Size: 98 KiB

View file

@ -0,0 +1,374 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="447.99197"
height="428.19299"
id="svg2"
version="1.1"
inkscape:version="0.48.3.1 r9886"
sodipodi:docname="GPpartitionReaders1.svg">
<defs
id="defs4">
<marker
inkscape:stockid="Arrow2Lend"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lend"
style="overflow:visible">
<path
id="path3792"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow2Lstart"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lstart"
style="overflow:visible">
<path
id="path3789"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(1.1,0,0,1.1,1.1,0)"
inkscape:connector-curvature="0" />
</marker>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.6184291"
inkscape:cx="223.99599"
inkscape:cy="214.0965"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
inkscape:window-width="979"
inkscape:window-height="836"
inkscape:window-x="571"
inkscape:window-y="335"
inkscape:window-maximized="0"
fit-margin-top="5"
fit-margin-left="5"
fit-margin-right="5"
fit-margin-bottom="5" />
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-28.441125,-185.60612)">
<flowRoot
xml:space="preserve"
id="flowRoot2985"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion
id="flowRegion2987"><rect
id="rect2989"
width="82.85714"
height="11.428572"
x="240"
y="492.36218" /></flowRegion><flowPara
id="flowPara2991"></flowPara></flowRoot> <g
id="g4433"
transform="translate(2,0)">
<text
sodipodi:linespacing="125%"
id="text2993"
y="-261.66608"
x="412.12299"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
xml:space="preserve"
transform="matrix(0,1,-1,0,0,0)"><tspan
y="-261.66608"
x="412.12299"
id="tspan2995"
sodipodi:role="line">synchronize_rcu()</tspan></text>
<g
id="g4417"
transform="matrix(0,1,-1,0,730.90257,222.4928)">
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:url(#Arrow2Lend)"
d="m 97.580736,477.4048 183.140664,0"
id="path2997"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 96.752718,465.38398 0,22.62742"
id="path4397"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 281.54942,465.38397 0,22.62742"
id="path4397-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
</g>
</g>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.04738"
y="268.18076"
id="text4429"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431"
x="112.04738"
y="268.18076">WRITE_ONCE(a, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.04738"
y="439.13766"
id="text4441"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4443"
x="112.04738"
y="439.13766">WRITE_ONCE(b, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="255.60869"
y="309.29346"
id="text4445"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4447"
x="255.60869"
y="309.29346">r1 = READ_ONCE(a);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="255.14423"
y="520.61786"
id="text4449"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4451"
x="255.14423"
y="520.61786">WRITE_ONCE(c, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="384.71124"
id="text4453"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4455"
x="396.10254"
y="384.71124">r2 = READ_ONCE(b);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="582.13617"
id="text4457"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4459"
x="396.10254"
y="582.13617">r3 = READ_ONCE(c);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.08231"
y="213.91006"
id="text4461"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463"
x="112.08231"
y="213.91006">thread0()</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="252.34512"
y="213.91006"
id="text4461-6"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463-0"
x="252.34512"
y="213.91006">thread1()</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.42557"
y="213.91006"
id="text4461-2"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463-2"
x="396.42557"
y="213.91006">thread2()</tspan></text>
<rect
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect4495"
width="436.28488"
height="416.4859"
x="34.648232"
y="191.10612" />
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
d="m 183.14066,191.10612 0,417.193 -0.70711,0"
id="path4497"
inkscape:connector-curvature="0" />
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
d="m 325.13867,191.10612 0,417.193 -0.70711,0"
id="path4497-5"
inkscape:connector-curvature="0" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="111.75929"
y="251.53981"
id="text4429-8"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9"
x="111.75929"
y="251.53981">rcu_read_lock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="367.91556"
id="text4429-8-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4"
x="396.10254"
y="367.91556">rcu_read_lock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="597.40289"
id="text4429-8-9-3"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4-4"
x="396.10254"
y="597.40289">rcu_read_unlock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="111.75929"
y="453.15311"
id="text4429-8-9-3-1"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4-4-6"
x="111.75929"
y="453.15311">rcu_read_unlock();</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 33.941125,227.87568 436.284885,0 0,0.7071"
id="path4608"
inkscape:connector-curvature="0" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="394.94427"
y="345.66351"
id="text4648"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650"
x="394.94427"
y="345.66351">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(36.441125,199.60612)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.11968"
y="475.77856"
id="text4648-4"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-4"
x="112.11968"
y="475.77856">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-7"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(-246.38346,329.72117)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<path
sodipodi:type="arc"
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-7-7"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(-103.65246,202.90878)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="254.85066"
y="348.96619"
id="text4648-4-3"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-4-5"
x="254.85066"
y="348.96619">QS</tspan></text>
</g>
</svg>

After

(image error) Size: 17 KiB

View file

@ -0,0 +1,237 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Creator: fig2dev Version 3.2 Patchlevel 5d -->
<!-- CreationDate: Tue Mar 4 18:34:25 2014 -->
<!-- Magnification: 3.000 -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="1089.1382"
height="668.21368"
viewBox="-2121 -36 14554.634 8876.4061"
id="svg2"
version="1.1"
inkscape:version="0.48.3.1 r9886"
sodipodi:docname="RCUApplicability.svg">
<metadata
id="metadata40">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<defs
id="defs38" />
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="849"
inkscape:window-height="639"
id="namedview36"
showgrid="false"
inkscape:zoom="0.51326165"
inkscape:cx="544.56912"
inkscape:cy="334.10686"
inkscape:window-x="149"
inkscape:window-y="448"
inkscape:window-maximized="0"
inkscape:current-layer="g4"
fit-margin-top="5"
fit-margin-left="5"
fit-margin-right="5"
fit-margin-bottom="5" />
<g
style="fill:none;stroke-width:0.025in"
id="g4"
transform="translate(-2043.6828,14.791398)">
<!-- Line: box -->
<rect
x="0"
y="0"
width="14400"
height="8775"
rx="0"
style="fill:#ffa1a1;stroke:#000000;stroke-width:21;stroke-linecap:butt;stroke-linejoin:miter"
id="rect6" />
<!-- Line: box -->
<rect
x="1350"
y="0"
width="11700"
height="6075"
rx="0"
style="fill:#ffff00;stroke:#000000;stroke-width:21;stroke-linecap:butt;stroke-linejoin:miter"
id="rect8" />
<!-- Line: box -->
<rect
x="2700"
y="0"
width="9000"
height="4275"
rx="0"
style="fill:#00ff00;stroke:#000000;stroke-width:21;stroke-linecap:butt;stroke-linejoin:miter"
id="rect10" />
<!-- Line: box -->
<rect
x="4050"
y="0"
width="6300"
height="2475"
rx="0"
style="fill:#87cfff;stroke:#000000;stroke-width:21;stroke-linecap:butt;stroke-linejoin:miter"
id="rect12" />
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="900"
font-style="normal"
font-weight="normal"
font-size="324"
id="text14"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3017">Read-Mostly, Stale &amp;</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="1350"
font-style="normal"
font-weight="normal"
font-size="324"
id="text16"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3019">Inconsistent Data OK</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="1800"
font-style="normal"
font-weight="normal"
font-size="324"
id="text18"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3021">(RCU Works Great!!!)</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="3825"
font-style="normal"
font-weight="normal"
font-size="324"
id="text20"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3023">(RCU Works Well)</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="3375"
font-style="normal"
font-weight="normal"
font-size="324"
id="text22"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3025">Read-Mostly, Need Consistent Data</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="5175"
font-style="normal"
font-weight="normal"
font-size="324"
id="text24"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3027">Read-Write, Need Consistent Data</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="6975"
font-style="normal"
font-weight="normal"
font-size="324"
id="text26"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
sodipodi:linespacing="125%">Update-Mostly, Need Consistent Data</text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="5625"
font-style="normal"
font-weight="normal"
font-size="324"
id="text28"
sodipodi:linespacing="125%"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"><tspan
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
id="tspan3029">(RCU Might Be OK...)</tspan></text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="7875"
font-style="normal"
font-weight="normal"
font-size="324"
id="text30"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
sodipodi:linespacing="125%">(1) Provide Existence Guarantees For Update-Friendly Mechanisms</text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="8325"
font-style="normal"
font-weight="normal"
font-size="324"
id="text32"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
sodipodi:linespacing="125%">(2) Provide Wait-Free Read-Side Primitives for Real-Time Use)</text>
<!-- Text -->
<text
xml:space="preserve"
x="7200"
y="7425"
font-style="normal"
font-weight="normal"
font-size="324"
id="text34"
style="font-size:427.63009644px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;font-family:Nimbus Sans L;-inkscape-font-specification:Nimbus Sans L"
sodipodi:linespacing="125%">(RCU is Very Unlikely to be the Right Tool For The Job, But it Can:</text>
</g>
</svg>

After

(image error) Size: 10 KiB

View file

@ -0,0 +1,639 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="735.25"
height="516.21875"
id="svg2"
version="1.1"
inkscape:version="0.48.3.1 r9886"
sodipodi:docname="ReadersPartitionGP1.svg">
<defs
id="defs4">
<marker
inkscape:stockid="Arrow2Lend"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lend"
style="overflow:visible">
<path
id="path3792"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow2Lstart"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lstart"
style="overflow:visible">
<path
id="path3789"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(1.1,0,0,1.1,1.1,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow2Lstart"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lstart-4"
style="overflow:visible">
<path
id="path3789-9"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(1.1,0,0,1.1,1.1,0)"
inkscape:connector-curvature="0" />
</marker>
<marker
inkscape:stockid="Arrow2Lend"
orient="auto"
refY="0"
refX="0"
id="Arrow2Lend-4"
style="overflow:visible">
<path
id="path3792-4"
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
inkscape:connector-curvature="0" />
</marker>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.3670394"
inkscape:cx="367.26465"
inkscape:cy="258.46182"
inkscape:document-units="px"
inkscape:current-layer="g4433-6"
showgrid="false"
inkscape:window-width="1351"
inkscape:window-height="836"
inkscape:window-x="438"
inkscape:window-y="335"
inkscape:window-maximized="0"
fit-margin-top="5"
fit-margin-left="5"
fit-margin-right="5"
fit-margin-bottom="5" />
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-29.15625,-185.59375)">
<flowRoot
xml:space="preserve"
id="flowRoot2985"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion
id="flowRegion2987"><rect
id="rect2989"
width="82.85714"
height="11.428572"
x="240"
y="492.36218" /></flowRegion><flowPara
id="flowPara2991" /></flowRoot> <g
id="g4433"
transform="translate(2,-12)">
<text
sodipodi:linespacing="125%"
id="text2993"
y="-261.66608"
x="436.12299"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
xml:space="preserve"
transform="matrix(0,1,-1,0,0,0)"><tspan
y="-261.66608"
x="436.12299"
id="tspan2995"
sodipodi:role="line">synchronize_rcu()</tspan></text>
<g
id="g4417"
transform="matrix(0,1,-1,0,730.90257,222.4928)">
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:url(#Arrow2Lend)"
d="M 97.580736,477.4048 327.57913,476.09759"
id="path2997"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 96.752718,465.38398 0,22.62742"
id="path4397"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 328.40703,465.38397 0,22.62742"
id="path4397-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
</g>
</g>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.04738"
y="268.18076"
id="text4429"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431"
x="112.04738"
y="268.18076">WRITE_ONCE(a, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.04738"
y="487.13766"
id="text4441"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4443"
x="112.04738"
y="487.13766">WRITE_ONCE(b, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="255.60869"
y="297.29346"
id="text4445"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4447"
x="255.60869"
y="297.29346">r1 = READ_ONCE(a);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="255.14423"
y="554.61786"
id="text4449"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4451"
x="255.14423"
y="554.61786">WRITE_ONCE(c, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="370.71124"
id="text4453"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4455"
x="396.10254"
y="370.71124">WRITE_ONCE(d, 1);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="572.13617"
id="text4457"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4459"
x="396.10254"
y="572.13617">r2 = READ_ONCE(c);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.08231"
y="213.91006"
id="text4461"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463"
x="112.08231"
y="213.91006">thread0()</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="252.34512"
y="213.91006"
id="text4461-6"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463-0"
x="252.34512"
y="213.91006">thread1()</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.42557"
y="213.91006"
id="text4461-2"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463-2"
x="396.42557"
y="213.91006">thread2()</tspan></text>
<rect
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect4495"
width="724.25244"
height="505.21201"
x="34.648232"
y="191.10612" />
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
d="m 183.14066,191.10612 0,504.24243"
id="path4497"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
d="m 325.13867,191.10612 0,504.24243"
id="path4497-5"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="111.75929"
y="251.53981"
id="text4429-8"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9"
x="111.75929"
y="251.53981">rcu_read_lock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="353.91556"
id="text4429-8-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4"
x="396.10254"
y="353.91556">rcu_read_lock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="396.10254"
y="587.40289"
id="text4429-8-9-3"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4-4"
x="396.10254"
y="587.40289">rcu_read_unlock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="111.75929"
y="501.15311"
id="text4429-8-9-3-1"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4-4-6"
x="111.75929"
y="501.15311">rcu_read_unlock();</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 33.941125,227.87568 724.941765,0"
id="path4608"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="394.94427"
y="331.66351"
id="text4648"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650"
x="394.94427"
y="331.66351">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(36.441125,185.60612)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="112.11968"
y="523.77856"
id="text4648-4"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-4"
x="112.11968"
y="523.77856">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-7"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(-246.38346,377.72117)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<path
sodipodi:type="arc"
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-7-7"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(-103.65246,190.90878)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="254.85066"
y="336.96619"
id="text4648-4-3"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-4-5"
x="254.85066"
y="336.96619">QS</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
d="m 470.93311,190.39903 0,504.24243"
id="path4497-5-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
d="m 616.22755,190.38323 0,504.24243"
id="path4497-5-2"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<g
id="g4433-6"
transform="translate(288.0964,78.32827)">
<text
sodipodi:linespacing="125%"
id="text2993-7"
y="-261.66608"
x="440.12299"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
xml:space="preserve"
transform="matrix(0,1,-1,0,0,0)"><tspan
y="-261.66608"
x="440.12299"
id="tspan2995-1"
sodipodi:role="line">synchronize_rcu()</tspan></text>
<g
id="g4417-1"
transform="matrix(0,1,-1,0,730.90257,222.4928)">
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:url(#Arrow2Lend)"
d="M 97.580736,477.4048 328.5624,477.07246"
id="path2997-2"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 96.752718,465.38398 0,22.62742"
id="path4397-3"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m 329.39039,465.38397 0,22.62742"
id="path4397-5-4"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
</g>
</g>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="541.70508"
y="387.6217"
id="text4445-0"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4447-5"
x="541.70508"
y="387.6217">r3 = READ_ONCE(d);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="541.2406"
y="646.94611"
id="text4449-6"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4451-6"
x="541.2406"
y="646.94611">WRITE_ONCE(e, 1);</tspan></text>
<path
sodipodi:type="arc"
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-7-7-5"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(182.44393,281.23704)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="540.94702"
y="427.29443"
id="text4648-4-3-1"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-4-5-7"
x="540.94702"
y="427.29443">QS</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="686.27747"
y="461.83929"
id="text4453-7"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4455-1"
x="686.27747"
y="461.83929">r4 = READ_ONCE(b);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="686.27747"
y="669.26422"
id="text4457-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4459-2"
x="686.27747"
y="669.26422">r5 = READ_ONCE(e);</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="686.27747"
y="445.04358"
id="text4429-8-9-33"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4-2"
x="686.27747"
y="445.04358">rcu_read_lock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="686.27747"
y="684.53094"
id="text4429-8-9-3-8"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4431-9-4-4-5"
x="686.27747"
y="684.53094">rcu_read_unlock();</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="685.11914"
y="422.79153"
id="text4648-9"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-7"
x="685.11914"
y="422.79153">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-8"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(326.61602,276.73415)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="397.85934"
y="609.59003"
id="text4648-5"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-77"
x="397.85934"
y="609.59003">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-80"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(39.356201,463.53264)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="256.75986"
y="586.99133"
id="text4648-5-2"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4650-77-7"
x="256.75986"
y="586.99133">QS</tspan></text>
<path
sodipodi:type="arc"
style="fill:none;stroke:#000000;stroke-width:1;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="path4652-80-5"
sodipodi:cx="358.85669"
sodipodi:cy="142.87541"
sodipodi:rx="10.960155"
sodipodi:ry="10.253048"
d="m 358.86939,132.62237 a 10.960155,10.253048 0 1 1 -0.0228,0"
transform="translate(-101.74328,440.93395)"
sodipodi:start="4.7135481"
sodipodi:end="10.994651"
sodipodi:open="true" />
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="546.22791"
y="213.91006"
id="text4461-2-5"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463-2-6"
x="546.22791"
y="213.91006">thread3()</tspan></text>
<text
xml:space="preserve"
style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"
x="684.00067"
y="213.91006"
id="text4461-2-1"
sodipodi:linespacing="125%"><tspan
sodipodi:role="line"
id="tspan4463-2-0"
x="684.00067"
y="213.91006">thread4()</tspan></text>
</g>
</svg>

After

(image error) Size: 29 KiB

File diff suppressed because it is too large Load diff

File diff suppressed because it is too large Load diff

View file

@ -0,0 +1,108 @@
#!/bin/sh
#
# Usage: sh htmlqqz.sh file
#
# Extracts and converts quick quizzes in a proto-HTML document file.htmlx.
# Commands, all of which must be on a line by themselves:
#
# "<p>@@QQ@@": Start of a quick quiz.
# "<p>@@QQA@@": Start of a quick-quiz answer.
# "<p>@@QQE@@": End of a quick-quiz answer, and thus of the quick quiz.
# "<p>@@QQAL@@": Place to put quick-quiz answer list.
#
# Places the result in file.html.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, you can access it online at
# http://www.gnu.org/licenses/gpl-2.0.html.
#
# Copyright (c) 2013 Paul E. McKenney, IBM Corporation.
fn=$1
if test ! -r $fn.htmlx
then
echo "Error: $fn.htmlx unreadable."
exit 1
fi
echo "<!-- DO NOT HAND EDIT. -->" > $fn.html
echo "<!-- Instead, edit $fn.htmlx and run 'sh htmlqqz.sh $fn' -->" >> $fn.html
awk < $fn.htmlx >> $fn.html '
state == "" && $1 != "<p>@@QQ@@" && $1 != "<p>@@QQAL@@" {
print $0;
if ($0 ~ /^<p>@@QQ/)
print "Bad Quick Quiz command: " NR " (expected <p>@@QQ@@ or <p>@@QQAL@@)." > "/dev/stderr"
next;
}
state == "" && $1 == "<p>@@QQ@@" {
qqn++;
qqlineno = NR;
haveqq = 1;
state = "qq";
print "<p><a name=\"Quick Quiz " qqn "\"><b>Quick Quiz " qqn "</b>:</a>"
next;
}
state == "qq" && $1 != "<p>@@QQA@@" {
qq[qqn] = qq[qqn] $0 "\n";
print $0
if ($0 ~ /^<p>@@QQ/)
print "Bad Quick Quiz command: " NR ". (expected <p>@@QQA@@)" > "/dev/stderr"
next;
}
state == "qq" && $1 == "<p>@@QQA@@" {
state = "qqa";
print "<br><a href=\"#qq" qqn "answer\">Answer</a>"
next;
}
state == "qqa" && $1 != "<p>@@QQE@@" {
qqa[qqn] = qqa[qqn] $0 "\n";
if ($0 ~ /^<p>@@QQ/)
print "Bad Quick Quiz command: " NR " (expected <p>@@QQE@@)." > "/dev/stderr"
next;
}
state == "qqa" && $1 == "<p>@@QQE@@" {
state = "";
next;
}
state == "" && $1 == "<p>@@QQAL@@" {
haveqq = "";
print "<h3><a name=\"Answers to Quick Quizzes\">"
print "Answers to Quick Quizzes</a></h3>"
print "";
for (i = 1; i <= qqn; i++) {
print "<a name=\"qq" i "answer\"></a>"
print "<p><b>Quick Quiz " i "</b>:"
print qq[i];
print "";
print "</p><p><b>Answer</b>:"
print qqa[i];
print "";
print "</p><p><a href=\"#Quick%20Quiz%20" i "\"><b>Back to Quick Quiz " i "</b>.</a>"
print "";
}
next;
}
END {
if (state != "")
print "Unterminated Quick Quiz: " qqlineno "." > "/dev/stderr"
else if (haveqq)
print "Missing \"<p>@@QQAL@@\", no Quick Quiz." > "/dev/stderr"
}'

View file

@ -718,8 +718,21 @@ generates appropriate diffstats by default.)
See more details on the proper patch format in the following
references.
15) Explicit In-Reply-To headers
--------------------------------
15) Sending "git pull" requests
It can be helpful to manually add In-Reply-To: headers to a patch
(e.g., when using "git send-email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the
series. This way multiple versions of the patch don't become an
unmanageable forest of references in email clients. If a link is
helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in
the cover email text) to link to an earlier version of the patch series.
16) Sending "git pull" requests
-------------------------------
If you have a series of patches, it may be most convenient to have the

View file

@ -375,7 +375,8 @@ int main(int argc, char *argv[])
}
}
if ((nl_sd = create_nl_socket(NETLINK_GENERIC)) < 0)
nl_sd = create_nl_socket(NETLINK_GENERIC);
if (nl_sd < 0)
err(1, "error creating Netlink socket\n");

View file

@ -0,0 +1,58 @@
ACPI I2C Muxes
--------------
Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
Device () scope per mux channel.
Consider this topology:
+------+ +------+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+------+ +------+
which corresponds to the following ASL:
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^SMB1", 0x00,
ResourceConsumer,,)
}
Device (CH00)
{
Name (_ADR, 0)
Device (CLIA)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH00", 0x00,
ResourceConsumer,,)
}
}
}
Device (CH01)
{
Name (_ADR, 1)
Device (CLIB)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH01", 0x00,
ResourceConsumer,,)
}
}
}
}
}

View file

@ -22,7 +22,7 @@ Orion family
88F5281
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
88F6183
Core: Feroceon ARMv5 compatible
Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-orion5x
Linux kernel plat directory: arch/arm/plat-orion
@ -52,7 +52,7 @@ Kirkwood family
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_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/
Core: Feroceon ARMv5 compatible
Core: Feroceon 88fr131 ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
@ -71,7 +71,7 @@ Discovery family
MV76100
Not supported by the Linux kernel.
Core: Feroceon ARMv5 compatible
Core: Feroceon 88fr571-vd ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-mv78xx0
Linux kernel plat directory: arch/arm/plat-orion
@ -86,20 +86,26 @@ EBU Armada family
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
Core: Sheeva ARMv7 compatible PJ4B
Armada 375 Flavors:
88F6720
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
Core: ARM Cortex-A9
Armada 380/385 Flavors:
88F6810
88F6820
88F6828
Armada 38x Flavors:
88F6810 Armada 380
88F6820 Armada 385
88F6828 Armada 388
Product infos: http://www.marvell.com/embedded-processors/armada-38x/
Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
Core: ARM Cortex-A9
Armada 390/398 Flavors:
88F6920
88F6928
Armada 39x Flavors:
88F6920 Armada 390
88F6928 Armada 398
Product infos: http://www.marvell.com/embedded-processors/armada-39x/
Core: ARM Cortex-A9
Armada XP Flavors:
MV78230
@ -112,12 +118,43 @@ EBU Armada family
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core: Sheeva ARMv7 compatible
Core: Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
EBU Armada family ARMv8
-----------------------
Armada 3710/3720 Flavors:
88F3710
88F3720
Core: ARM Cortex A53 (ARMv8)
Homepage: http://www.marvell.com/embedded-processors/armada-3700/
Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-37*
Armada 7K Flavors:
88F7020 (AP806 Dual + one CP110)
88F7040 (AP806 Quad + one CP110)
Core: ARM Cortex A72
Homepage: http://www.marvell.com/embedded-processors/armada-70xx/
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-70*
Armada 8K Flavors:
88F8020 (AP806 Dual + two CP110)
88F8040 (AP806 Quad + two CP110)
Core: ARM Cortex A72
Homepage: http://www.marvell.com/embedded-processors/armada-80xx/
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-80*
Avanta family
-------------
@ -135,6 +172,15 @@ Avanta family
Linux kernel mach directory: no code in mainline yet, planned for the future
Linux kernel plat directory: no code in mainline yet, planned for the future
Storage family
--------------
Armada SP:
88RC1580
Product infos: http://www.marvell.com/storage/armada-sp/
Core: Sheeva ARMv7 comatible Quad-core PJ4C
(not supported in upstream Linux kernel)
Dove family (application processor)
-----------------------------------
@ -155,7 +201,7 @@ PXA 2xx/3xx/93x/95x family
Flavors:
PXA21x, PXA25x, PXA26x
Application processor only
Core: ARMv5 XScale core
Core: ARMv5 XScale1 core
PXA270, PXA271, PXA272
Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
@ -163,7 +209,7 @@ PXA 2xx/3xx/93x/95x family
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
Specification update : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
Application processor only
Core: ARMv5 XScale core
Core: ARMv5 XScale2 core
PXA300, PXA310, PXA320
PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
@ -174,10 +220,10 @@ PXA 2xx/3xx/93x/95x family
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
Reference Manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
Application processor only
Core: ARMv5 XScale core
Core: ARMv5 XScale3 core
PXA930, PXA935
Application processor with Communication processor
Core: ARMv5 XScale core
Core: ARMv5 XScale3 core
PXA955
Application processor with Communication processor
Core: ARMv7 compatible Sheeva PJ4 core
@ -196,7 +242,7 @@ PXA 2xx/3xx/93x/95x family
Linux kernel mach directory: arch/arm/mach-pxa
Linux kernel plat directory: arch/arm/plat-pxa
MMP/MMP2 family (communication processor)
MMP/MMP2/MMP3 family (communication processor)
-----------------------------------------
Flavors:
@ -209,16 +255,32 @@ MMP/MMP2 family (communication processor)
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
App node package : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
Application processor only
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
PXA910
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
PXA910/PXA920
Homepage : http://www.marvell.com/communication-processors/pxa910/
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
Application processor with Communication processor
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
MMP2, a.k.a Armada 610
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
PXA688, a.k.a. MMP2, a.k.a Armada 610
Product Brief : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
Application processor only
Core: ARMv7 compatible Sheeva PJ4 core
Core: ARMv7 compatible Sheeva PJ4 88sv581x core
PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream)
Product Brief : http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
Application processor only
Core: Dual-core ARMv7 compatible Sheeva PJ4C core
PXA960/PXA968/PXA978 (Linux support not upstream)
Application processor with Communication Processor
Core: ARMv7 compatible Sheeva PJ4 core
PXA986/PXA988 (Linux support not upstream)
Application processor with Communication Processor
Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
PXA1088/PXA1920 (Linux support not upstream)
Application processor with Communication Processor
Core: quad-core ARMv7 Cortex-A7
PXA1908/PXA1928/PXA1936
Application processor with Communication Processor
Core: multi-core ARMv8 Cortex-A53
Comments:
@ -233,35 +295,85 @@ MMP/MMP2 family (communication processor)
Linux kernel mach directory: arch/arm/mach-mmp
Linux kernel plat directory: arch/arm/plat-pxa
Berlin family (Digital Entertainment)
Berlin family (Multimedia Solutions)
-------------------------------------
Flavors:
88DE3010, Armada 1000 (no Linux support)
Core: Marvell PJ1 (ARMv5TE), Dual-core
Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf
88DE3005, Armada 1500-mini
88DE3005, Armada 1500 Mini
Design name: BG2CD
Core: ARM Cortex-A9, PL310 L2CC
Homepage: http://www.marvell.com/digital-entertainment/armada-1500-mini/
Homepage: http://www.marvell.com/multimedia-solutions/armada-1500-mini/
88DE3006, Armada 1500 Mini Plus
Design name: BG2CDP
Core: Dual Core ARM Cortex-A7
Homepage: http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
88DE3100, Armada 1500
Design name: BG2
Core: Marvell PJ4B (ARMv7), Tauros3 L2CC
Homepage: http://www.marvell.com/digital-entertainment/armada-1500/
Core: Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
Design name: BG2-Q
Design name: BG2Q
Core: Quad Core ARM Cortex-A9, PL310 L2CC
Homepage: http://www.marvell.com/digital-entertainment/armada-1500-pro/
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
88DE????
88DE3214, Armada 1500 Pro 4K
Design name: BG3
Core: ARM Cortex-A15, CA15 integrated L2CC
88DE3218, ARMADA 1500 Ultra
Core: ARM Cortex-A53
Homepage: http://www.marvell.com/digital-entertainment/
Homepage: http://www.marvell.com/multimedia-solutions/
Directory: arch/arm/mach-berlin
Comments:
* This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
CPU Cores
---------
The XScale cores were designed by Intel, and shipped by Marvell in the older
PXA processors. Feroceon is a Marvell designed core that developed in-house,
and that evolved into Sheeva. The XScale and Feroceon cores were phased out
over time and replaced with Sheeva cores in later products, which subsequently
got replaced with licensed ARM Cortex-A cores.
XScale 1
CPUID 0x69052xxx
ARMv5, iWMMXt
XScale 2
CPUID 0x69054xxx
ARMv5, iWMMXt
XScale 3
CPUID 0x69056xxx or 0x69056xxx
ARMv5, iWMMXt
Feroceon-1850 88fr331 "Mohawk"
CPUID 0x5615331x or 0x41xx926x
ARMv5TE, single issue
Feroceon-2850 88fr531-vd "Jolteon"
CPUID 0x5605531x or 0x41xx926x
ARMv5TE, VFP, dual-issue
Feroceon 88fr571-vd "Jolteon"
CPUID 0x5615571x
ARMv5TE, VFP, dual-issue
Feroceon 88fr131 "Mohawk-D"
CPUID 0x5625131x
ARMv5TE, single-issue in-order
Sheeva PJ1 88sv331 "Mohawk"
CPUID 0x561584xx
ARMv5, single-issue iWMMXt v2
Sheeva PJ4 88sv581x "Flareon"
CPUID 0x560f581x
ARMv7, idivt, optional iWMMXt v2
Sheeva PJ4B 88sv581x
CPUID 0x561f581x
ARMv7, idivt, optional iWMMXt v2
Sheeva PJ4B-MP / PJ4C
CPUID 0x562f584x
ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON
Long-term plans
---------------

View file

@ -19,7 +19,7 @@ executing kernel.
Address: sysram_ns_base_addr
Offset Value Purpose
=============================================================================
0x08 exynos_cpu_resume_ns System suspend
0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend
0x0c 0x00000bad (Magic cookie) System suspend
0x1c exynos4_secondary_startup Secondary CPU boot
0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
@ -56,7 +56,8 @@ Offset Value Purpose
Address: pmu_base_addr
Offset Value Purpose
=============================================================================
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
0x0908 Non-zero Secondary CPU boot up indicator
on Exynos3250 and Exynos542x
4. Glossary

View file

@ -41,7 +41,7 @@ function find_length(f)
else if (f ~ /0xf/)
return 4
printf "unknown legnth " f "\n" > "/dev/stderr"
printf "unknown length " f "\n" > "/dev/stderr"
exit
}

View file

@ -49,24 +49,6 @@ specified through DTS. Following are the DTS used:-
The device tree documentation for the keystone machines are located at
Documentation/devicetree/bindings/arm/keystone/keystone.txt
Known issues & workaround
-------------------------
Some of the device drivers used on keystone are re-used from that from
DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
Some of the keystone specific drivers such as netcp uses run time power
management API instead to enable clock. As this API has limitations on
keystone, following workaround is needed to boot Linux.
Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
clock frameworks will try to disable clocks that are unused and disable
the hardware. This is because netcp related power domain and clock
domains are enabled in u-boot as run time power management API currently
doesn't enable clocks for netcp due to a limitation. This workaround is
expected to be removed in the future when proper API support becomes
available. Until then, this work around is needed.
Document Author
---------------
Murali Karicheri <m-karicheri2@ti.com>

View file

@ -0,0 +1,56 @@
* Texas Instruments Keystone Navigator Queue Management SubSystem driver
Driver source code path
drivers/soc/ti/knav_qmss.c
drivers/soc/ti/knav_qmss_acc.c
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
DT documentation is available at
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
Accumulator QMSS queues using PDSP firmware
============================================
The QMSS PDSP firmware support accumulator channel that can monitor a single
queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
driver that interface with the accumulator PDSP. This configures
accumulator channels defined in DTS (example in DT documentation) to monitor
1 or 32 queues per channel. More description on the firmware is available in
CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
git://git.ti.com/keystone-rtos/qmss-lld.git
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
channels. This firmware is available under ti-keystone folder of
firmware.git at
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
To use copy the firmware image to lib/firmware folder of the initramfs or
ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
Use of accumulated queues requires the firmware image to be present in the
file system. The driver doesn't acc queues to the supported queue range if
PDSP is not running in the SoC. The API call fails if there is a queue open
request to an acc queue and PDSP is not running. So make sure to copy firmware
to file system before using these queue types.

View file

@ -49,7 +49,7 @@ to this new MFP mechanism, here are several key points:
internal controllers like PWM, SSP and UART, with 128 internal signals
which can be routed to external through one or more MFPs (e.g. GPIO<0>
can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2,
see arch/arm/mach-pxa/mach/include/mfp-pxa300.h)
see arch/arm/mach-pxa/mfp-pxa300.h)
2. Alternate function configuration is removed from this GPIO controller,
the remaining functions are pure GPIO-specific, i.e.
@ -76,11 +76,11 @@ For board code writers, here are some guidelines:
1. include ONE of the following header files in your <board>.c:
- #include <mach/mfp-pxa25x.h>
- #include <mach/mfp-pxa27x.h>
- #include <mach/mfp-pxa300.h>
- #include <mach/mfp-pxa320.h>
- #include <mach/mfp-pxa930.h>
- #include "mfp-pxa25x.h"
- #include "mfp-pxa27x.h"
- #include "mfp-pxa300.h"
- #include "mfp-pxa320.h"
- #include "mfp-pxa930.h"
NOTE: only one file in your <board>.c, depending on the processors used,
because pin configuration definitions may conflict in these file (i.e.
@ -203,20 +203,20 @@ make them effective there-after.
1. Unified pin definitions - enum constants for all configurable pins
2. processor-neutral bit definitions for a possible MFP configuration
- arch/arm/mach-pxa/include/mach/mfp-pxa3xx.h
- arch/arm/mach-pxa/mfp-pxa3xx.h
for PXA3xx specific MFPR register bit definitions and PXA3xx common pin
configurations
- arch/arm/mach-pxa/include/mach/mfp-pxa2xx.h
- arch/arm/mach-pxa/mfp-pxa2xx.h
for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations
- arch/arm/mach-pxa/include/mach/mfp-pxa25x.h
arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
arch/arm/mach-pxa/include/mach/mfp-pxa300.h
arch/arm/mach-pxa/include/mach/mfp-pxa320.h
arch/arm/mach-pxa/include/mach/mfp-pxa930.h
- arch/arm/mach-pxa/mfp-pxa25x.h
arch/arm/mach-pxa/mfp-pxa27x.h
arch/arm/mach-pxa/mfp-pxa300.h
arch/arm/mach-pxa/mfp-pxa320.h
arch/arm/mach-pxa/mfp-pxa930.h
for processor specific definitions

View file

@ -25,7 +25,7 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
- Allwinner A13 (sun5i)
- Allwinner A13 / R8 (sun5i)
+ Datasheet
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ User Manual
@ -72,6 +72,5 @@ SunXi family
* Octa ARM Cortex-A7 based SoCs
- Allwinner A83T
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A83T/A83T_datasheet_Revision_1.1.pdf

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