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:
commit
9938b04472
17915 changed files with 1320089 additions and 707228 deletions
.mailmapCREDITSCodingStyleDMA-API-HOWTO.txtDMA-API.txtDMA-attributes.txtSubmittingPatches
Documentation
ABI
obsolete
removed
stable
testing
configfs-iioconfigfs-rdma_cmconfigfs-usb-gadget-sourcesinkconfigfs-usb-gadget-tcmgpio-cdevima_policysysfs-bus-iiosysfs-bus-iio-health-afe440xsysfs-bus-iio-ina2xx-adcsysfs-bus-iio-magnetometer-hmc5843sysfs-bus-iio-vf610sysfs-bus-usbsysfs-class-cxlsysfs-class-infinibandsysfs-class-net-batman-advsysfs-class-net-cdc_ncmsysfs-class-net-meshsysfs-class-net-qmisysfs-class-rc-nuvotonsysfs-class-watchdogsysfs-devices-system-cpusysfs-driver-stsysfs-driver-toshiba_acpisysfs-firmware-qemu_fw_cfgsysfs-fs-f2fssysfs-kernel-livepatchsysfs-platform-hidma-mgmtsysfs-platform-i2c-demux-pinctrl
DocBook
Makefilecrypto-API.tmpldevice-drivers.tmpldrm.tmplgpu.tmpliio.tmpl
HOWTOIPMI.txtIntel-IOMMU.txtMakefilemedia
Makefile
media_api.tmplmtdnand.tmplusb.tmpldvb
v4l
capture.c.xmlcompat.xmlcontrols.xmlio.xmlmedia-controller.xmlmedia-ioc-enum-entities.xmlmedia-ioc-enum-links.xmlmedia-ioc-g-topology.xmlmedia-types.xmlpixfmt-y12i.xmlpixfmt-y8i.xmlpixfmt-yuv420m.xmlpixfmt-yuv422m.xmlpixfmt-yuv444m.xmlpixfmt-yvu420m.xmlpixfmt-z16.xmlpixfmt.xmlv4l2.xmlvidioc-create-bufs.xmlvidioc-dbg-g-chip-info.xmlvidioc-dbg-g-register.xmlvidioc-enumstd.xmlvidioc-g-ext-ctrls.xmlvidioc-query-dv-timings.xmlvidioc-querystd.xml
RCU/Design
Requirements
2013-08-is-it-dead.pngGPpartitionReaders1.svgRCUApplicability.svgReadersPartitionGP1.svgRequirements.htmlRequirements.htmlx
htmlqqz.shaccounting
acpi
arm
Marvell
Samsung
keystone
pxa
sunxi
2
.mailmap
2
.mailmap
|
@ -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
20
CREDITS
|
@ -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
|
||||
|
|
|
@ -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
|
|
@ -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.
|
13
Documentation/ABI/removed/sysfs-class-rfkill
Normal file
13
Documentation/ABI/removed/sysfs-class-rfkill
Normal 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
|
|
@ -100,4 +100,5 @@ Description:
|
|||
|
||||
Users: libraw1394
|
||||
libdc1394
|
||||
tools like jujuutils, fwhack, ...
|
||||
libhinawa
|
||||
tools like linux-firewire-utils, fwhack, ...
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
87
Documentation/ABI/stable/sysfs-fs-orangefs
Normal file
87
Documentation/ABI/stable/sysfs-fs-orangefs
Normal 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.
|
21
Documentation/ABI/testing/configfs-iio
Normal file
21
Documentation/ABI/testing/configfs-iio
Normal 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.
|
22
Documentation/ABI/testing/configfs-rdma_cm
Normal file
22
Documentation/ABI/testing/configfs-rdma_cm
Normal 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.
|
|
@ -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
|
||||
|
|
6
Documentation/ABI/testing/configfs-usb-gadget-tcm
Normal file
6
Documentation/ABI/testing/configfs-usb-gadget-tcm
Normal 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.
|
26
Documentation/ABI/testing/gpio-cdev
Normal file
26
Documentation/ABI/testing/gpio-cdev
Normal 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
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
54
Documentation/ABI/testing/sysfs-bus-iio-health-afe440x
Normal file
54
Documentation/ABI/testing/sysfs-bus-iio-health-afe440x
Normal 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.
|
24
Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc
Normal file
24
Documentation/ABI/testing/sysfs-bus-iio-ina2xx-adc
Normal 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.
|
15
Documentation/ABI/testing/sysfs-bus-iio-magnetometer-hmc5843
Normal file
15
Documentation/ABI/testing/sysfs-bus-iio-magnetometer-hmc5843
Normal 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.
|
|
@ -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.
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
16
Documentation/ABI/testing/sysfs-class-infiniband
Normal file
16
Documentation/ABI/testing/sysfs-class-infiniband
Normal 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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
23
Documentation/ABI/testing/sysfs-class-net-qmi
Normal file
23
Documentation/ABI/testing/sysfs-class-net-qmi
Normal 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.
|
15
Documentation/ABI/testing/sysfs-class-rc-nuvoton
Normal file
15
Documentation/ABI/testing/sysfs-class-rc-nuvoton
Normal 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.
|
51
Documentation/ABI/testing/sysfs-class-watchdog
Normal file
51
Documentation/ABI/testing/sysfs-class-watchdog
Normal 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.
|
|
@ -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.
|
||||
|
|
12
Documentation/ABI/testing/sysfs-driver-st
Normal file
12
Documentation/ABI/testing/sysfs-driver-st
Normal 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.
|
|
@ -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
|
||||
|
|
100
Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
Normal file
100
Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
Normal 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.
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
97
Documentation/ABI/testing/sysfs-platform-hidma-mgmt
Normal file
97
Documentation/ABI/testing/sysfs-platform-hidma-mgmt
Normal 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.
|
18
Documentation/ABI/testing/sysfs-platform-i2c-demux-pinctrl
Normal file
18
Documentation/ABI/testing/sysfs-platform-i2c-demux-pinctrl
Normal 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'.
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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->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->req);
|
||||
rc = crypto_skcipher_encrypt(sk->req);
|
||||
else
|
||||
rc = crypto_ablkcipher_decrypt(ablk->req);
|
||||
rc = crypto_skcipher_decrypt(sk->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(
|
||||
&ablk->result.completion);
|
||||
if (!rc && !ablk->result.err) {
|
||||
reinit_completion(&ablk->result.completion);
|
||||
&sk->result.completion);
|
||||
if (!rc && !sk->result.err) {
|
||||
reinit_completion(&sk->result.completion);
|
||||
break;
|
||||
}
|
||||
default:
|
||||
pr_info("ablkcipher encrypt returned with %d result %d\n",
|
||||
rc, ablk->result.err);
|
||||
pr_info("skcipher encrypt returned with %d result %d\n",
|
||||
rc, sk->result.err);
|
||||
break;
|
||||
}
|
||||
init_completion(&ablk->result.completion);
|
||||
init_completion(&sk->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,
|
||||
&ablk.result);
|
||||
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
|
||||
test_skcipher_cb,
|
||||
&sk.result);
|
||||
|
||||
/* AES 256 with random key */
|
||||
get_random_bytes(&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(&ablk.sg, scratchpad, 16);
|
||||
ablkcipher_request_set_crypt(req, &ablk.sg, &ablk.sg, 16, ivdata);
|
||||
init_completion(&ablk.result.completion);
|
||||
sg_init_one(&sk.sg, scratchpad, 16);
|
||||
skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
|
||||
init_completion(&sk.result.completion);
|
||||
|
||||
/* encrypt data */
|
||||
ret = test_ablkcipher_encdec(&ablk, 1);
|
||||
ret = test_skcipher_encdec(&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(&sg, scratchpad, crypto_blkcipher_blocksize(blkcipher));
|
||||
|
||||
/* encrypt data in place */
|
||||
crypto_blkcipher_encrypt(&desc, &sg, &sg,
|
||||
crypto_blkcipher_blocksize(blkcipher));
|
||||
|
||||
/* decrypt data in place
|
||||
* crypto_blkcipher_decrypt(&desc, &sg, &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>
|
||||
|
||||
|
|
|
@ -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 “function is not available”.</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
|
||||
“bottom half” 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
3521
Documentation/DocBook/gpu.tmpl
Normal file
3521
Documentation/DocBook/gpu.tmpl
Normal file
File diff suppressed because it is too large
Load diff
|
@ -458,7 +458,7 @@
|
|||
.scan_type = {
|
||||
.sign = 's',
|
||||
.realbits = 12,
|
||||
.storgebits = 16,
|
||||
.storagebits = 16,
|
||||
.shift = 4,
|
||||
.endianness = IIO_LE,
|
||||
},
|
||||
|
|
|
@ -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 $< >$@
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 <stdio.h>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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> </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> </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 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> </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> </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> </entry>
|
||||
<entry>Cinema content.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant> </entry>
|
||||
<entry>Game content. Audio and video latency should be minimized.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant> </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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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;
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
391
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
Normal file
391
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
Normal 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>
|
315
Documentation/DocBook/media/v4l/media-types.xml
Normal file
315
Documentation/DocBook/media/v4l/media-types.xml
Normal 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>
|
49
Documentation/DocBook/media/v4l/pixfmt-y12i.xml
Normal file
49
Documentation/DocBook/media/v4l/pixfmt-y12i.xml
Normal 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 & *(__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>
|
80
Documentation/DocBook/media/v4l/pixfmt-y8i.xml
Normal file
80
Documentation/DocBook/media/v4l/pixfmt-y8i.xml
Normal 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 × 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 + 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 + 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 + 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 + 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>
|
|
@ -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>
|
||||
|
||||
|
|
166
Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml
Normal file
166
Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml
Normal 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 ½ 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 × 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 + 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 + 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 + 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 + 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 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 4:</entry>
|
||||
<entry>Cb<subscript>20</subscript></entry>
|
||||
<entry>Cb<subscript>21</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 6:</entry>
|
||||
<entry>Cb<subscript>30</subscript></entry>
|
||||
<entry>Cb<subscript>31</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 4:</entry>
|
||||
<entry>Cr<subscript>20</subscript></entry>
|
||||
<entry>Cr<subscript>21</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 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>
|
177
Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml
Normal file
177
Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml
Normal 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 × 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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>
|
|
@ -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 × 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 + 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 + 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 + 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 + 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 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 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>
|
81
Documentation/DocBook/media/v4l/pixfmt-z16.xml
Normal file
81
Documentation/DocBook/media/v4l/pixfmt-z16.xml
Normal 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 × 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 + 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 + 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 + 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 + 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>
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 |\
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
||||
|
|
|
@ -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 &= ~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 &= ~BOARD_NAND_ADDR_MASK;
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
BIN
Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png
Normal file
BIN
Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png
Normal file
Binary file not shown.
After ![]() (image error) Size: 98 KiB |
374
Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg
Normal file
374
Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg
Normal 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 |
237
Documentation/RCU/Design/Requirements/RCUApplicability.svg
Normal file
237
Documentation/RCU/Design/Requirements/RCUApplicability.svg
Normal 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 &</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 |
639
Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg
Normal file
639
Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg
Normal 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 |
2897
Documentation/RCU/Design/Requirements/Requirements.html
Normal file
2897
Documentation/RCU/Design/Requirements/Requirements.html
Normal file
File diff suppressed because it is too large
Load diff
2741
Documentation/RCU/Design/Requirements/Requirements.htmlx
Normal file
2741
Documentation/RCU/Design/Requirements/Requirements.htmlx
Normal file
File diff suppressed because it is too large
Load diff
108
Documentation/RCU/Design/htmlqqz.sh
Executable file
108
Documentation/RCU/Design/htmlqqz.sh
Executable 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"
|
||||
}'
|
|
@ -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
|
||||
|
|
|
@ -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");
|
||||
|
||||
|
||||
|
|
58
Documentation/acpi/i2c-muxes.txt
Normal file
58
Documentation/acpi/i2c-muxes.txt
Normal 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,,)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
|
@ -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
|
||||
---------------
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
}
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
56
Documentation/arm/keystone/knav-qmss.txt
Normal file
56
Documentation/arm/keystone/knav-qmss.txt
Normal 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.
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
Loading…
Add table
Reference in a new issue