mirror of
https://github.com/brain-hackers/linux-brain.git
synced 2024-06-09 15:26:21 +09:00
Linux 4.5
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJW5j4RAAoJEHm+PkMAQRiGhVEH/0qZbM1J+WnCK92bm9+inCnB JO2JViGIuCQB5BxljVMil2dzrw85D+dC7+fryr0wVBhhBlr0lXPJGSYCYYTEaI20 Wco5YlTmjRirUwmxWzBXvB5kvTdIaNfNYDcFch6lbsaLUNgqydNKtk08ckO/4k0D AmaShW8swBiXE/RmHuj8H41ksHsnY8W62dlczEaAIfr4kluPX/kKnyXpmpvmZm1j sM4fskPlq+Jz5pOXXFsFfrhiBgpSUnwSj1tNwK5+DkmaVnWOkPuwkqLBWqpy4pzm GTeDBdf5/ixGxgNsZ2VWtbPnc2wEP7SIcu45MU7QFw5kqwDN2nN63BRVXI5Z5qY= =RFx2 -----END PGP SIGNATURE----- Orangefs: merge to v4.5 Merge tag 'v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into current Linux 4.5
This commit is contained in:
Mike Marshall
commit
ab6652524a
1
.mailmap
1
.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>
|
||||
|
|
|
|||
19
CREDITS
19
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
|
||||
|
|
|
|||
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.
|
||||
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.
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
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.
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
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.
|
||||
|
|
@ -87,6 +87,12 @@ 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>
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Description:
|
|||
assignment may be changed by two writing numbers into
|
||||
the file.
|
||||
|
||||
What: /sys/class/ptp/ptpN/pps_avaiable
|
||||
What: /sys/class/ptp/ptpN/pps_available
|
||||
Date: September 2010
|
||||
Contact: Richard Cochran <richardcochran@gmail.com>
|
||||
Description:
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -236,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).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -238,83 +238,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
|
||||
|
|
|
|||
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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
394
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
Normal file
394
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
Normal file
|
|
@ -0,0 +1,394 @@
|
|||
<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><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para>
|
||||
|
||||
<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>
|
||||
236
Documentation/DocBook/media/v4l/media-types.xml
Normal file
236
Documentation/DocBook/media/v4l/media-types.xml
Normal file
|
|
@ -0,0 +1,236 @@
|
|||
<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.</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>
|
||||
</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>
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 Width: | Height: | 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 Width: | Height: | 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 Width: | Height: | 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 Width: | Height: | 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"
|
||||
}'
|
||||
|
|
@ -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");
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -233,29 +233,30 @@ 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:
|
||||
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/
|
||||
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
|
||||
Product Brief: http://www.marvell.com/multimedia-solutions/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????
|
||||
Design name: BG3
|
||||
Core: ARM Cortex-A15, CA15 integrated L2CC
|
||||
|
||||
Homepage: http://www.marvell.com/digital-entertainment/
|
||||
Homepage: http://www.marvell.com/multimedia-solutions/
|
||||
Directory: arch/arm/mach-berlin
|
||||
|
||||
Comments:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
58
Documentation/arm64/silicon-errata.txt
Normal file
58
Documentation/arm64/silicon-errata.txt
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
Silicon Errata and Software Workarounds
|
||||
=======================================
|
||||
|
||||
Author: Will Deacon <will.deacon@arm.com>
|
||||
Date : 27 November 2015
|
||||
|
||||
It is an unfortunate fact of life that hardware is often produced with
|
||||
so-called "errata", which can cause it to deviate from the architecture
|
||||
under specific circumstances. For hardware produced by ARM, these
|
||||
errata are broadly classified into the following categories:
|
||||
|
||||
Category A: A critical error without a viable workaround.
|
||||
Category B: A significant or critical error with an acceptable
|
||||
workaround.
|
||||
Category C: A minor error that is not expected to occur under normal
|
||||
operation.
|
||||
|
||||
For more information, consult one of the "Software Developers Errata
|
||||
Notice" documents available on infocenter.arm.com (registration
|
||||
required).
|
||||
|
||||
As far as Linux is concerned, Category B errata may require some special
|
||||
treatment in the operating system. For example, avoiding a particular
|
||||
sequence of code, or configuring the processor in a particular way. A
|
||||
less common situation may require similar actions in order to declassify
|
||||
a Category A erratum into a Category C erratum. These are collectively
|
||||
known as "software workarounds" and are only required in the minority of
|
||||
cases (e.g. those cases that both require a non-secure workaround *and*
|
||||
can be triggered by Linux).
|
||||
|
||||
For software workarounds that may adversely impact systems unaffected by
|
||||
the erratum in question, a Kconfig entry is added under "Kernel
|
||||
Features" -> "ARM errata workarounds via the alternatives framework".
|
||||
These are enabled by default and patched in at runtime when an affected
|
||||
CPU is detected. For less-intrusive workarounds, a Kconfig option is not
|
||||
available and the code is structured (preferably with a comment) in such
|
||||
a way that the erratum will not be hit.
|
||||
|
||||
This approach can make it slightly onerous to determine exactly which
|
||||
errata are worked around in an arbitrary kernel source tree, so this
|
||||
file acts as a registry of software workarounds in the Linux Kernel and
|
||||
will be updated when new workarounds are committed and backported to
|
||||
stable kernels.
|
||||
|
||||
| Implementor | Component | Erratum ID | Kconfig |
|
||||
+----------------+-----------------+-----------------+-------------------------+
|
||||
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
|
||||
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
|
||||
| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
|
||||
| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
|
||||
| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
|
||||
| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
|
||||
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
|
||||
| ARM | Cortex-A57 | #852523 | N/A |
|
||||
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
|
||||
| | | | |
|
||||
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
|
||||
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
|
||||
|
|
@ -81,14 +81,13 @@ on higher end storage.
|
|||
|
||||
Default value for this parameter is 8ms.
|
||||
|
||||
latency
|
||||
-------
|
||||
This parameter is used to enable/disable the latency mode of the CFQ
|
||||
scheduler. If latency mode (called low_latency) is enabled, CFQ tries
|
||||
to recompute the slice time for each process based on the target_latency set
|
||||
for the system. This favors fairness over throughput. Disabling low
|
||||
latency (setting it to 0) ignores target latency, allowing each process in the
|
||||
system to get a full time slice.
|
||||
low_latency
|
||||
-----------
|
||||
This parameter is used to enable/disable the low latency mode of the CFQ
|
||||
scheduler. If enabled, CFQ tries to recompute the slice time for each process
|
||||
based on the target_latency set for the system. This favors fairness over
|
||||
throughput. Disabling low latency (setting it to 0) ignores target latency,
|
||||
allowing each process in the system to get a full time slice.
|
||||
|
||||
By default low latency mode is enabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,5 @@ net_prio.txt
|
|||
- Network priority cgroups details and usages.
|
||||
pids.txt
|
||||
- Process number cgroups details and usages.
|
||||
resource_counter.txt
|
||||
- Resource Counter API.
|
||||
unified-hierarchy.txt
|
||||
- Description the new/next cgroup interface.
|
||||
|
|
@ -84,8 +84,7 @@ Throttling/Upper Limit policy
|
|||
|
||||
- Run dd to read a file and see if rate is throttled to 1MB/s or not.
|
||||
|
||||
# dd if=/mnt/common/zerofile of=/dev/null bs=4K count=1024
|
||||
# iflag=direct
|
||||
# dd iflag=direct if=/mnt/common/zerofile of=/dev/null bs=4K count=1024
|
||||
1024+0 records in
|
||||
1024+0 records out
|
||||
4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s
|
||||
|
|
@ -374,82 +373,3 @@ One can experience an overall throughput drop if you have created multiple
|
|||
groups and put applications in that group which are not driving enough
|
||||
IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle
|
||||
on individual groups and throughput should improve.
|
||||
|
||||
Writeback
|
||||
=========
|
||||
|
||||
Page cache is dirtied through buffered writes and shared mmaps and
|
||||
written asynchronously to the backing filesystem by the writeback
|
||||
mechanism. Writeback sits between the memory and IO domains and
|
||||
regulates the proportion of dirty memory by balancing dirtying and
|
||||
write IOs.
|
||||
|
||||
On traditional cgroup hierarchies, relationships between different
|
||||
controllers cannot be established making it impossible for writeback
|
||||
to operate accounting for cgroup resource restrictions and all
|
||||
writeback IOs are attributed to the root cgroup.
|
||||
|
||||
If both the blkio and memory controllers are used on the v2 hierarchy
|
||||
and the filesystem supports cgroup writeback, writeback operations
|
||||
correctly follow the resource restrictions imposed by both memory and
|
||||
blkio controllers.
|
||||
|
||||
Writeback examines both system-wide and per-cgroup dirty memory status
|
||||
and enforces the more restrictive of the two. Also, writeback control
|
||||
parameters which are absolute values - vm.dirty_bytes and
|
||||
vm.dirty_background_bytes - are distributed across cgroups according
|
||||
to their current writeback bandwidth.
|
||||
|
||||
There's a peculiarity stemming from the discrepancy in ownership
|
||||
granularity between memory controller and writeback. While memory
|
||||
controller tracks ownership per page, writeback operates on inode
|
||||
basis. cgroup writeback bridges the gap by tracking ownership by
|
||||
inode but migrating ownership if too many foreign pages, pages which
|
||||
don't match the current inode ownership, have been encountered while
|
||||
writing back the inode.
|
||||
|
||||
This is a conscious design choice as writeback operations are
|
||||
inherently tied to inodes making strictly following page ownership
|
||||
complicated and inefficient. The only use case which suffers from
|
||||
this compromise is multiple cgroups concurrently dirtying disjoint
|
||||
regions of the same inode, which is an unlikely use case and decided
|
||||
to be unsupported. Note that as memory controller assigns page
|
||||
ownership on the first use and doesn't update it until the page is
|
||||
released, even if cgroup writeback strictly follows page ownership,
|
||||
multiple cgroups dirtying overlapping areas wouldn't work as expected.
|
||||
In general, write-sharing an inode across multiple cgroups is not well
|
||||
supported.
|
||||
|
||||
Filesystem support for cgroup writeback
|
||||
---------------------------------------
|
||||
|
||||
A filesystem can make writeback IOs cgroup-aware by updating
|
||||
address_space_operations->writepage[s]() to annotate bio's using the
|
||||
following two functions.
|
||||
|
||||
* wbc_init_bio(@wbc, @bio)
|
||||
|
||||
Should be called for each bio carrying writeback data and associates
|
||||
the bio with the inode's owner cgroup. Can be called anytime
|
||||
between bio allocation and submission.
|
||||
|
||||
* wbc_account_io(@wbc, @page, @bytes)
|
||||
|
||||
Should be called for each data segment being written out. While
|
||||
this function doesn't care exactly when it's called during the
|
||||
writeback session, it's the easiest and most natural to call it as
|
||||
data segments are added to a bio.
|
||||
|
||||
With writeback bio's annotated, cgroup support can be enabled per
|
||||
super_block by setting MS_CGROUPWB in ->s_flags. This allows for
|
||||
selective disabling of cgroup writeback support which is helpful when
|
||||
certain filesystem features, e.g. journaled data mode, are
|
||||
incompatible.
|
||||
|
||||
wbc_init_bio() binds the specified bio to its cgroup. Depending on
|
||||
the configuration, the bio may be executed at a lower priority and if
|
||||
the writeback session is holding shared resources, e.g. a journal
|
||||
entry, may lead to priority inversion. There is no one easy solution
|
||||
for the problem. Filesystems can try to work around specific problem
|
||||
cases by skipping wbc_init_bio() or using bio_associate_blkcg()
|
||||
directly.
|
||||
1386
Documentation/cgroup-v2.txt
Normal file
1386
Documentation/cgroup-v2.txt
Normal file
File diff suppressed because it is too large
Load Diff
|
|
@ -1,647 +0,0 @@
|
|||
|
||||
Cgroup unified hierarchy
|
||||
|
||||
April, 2014 Tejun Heo <tj@kernel.org>
|
||||
|
||||
This document describes the changes made by unified hierarchy and
|
||||
their rationales. It will eventually be merged into the main cgroup
|
||||
documentation.
|
||||
|
||||
CONTENTS
|
||||
|
||||
1. Background
|
||||
2. Basic Operation
|
||||
2-1. Mounting
|
||||
2-2. cgroup.subtree_control
|
||||
2-3. cgroup.controllers
|
||||
3. Structural Constraints
|
||||
3-1. Top-down
|
||||
3-2. No internal tasks
|
||||
4. Delegation
|
||||
4-1. Model of delegation
|
||||
4-2. Common ancestor rule
|
||||
5. Other Changes
|
||||
5-1. [Un]populated Notification
|
||||
5-2. Other Core Changes
|
||||
5-3. Controller File Conventions
|
||||
5-3-1. Format
|
||||
5-3-2. Control Knobs
|
||||
5-4. Per-Controller Changes
|
||||
5-4-1. io
|
||||
5-4-2. cpuset
|
||||
5-4-3. memory
|
||||
6. Planned Changes
|
||||
6-1. CAP for resource control
|
||||
|
||||
|
||||
1. Background
|
||||
|
||||
cgroup allows an arbitrary number of hierarchies and each hierarchy
|
||||
can host any number of controllers. While this seems to provide a
|
||||
high level of flexibility, it isn't quite useful in practice.
|
||||
|
||||
For example, as there is only one instance of each controller, utility
|
||||
type controllers such as freezer which can be useful in all
|
||||
hierarchies can only be used in one. The issue is exacerbated by the
|
||||
fact that controllers can't be moved around once hierarchies are
|
||||
populated. Another issue is that all controllers bound to a hierarchy
|
||||
are forced to have exactly the same view of the hierarchy. It isn't
|
||||
possible to vary the granularity depending on the specific controller.
|
||||
|
||||
In practice, these issues heavily limit which controllers can be put
|
||||
on the same hierarchy and most configurations resort to putting each
|
||||
controller on its own hierarchy. Only closely related ones, such as
|
||||
the cpu and cpuacct controllers, make sense to put on the same
|
||||
hierarchy. This often means that userland ends up managing multiple
|
||||
similar hierarchies repeating the same steps on each hierarchy
|
||||
whenever a hierarchy management operation is necessary.
|
||||
|
||||
Unfortunately, support for multiple hierarchies comes at a steep cost.
|
||||
Internal implementation in cgroup core proper is dazzlingly
|
||||
complicated but more importantly the support for multiple hierarchies
|
||||
restricts how cgroup is used in general and what controllers can do.
|
||||
|
||||
There's no limit on how many hierarchies there may be, which means
|
||||
that a task's cgroup membership can't be described in finite length.
|
||||
The key may contain any varying number of entries and is unlimited in
|
||||
length, which makes it highly awkward to handle and leads to addition
|
||||
of controllers which exist only to identify membership, which in turn
|
||||
exacerbates the original problem.
|
||||
|
||||
Also, as a controller can't have any expectation regarding what shape
|
||||
of hierarchies other controllers would be on, each controller has to
|
||||
assume that all other controllers are operating on completely
|
||||
orthogonal hierarchies. This makes it impossible, or at least very
|
||||
cumbersome, for controllers to cooperate with each other.
|
||||
|
||||
In most use cases, putting controllers on hierarchies which are
|
||||
completely orthogonal to each other isn't necessary. What usually is
|
||||
called for is the ability to have differing levels of granularity
|
||||
depending on the specific controller. In other words, hierarchy may
|
||||
be collapsed from leaf towards root when viewed from specific
|
||||
controllers. For example, a given configuration might not care about
|
||||
how memory is distributed beyond a certain level while still wanting
|
||||
to control how CPU cycles are distributed.
|
||||
|
||||
Unified hierarchy is the next version of cgroup interface. It aims to
|
||||
address the aforementioned issues by having more structure while
|
||||
retaining enough flexibility for most use cases. Various other
|
||||
general and controller-specific interface issues are also addressed in
|
||||
the process.
|
||||
|
||||
|
||||
2. Basic Operation
|
||||
|
||||
2-1. Mounting
|
||||
|
||||
Currently, unified hierarchy can be mounted with the following mount
|
||||
command. Note that this is still under development and scheduled to
|
||||
change soon.
|
||||
|
||||
mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
|
||||
|
||||
All controllers which support the unified hierarchy and are not bound
|
||||
to other hierarchies are automatically bound to unified hierarchy and
|
||||
show up at the root of it. Controllers which are enabled only in the
|
||||
root of unified hierarchy can be bound to other hierarchies. This
|
||||
allows mixing unified hierarchy with the traditional multiple
|
||||
hierarchies in a fully backward compatible way.
|
||||
|
||||
A controller can be moved across hierarchies only after the controller
|
||||
is no longer referenced in its current hierarchy. Because per-cgroup
|
||||
controller states are destroyed asynchronously and controllers may
|
||||
have lingering references, a controller may not show up immediately on
|
||||
the unified hierarchy after the final umount of the previous
|
||||
hierarchy. Similarly, a controller should be fully disabled to be
|
||||
moved out of the unified hierarchy and it may take some time for the
|
||||
disabled controller to become available for other hierarchies;
|
||||
furthermore, due to dependencies among controllers, other controllers
|
||||
may need to be disabled too.
|
||||
|
||||
While useful for development and manual configurations, dynamically
|
||||
moving controllers between the unified and other hierarchies is
|
||||
strongly discouraged for production use. It is recommended to decide
|
||||
the hierarchies and controller associations before starting using the
|
||||
controllers.
|
||||
|
||||
|
||||
2-2. cgroup.subtree_control
|
||||
|
||||
All cgroups on unified hierarchy have a "cgroup.subtree_control" file
|
||||
which governs which controllers are enabled on the children of the
|
||||
cgroup. Let's assume a hierarchy like the following.
|
||||
|
||||
root - A - B - C
|
||||
\ D
|
||||
|
||||
root's "cgroup.subtree_control" file determines which controllers are
|
||||
enabled on A. A's on B. B's on C and D. This coincides with the
|
||||
fact that controllers on the immediate sub-level are used to
|
||||
distribute the resources of the parent. In fact, it's natural to
|
||||
assume that resource control knobs of a child belong to its parent.
|
||||
Enabling a controller in a "cgroup.subtree_control" file declares that
|
||||
distribution of the respective resources of the cgroup will be
|
||||
controlled. Note that this means that controller enable states are
|
||||
shared among siblings.
|
||||
|
||||
When read, the file contains a space-separated list of currently
|
||||
enabled controllers. A write to the file should contain a
|
||||
space-separated list of controllers with '+' or '-' prefixed (without
|
||||
the quotes). Controllers prefixed with '+' are enabled and '-'
|
||||
disabled. If a controller is listed multiple times, the last entry
|
||||
wins. The specific operations are executed atomically - either all
|
||||
succeed or fail.
|
||||
|
||||
|
||||
2-3. cgroup.controllers
|
||||
|
||||
Read-only "cgroup.controllers" file contains a space-separated list of
|
||||
controllers which can be enabled in the cgroup's
|
||||
"cgroup.subtree_control" file.
|
||||
|
||||
In the root cgroup, this lists controllers which are not bound to
|
||||
other hierarchies and the content changes as controllers are bound to
|
||||
and unbound from other hierarchies.
|
||||
|
||||
In non-root cgroups, the content of this file equals that of the
|
||||
parent's "cgroup.subtree_control" file as only controllers enabled
|
||||
from the parent can be used in its children.
|
||||
|
||||
|
||||
3. Structural Constraints
|
||||
|
||||
3-1. Top-down
|
||||
|
||||
As it doesn't make sense to nest control of an uncontrolled resource,
|
||||
all non-root "cgroup.subtree_control" files can only contain
|
||||
controllers which are enabled in the parent's "cgroup.subtree_control"
|
||||
file. A controller can be enabled only if the parent has the
|
||||
controller enabled and a controller can't be disabled if one or more
|
||||
children have it enabled.
|
||||
|
||||
|
||||
3-2. No internal tasks
|
||||
|
||||
One long-standing issue that cgroup faces is the competition between
|
||||
tasks belonging to the parent cgroup and its children cgroups. This
|
||||
is inherently nasty as two different types of entities compete and
|
||||
there is no agreed-upon obvious way to handle it. Different
|
||||
controllers are doing different things.
|
||||
|
||||
The cpu controller considers tasks and cgroups as equivalents and maps
|
||||
nice levels to cgroup weights. This works for some cases but falls
|
||||
flat when children should be allocated specific ratios of CPU cycles
|
||||
and the number of internal tasks fluctuates - the ratios constantly
|
||||
change as the number of competing entities fluctuates. There also are
|
||||
other issues. The mapping from nice level to weight isn't obvious or
|
||||
universal, and there are various other knobs which simply aren't
|
||||
available for tasks.
|
||||
|
||||
The io controller implicitly creates a hidden leaf node for each
|
||||
cgroup to host the tasks. The hidden leaf has its own copies of all
|
||||
the knobs with "leaf_" prefixed. While this allows equivalent control
|
||||
over internal tasks, it's with serious drawbacks. It always adds an
|
||||
extra layer of nesting which may not be necessary, makes the interface
|
||||
messy and significantly complicates the implementation.
|
||||
|
||||
The memory controller currently doesn't have a way to control what
|
||||
happens between internal tasks and child cgroups and the behavior is
|
||||
not clearly defined. There have been attempts to add ad-hoc behaviors
|
||||
and knobs to tailor the behavior to specific workloads. Continuing
|
||||
this direction will lead to problems which will be extremely difficult
|
||||
to resolve in the long term.
|
||||
|
||||
Multiple controllers struggle with internal tasks and came up with
|
||||
different ways to deal with it; unfortunately, all the approaches in
|
||||
use now are severely flawed and, furthermore, the widely different
|
||||
behaviors make cgroup as whole highly inconsistent.
|
||||
|
||||
It is clear that this is something which needs to be addressed from
|
||||
cgroup core proper in a uniform way so that controllers don't need to
|
||||
worry about it and cgroup as a whole shows a consistent and logical
|
||||
behavior. To achieve that, unified hierarchy enforces the following
|
||||
structural constraint:
|
||||
|
||||
Except for the root, only cgroups which don't contain any task may
|
||||
have controllers enabled in their "cgroup.subtree_control" files.
|
||||
|
||||
Combined with other properties, this guarantees that, when a
|
||||
controller is looking at the part of the hierarchy which has it
|
||||
enabled, tasks are always only on the leaves. This rules out
|
||||
situations where child cgroups compete against internal tasks of the
|
||||
parent.
|
||||
|
||||
There are two things to note. Firstly, the root cgroup is exempt from
|
||||
the restriction. Root contains tasks and anonymous resource
|
||||
consumption which can't be associated with any other cgroup and
|
||||
requires special treatment from most controllers. How resource
|
||||
consumption in the root cgroup is governed is up to each controller.
|
||||
|
||||
Secondly, the restriction doesn't take effect if there is no enabled
|
||||
controller in the cgroup's "cgroup.subtree_control" file. This is
|
||||
important as otherwise it wouldn't be possible to create children of a
|
||||
populated cgroup. To control resource distribution of a cgroup, the
|
||||
cgroup must create children and transfer all its tasks to the children
|
||||
before enabling controllers in its "cgroup.subtree_control" file.
|
||||
|
||||
|
||||
4. Delegation
|
||||
|
||||
4-1. Model of delegation
|
||||
|
||||
A cgroup can be delegated to a less privileged user by granting write
|
||||
access of the directory and its "cgroup.procs" file to the user. Note
|
||||
that the resource control knobs in a given directory concern the
|
||||
resources of the parent and thus must not be delegated along with the
|
||||
directory.
|
||||
|
||||
Once delegated, the user can build sub-hierarchy under the directory,
|
||||
organize processes as it sees fit and further distribute the resources
|
||||
it got from the parent. The limits and other settings of all resource
|
||||
controllers are hierarchical and regardless of what happens in the
|
||||
delegated sub-hierarchy, nothing can escape the resource restrictions
|
||||
imposed by the parent.
|
||||
|
||||
Currently, cgroup doesn't impose any restrictions on the number of
|
||||
cgroups in or nesting depth of a delegated sub-hierarchy; however,
|
||||
this may in the future be limited explicitly.
|
||||
|
||||
|
||||
4-2. Common ancestor rule
|
||||
|
||||
On the unified hierarchy, to write to a "cgroup.procs" file, in
|
||||
addition to the usual write permission to the file and uid match, the
|
||||
writer must also have write access to the "cgroup.procs" file of the
|
||||
common ancestor of the source and destination cgroups. This prevents
|
||||
delegatees from smuggling processes across disjoint sub-hierarchies.
|
||||
|
||||
Let's say cgroups C0 and C1 have been delegated to user U0 who created
|
||||
C00, C01 under C0 and C10 under C1 as follows.
|
||||
|
||||
~~~~~~~~~~~~~ - C0 - C00
|
||||
~ cgroup ~ \ C01
|
||||
~ hierarchy ~
|
||||
~~~~~~~~~~~~~ - C1 - C10
|
||||
|
||||
C0 and C1 are separate entities in terms of resource distribution
|
||||
regardless of their relative positions in the hierarchy. The
|
||||
resources the processes under C0 are entitled to are controlled by
|
||||
C0's ancestors and may be completely different from C1. It's clear
|
||||
that the intention of delegating C0 to U0 is allowing U0 to organize
|
||||
the processes under C0 and further control the distribution of C0's
|
||||
resources.
|
||||
|
||||
On traditional hierarchies, if a task has write access to "tasks" or
|
||||
"cgroup.procs" file of a cgroup and its uid agrees with the target, it
|
||||
can move the target to the cgroup. In the above example, U0 will not
|
||||
only be able to move processes in each sub-hierarchy but also across
|
||||
the two sub-hierarchies, effectively allowing it to violate the
|
||||
organizational and resource restrictions implied by the hierarchical
|
||||
structure above C0 and C1.
|
||||
|
||||
On the unified hierarchy, let's say U0 wants to write the pid of a
|
||||
process which has a matching uid and is currently in C10 into
|
||||
"C00/cgroup.procs". U0 obviously has write access to the file and
|
||||
migration permission on the process; however, the common ancestor of
|
||||
the source cgroup C10 and the destination cgroup C00 is above the
|
||||
points of delegation and U0 would not have write access to its
|
||||
"cgroup.procs" and thus be denied with -EACCES.
|
||||
|
||||
|
||||
5. Other Changes
|
||||
|
||||
5-1. [Un]populated Notification
|
||||
|
||||
cgroup users often need a way to determine when a cgroup's
|
||||
subhierarchy becomes empty so that it can be cleaned up. cgroup
|
||||
currently provides release_agent for it; unfortunately, this mechanism
|
||||
is riddled with issues.
|
||||
|
||||
- It delivers events by forking and execing a userland binary
|
||||
specified as the release_agent. This is a long deprecated method of
|
||||
notification delivery. It's extremely heavy, slow and cumbersome to
|
||||
integrate with larger infrastructure.
|
||||
|
||||
- There is single monitoring point at the root. There's no way to
|
||||
delegate management of a subtree.
|
||||
|
||||
- The event isn't recursive. It triggers when a cgroup doesn't have
|
||||
any tasks or child cgroups. Events for internal nodes trigger only
|
||||
after all children are removed. This again makes it impossible to
|
||||
delegate management of a subtree.
|
||||
|
||||
- Events are filtered from the kernel side. A "notify_on_release"
|
||||
file is used to subscribe to or suppress release events. This is
|
||||
unnecessarily complicated and probably done this way because event
|
||||
delivery itself was expensive.
|
||||
|
||||
Unified hierarchy implements "populated" field in "cgroup.events"
|
||||
interface file which can be used to monitor whether the cgroup's
|
||||
subhierarchy has tasks in it or not. Its value is 0 if there is no
|
||||
task in the cgroup and its descendants; otherwise, 1. poll and
|
||||
[id]notify events are triggered when the value changes.
|
||||
|
||||
This is significantly lighter and simpler and trivially allows
|
||||
delegating management of subhierarchy - subhierarchy monitoring can
|
||||
block further propagation simply by putting itself or another process
|
||||
in the subhierarchy and monitor events that it's interested in from
|
||||
there without interfering with monitoring higher in the tree.
|
||||
|
||||
In unified hierarchy, the release_agent mechanism is no longer
|
||||
supported and the interface files "release_agent" and
|
||||
"notify_on_release" do not exist.
|
||||
|
||||
|
||||
5-2. Other Core Changes
|
||||
|
||||
- None of the mount options is allowed.
|
||||
|
||||
- remount is disallowed.
|
||||
|
||||
- rename(2) is disallowed.
|
||||
|
||||
- The "tasks" file is removed. Everything should at process
|
||||
granularity. Use the "cgroup.procs" file instead.
|
||||
|
||||
- The "cgroup.procs" file is not sorted. pids will be unique unless
|
||||
they got recycled in-between reads.
|
||||
|
||||
- The "cgroup.clone_children" file is removed.
|
||||
|
||||
- /proc/PID/cgroup keeps reporting the cgroup that a zombie belonged
|
||||
to before exiting. If the cgroup is removed before the zombie is
|
||||
reaped, " (deleted)" is appeneded to the path.
|
||||
|
||||
|
||||
5-3. Controller File Conventions
|
||||
|
||||
5-3-1. Format
|
||||
|
||||
In general, all controller files should be in one of the following
|
||||
formats whenever possible.
|
||||
|
||||
- Values only files
|
||||
|
||||
VAL0 VAL1...\n
|
||||
|
||||
- Flat keyed files
|
||||
|
||||
KEY0 VAL0\n
|
||||
KEY1 VAL1\n
|
||||
...
|
||||
|
||||
- Nested keyed files
|
||||
|
||||
KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01...
|
||||
KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11...
|
||||
...
|
||||
|
||||
For a writeable file, the format for writing should generally match
|
||||
reading; however, controllers may allow omitting later fields or
|
||||
implement restricted shortcuts for most common use cases.
|
||||
|
||||
For both flat and nested keyed files, only the values for a single key
|
||||
can be written at a time. For nested keyed files, the sub key pairs
|
||||
may be specified in any order and not all pairs have to be specified.
|
||||
|
||||
|
||||
5-3-2. Control Knobs
|
||||
|
||||
- Settings for a single feature should generally be implemented in a
|
||||
single file.
|
||||
|
||||
- In general, the root cgroup should be exempt from resource control
|
||||
and thus shouldn't have resource control knobs.
|
||||
|
||||
- If a controller implements ratio based resource distribution, the
|
||||
control knob should be named "weight" and have the range [1, 10000]
|
||||
and 100 should be the default value. The values are chosen to allow
|
||||
enough and symmetric bias in both directions while keeping it
|
||||
intuitive (the default is 100%).
|
||||
|
||||
- If a controller implements an absolute resource guarantee and/or
|
||||
limit, the control knobs should be named "min" and "max"
|
||||
respectively. If a controller implements best effort resource
|
||||
gurantee and/or limit, the control knobs should be named "low" and
|
||||
"high" respectively.
|
||||
|
||||
In the above four control files, the special token "max" should be
|
||||
used to represent upward infinity for both reading and writing.
|
||||
|
||||
- If a setting has configurable default value and specific overrides,
|
||||
the default settings should be keyed with "default" and appear as
|
||||
the first entry in the file. Specific entries can use "default" as
|
||||
its value to indicate inheritance of the default value.
|
||||
|
||||
- For events which are not very high frequency, an interface file
|
||||
"events" should be created which lists event key value pairs.
|
||||
Whenever a notifiable event happens, file modified event should be
|
||||
generated on the file.
|
||||
|
||||
|
||||
5-4. Per-Controller Changes
|
||||
|
||||
5-4-1. io
|
||||
|
||||
- blkio is renamed to io. The interface is overhauled anyway. The
|
||||
new name is more in line with the other two major controllers, cpu
|
||||
and memory, and better suited given that it may be used for cgroup
|
||||
writeback without involving block layer.
|
||||
|
||||
- Everything including stat is always hierarchical making separate
|
||||
recursive stat files pointless and, as no internal node can have
|
||||
tasks, leaf weights are meaningless. The operation model is
|
||||
simplified and the interface is overhauled accordingly.
|
||||
|
||||
io.stat
|
||||
|
||||
The stat file. The reported stats are from the point where
|
||||
bio's are issued to request_queue. The stats are counted
|
||||
independent of which policies are enabled. Each line in the
|
||||
file follows the following format. More fields may later be
|
||||
added at the end.
|
||||
|
||||
$MAJ:$MIN rbytes=$RBYTES wbytes=$WBYTES rios=$RIOS wrios=$WIOS
|
||||
|
||||
io.weight
|
||||
|
||||
The weight setting, currently only available and effective if
|
||||
cfq-iosched is in use for the target device. The weight is
|
||||
between 1 and 10000 and defaults to 100. The first line
|
||||
always contains the default weight in the following format to
|
||||
use when per-device setting is missing.
|
||||
|
||||
default $WEIGHT
|
||||
|
||||
Subsequent lines list per-device weights of the following
|
||||
format.
|
||||
|
||||
$MAJ:$MIN $WEIGHT
|
||||
|
||||
Writing "$WEIGHT" or "default $WEIGHT" changes the default
|
||||
setting. Writing "$MAJ:$MIN $WEIGHT" sets per-device weight
|
||||
while "$MAJ:$MIN default" clears it.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
io.max
|
||||
|
||||
The maximum bandwidth and/or iops setting, only available if
|
||||
blk-throttle is enabled. The file is of the following format.
|
||||
|
||||
$MAJ:$MIN rbps=$RBPS wbps=$WBPS riops=$RIOPS wiops=$WIOPS
|
||||
|
||||
${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
|
||||
read/write IOs per second. "max" indicates no limit. Writing
|
||||
to the file follows the same format but the individual
|
||||
settings may be omitted or specified in any order.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
|
||||
5-4-2. cpuset
|
||||
|
||||
- Tasks are kept in empty cpusets after hotplug and take on the masks
|
||||
of the nearest non-empty ancestor, instead of being moved to it.
|
||||
|
||||
- A task can be moved into an empty cpuset, and again it takes on the
|
||||
masks of the nearest non-empty ancestor.
|
||||
|
||||
|
||||
5-4-3. memory
|
||||
|
||||
- use_hierarchy is on by default and the cgroup file for the flag is
|
||||
not created.
|
||||
|
||||
- The original lower boundary, the soft limit, is defined as a limit
|
||||
that is per default unset. As a result, the set of cgroups that
|
||||
global reclaim prefers is opt-in, rather than opt-out. The costs
|
||||
for optimizing these mostly negative lookups are so high that the
|
||||
implementation, despite its enormous size, does not even provide the
|
||||
basic desirable behavior. First off, the soft limit has no
|
||||
hierarchical meaning. All configured groups are organized in a
|
||||
global rbtree and treated like equal peers, regardless where they
|
||||
are located in the hierarchy. This makes subtree delegation
|
||||
impossible. Second, the soft limit reclaim pass is so aggressive
|
||||
that it not just introduces high allocation latencies into the
|
||||
system, but also impacts system performance due to overreclaim, to
|
||||
the point where the feature becomes self-defeating.
|
||||
|
||||
The memory.low boundary on the other hand is a top-down allocated
|
||||
reserve. A cgroup enjoys reclaim protection when it and all its
|
||||
ancestors are below their low boundaries, which makes delegation of
|
||||
subtrees possible. Secondly, new cgroups have no reserve per
|
||||
default and in the common case most cgroups are eligible for the
|
||||
preferred reclaim pass. This allows the new low boundary to be
|
||||
efficiently implemented with just a minor addition to the generic
|
||||
reclaim code, without the need for out-of-band data structures and
|
||||
reclaim passes. Because the generic reclaim code considers all
|
||||
cgroups except for the ones running low in the preferred first
|
||||
reclaim pass, overreclaim of individual groups is eliminated as
|
||||
well, resulting in much better overall workload performance.
|
||||
|
||||
- The original high boundary, the hard limit, is defined as a strict
|
||||
limit that can not budge, even if the OOM killer has to be called.
|
||||
But this generally goes against the goal of making the most out of
|
||||
the available memory. The memory consumption of workloads varies
|
||||
during runtime, and that requires users to overcommit. But doing
|
||||
that with a strict upper limit requires either a fairly accurate
|
||||
prediction of the working set size or adding slack to the limit.
|
||||
Since working set size estimation is hard and error prone, and
|
||||
getting it wrong results in OOM kills, most users tend to err on the
|
||||
side of a looser limit and end up wasting precious resources.
|
||||
|
||||
The memory.high boundary on the other hand can be set much more
|
||||
conservatively. When hit, it throttles allocations by forcing them
|
||||
into direct reclaim to work off the excess, but it never invokes the
|
||||
OOM killer. As a result, a high boundary that is chosen too
|
||||
aggressively will not terminate the processes, but instead it will
|
||||
lead to gradual performance degradation. The user can monitor this
|
||||
and make corrections until the minimal memory footprint that still
|
||||
gives acceptable performance is found.
|
||||
|
||||
In extreme cases, with many concurrent allocations and a complete
|
||||
breakdown of reclaim progress within the group, the high boundary
|
||||
can be exceeded. But even then it's mostly better to satisfy the
|
||||
allocation from the slack available in other groups or the rest of
|
||||
the system than killing the group. Otherwise, memory.max is there
|
||||
to limit this type of spillover and ultimately contain buggy or even
|
||||
malicious applications.
|
||||
|
||||
- The original control file names are unwieldy and inconsistent in
|
||||
many different ways. For example, the upper boundary hit count is
|
||||
exported in the memory.failcnt file, but an OOM event count has to
|
||||
be manually counted by listening to memory.oom_control events, and
|
||||
lower boundary / soft limit events have to be counted by first
|
||||
setting a threshold for that value and then counting those events.
|
||||
Also, usage and limit files encode their units in the filename.
|
||||
That makes the filenames very long, even though this is not
|
||||
information that a user needs to be reminded of every time they type
|
||||
out those names.
|
||||
|
||||
To address these naming issues, as well as to signal clearly that
|
||||
the new interface carries a new configuration model, the naming
|
||||
conventions in it necessarily differ from the old interface.
|
||||
|
||||
- The original limit files indicate the state of an unset limit with a
|
||||
Very High Number, and a configured limit can be unset by echoing -1
|
||||
into those files. But that very high number is implementation and
|
||||
architecture dependent and not very descriptive. And while -1 can
|
||||
be understood as an underflow into the highest possible value, -2 or
|
||||
-10M etc. do not work, so it's not consistent.
|
||||
|
||||
memory.low, memory.high, and memory.max will use the string "max" to
|
||||
indicate and set the highest possible value.
|
||||
|
||||
6. Planned Changes
|
||||
|
||||
6-1. CAP for resource control
|
||||
|
||||
Unified hierarchy will require one of the capabilities(7), which is
|
||||
yet to be decided, for all resource control related knobs. Process
|
||||
organization operations - creation of sub-cgroups and migration of
|
||||
processes in sub-hierarchies may be delegated by changing the
|
||||
ownership and/or permissions on the cgroup directory and
|
||||
"cgroup.procs" interface file; however, all operations which affect
|
||||
resource control - writes to a "cgroup.subtree_control" file or any
|
||||
controller-specific knobs - will require an explicit CAP privilege.
|
||||
|
||||
This, in part, is to prevent the cgroup interface from being
|
||||
inadvertently promoted to programmable API used by non-privileged
|
||||
binaries. cgroup exposes various aspects of the system in ways which
|
||||
aren't properly abstracted for direct consumption by regular programs.
|
||||
This is an administration interface much closer to sysctl knobs than
|
||||
system calls. Even the basic access model, being filesystem path
|
||||
based, isn't suitable for direct consumption. There's no way to
|
||||
access "my cgroup" in a race-free way or make multiple operations
|
||||
atomic against migration to another cgroup.
|
||||
|
||||
Another aspect is that, for better or for worse, the cgroup interface
|
||||
goes through far less scrutiny than regular interfaces for
|
||||
unprivileged userland. The upside is that cgroup is able to expose
|
||||
useful features which may not be suitable for general consumption in a
|
||||
reasonable time frame. It provides a relatively short path between
|
||||
internal details and userland-visible interface. Of course, this
|
||||
shortcut comes with high risk. We go through what we go through for
|
||||
general kernel APIs for good reasons. It may end up leaking internal
|
||||
details in a way which can exert significant pain by locking the
|
||||
kernel into a contract that can't be maintained in a reasonable
|
||||
manner.
|
||||
|
||||
Also, due to the specific nature, cgroup and its controllers don't
|
||||
tend to attract attention from a wide scope of developers. cgroup's
|
||||
short history is already fraught with severely mis-designed
|
||||
interfaces, unnecessary commitments to and exposing of internal
|
||||
details, broken and dangerous implementations of various features.
|
||||
|
||||
Keeping cgroup as an administration interface is both advantageous for
|
||||
its role and imperative given its nature. Some of the cgroup features
|
||||
may make sense for unprivileged access. If deemed justified, those
|
||||
must be further abstracted and implemented as a different interface,
|
||||
be it a system call or process-private filesystem, and survive through
|
||||
the scrutiny that any interface for general consumption is required to
|
||||
go through.
|
||||
|
||||
Requiring CAP is not a complete solution but should serve as a
|
||||
significant deterrent against spraying cgroup usages in non-privileged
|
||||
programs.
|
||||
|
|
@ -1,61 +1,131 @@
|
|||
Intel P-state driver
|
||||
Intel P-State driver
|
||||
--------------------
|
||||
|
||||
This driver provides an interface to control the P state selection for
|
||||
SandyBridge+ Intel processors. The driver can operate two different
|
||||
modes based on the processor model, legacy mode and Hardware P state (HWP)
|
||||
mode.
|
||||
This driver provides an interface to control the P-State selection for the
|
||||
SandyBridge+ Intel processors.
|
||||
|
||||
In legacy mode, the Intel P-state implements two internal governors,
|
||||
performance and powersave, that differ from the general cpufreq governors of
|
||||
the same name (the general cpufreq governors implement target(), whereas the
|
||||
internal Intel P-state governors implement setpolicy()). The internal
|
||||
performance governor sets the max_perf_pct and min_perf_pct to 100; that is,
|
||||
the governor selects the highest available P state to maximize the performance
|
||||
of the core. The internal powersave governor selects the appropriate P state
|
||||
based on the current load on the CPU.
|
||||
The following document explains P-States:
|
||||
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf
|
||||
As stated in the document, P-State doesn’t exactly mean a frequency. However, for
|
||||
the sake of the relationship with cpufreq, P-State and frequency are used
|
||||
interchangeably.
|
||||
|
||||
In HWP mode P state selection is implemented in the processor
|
||||
itself. The driver provides the interfaces between the cpufreq core and
|
||||
the processor to control P state selection based on user preferences
|
||||
and reporting frequency to the cpufreq core. In this mode the
|
||||
internal Intel P-state governor code is disabled.
|
||||
Understanding the cpufreq core governors and policies are important before
|
||||
discussing more details about the Intel P-State driver. Based on what callbacks
|
||||
a cpufreq driver provides to the cpufreq core, it can support two types of
|
||||
drivers:
|
||||
- with target_index() callback: In this mode, the drivers using cpufreq core
|
||||
simply provide the minimum and maximum frequency limits and an additional
|
||||
interface target_index() to set the current frequency. The cpufreq subsystem
|
||||
has a number of scaling governors ("performance", "powersave", "ondemand",
|
||||
etc.). Depending on which governor is in use, cpufreq core will call for
|
||||
transitions to a specific frequency using target_index() callback.
|
||||
- setpolicy() callback: In this mode, drivers do not provide target_index()
|
||||
callback, so cpufreq core can't request a transition to a specific frequency.
|
||||
The driver provides minimum and maximum frequency limits and callbacks to set a
|
||||
policy. The policy in cpufreq sysfs is referred to as the "scaling governor".
|
||||
The cpufreq core can request the driver to operate in any of the two policies:
|
||||
"performance: and "powersave". The driver decides which frequency to use based
|
||||
on the above policy selection considering minimum and maximum frequency limits.
|
||||
|
||||
In addition to the interfaces provided by the cpufreq core for
|
||||
controlling frequency the driver provides sysfs files for
|
||||
controlling P state selection. These files have been added to
|
||||
/sys/devices/system/cpu/intel_pstate/
|
||||
The Intel P-State driver falls under the latter category, which implements the
|
||||
setpolicy() callback. This driver decides what P-State to use based on the
|
||||
requested policy from the cpufreq core. If the processor is capable of
|
||||
selecting its next P-State internally, then the driver will offload this
|
||||
responsibility to the processor (aka HWP: Hardware P-States). If not, the
|
||||
driver implements algorithms to select the next P-State.
|
||||
|
||||
max_perf_pct: limits the maximum P state that will be requested by
|
||||
the driver stated as a percentage of the available performance. The
|
||||
available (P states) performance may be reduced by the no_turbo
|
||||
Since these policies are implemented in the driver, they are not same as the
|
||||
cpufreq scaling governors implementation, even if they have the same name in
|
||||
the cpufreq sysfs (scaling_governors). For example the "performance" policy is
|
||||
similar to cpufreq’s "performance" governor, but "powersave" is completely
|
||||
different than the cpufreq "powersave" governor. The strategy here is similar
|
||||
to cpufreq "ondemand", where the requested P-State is related to the system load.
|
||||
|
||||
Sysfs Interface
|
||||
|
||||
In addition to the frequency-controlling interfaces provided by the cpufreq
|
||||
core, the driver provides its own sysfs files to control the P-State selection.
|
||||
These files have been added to /sys/devices/system/cpu/intel_pstate/.
|
||||
Any changes made to these files are applicable to all CPUs (even in a
|
||||
multi-package system).
|
||||
|
||||
max_perf_pct: Limits the maximum P-State that will be requested by
|
||||
the driver. It states it as a percentage of the available performance. The
|
||||
available (P-State) performance may be reduced by the no_turbo
|
||||
setting described below.
|
||||
|
||||
min_perf_pct: limits the minimum P state that will be requested by
|
||||
the driver stated as a percentage of the max (non-turbo)
|
||||
min_perf_pct: Limits the minimum P-State that will be requested by
|
||||
the driver. It states it as a percentage of the max (non-turbo)
|
||||
performance level.
|
||||
|
||||
no_turbo: limits the driver to selecting P states below the turbo
|
||||
no_turbo: Limits the driver to selecting P-State below the turbo
|
||||
frequency range.
|
||||
|
||||
turbo_pct: displays the percentage of the total performance that
|
||||
is supported by hardware that is in the turbo range. This number
|
||||
turbo_pct: Displays the percentage of the total performance that
|
||||
is supported by hardware that is in the turbo range. This number
|
||||
is independent of whether turbo has been disabled or not.
|
||||
|
||||
num_pstates: displays the number of pstates that are supported
|
||||
by hardware. This number is independent of whether turbo has
|
||||
num_pstates: Displays the number of P-States that are supported
|
||||
by hardware. This number is independent of whether turbo has
|
||||
been disabled or not.
|
||||
|
||||
For example, if a system has these parameters:
|
||||
Max 1 core turbo ratio: 0x21 (Max 1 core ratio is the maximum P-State)
|
||||
Max non turbo ratio: 0x17
|
||||
Minimum ratio : 0x08 (Here the ratio is called max efficiency ratio)
|
||||
|
||||
Sysfs will show :
|
||||
max_perf_pct:100, which corresponds to 1 core ratio
|
||||
min_perf_pct:24, max_efficiency_ratio / max 1 Core ratio
|
||||
no_turbo:0, turbo is not disabled
|
||||
num_pstates:26 = (max 1 Core ratio - Max Efficiency Ratio + 1)
|
||||
turbo_pct:39 = (max 1 core ratio - max non turbo ratio) / num_pstates
|
||||
|
||||
Refer to "Intel® 64 and IA-32 Architectures Software Developer’s Manual
|
||||
Volume 3: System Programming Guide" to understand ratios.
|
||||
|
||||
cpufreq sysfs for Intel P-State
|
||||
|
||||
Since this driver registers with cpufreq, cpufreq sysfs is also presented.
|
||||
There are some important differences, which need to be considered.
|
||||
|
||||
scaling_cur_freq: This displays the real frequency which was used during
|
||||
the last sample period instead of what is requested. Some other cpufreq driver,
|
||||
like acpi-cpufreq, displays what is requested (Some changes are on the
|
||||
way to fix this for acpi-cpufreq driver). The same is true for frequencies
|
||||
displayed at /proc/cpuinfo.
|
||||
|
||||
scaling_governor: This displays current active policy. Since each CPU has a
|
||||
cpufreq sysfs, it is possible to set a scaling governor to each CPU. But this
|
||||
is not possible with Intel P-States, as there is one common policy for all
|
||||
CPUs. Here, the last requested policy will be applicable to all CPUs. It is
|
||||
suggested that one use the cpupower utility to change policy to all CPUs at the
|
||||
same time.
|
||||
|
||||
scaling_setspeed: This attribute can never be used with Intel P-State.
|
||||
|
||||
scaling_max_freq/scaling_min_freq: This interface can be used similarly to
|
||||
the max_perf_pct/min_perf_pct of Intel P-State sysfs. However since frequencies
|
||||
are converted to nearest possible P-State, this is prone to rounding errors.
|
||||
This method is not preferred to limit performance.
|
||||
|
||||
affected_cpus: Not used
|
||||
related_cpus: Not used
|
||||
|
||||
For contemporary Intel processors, the frequency is controlled by the
|
||||
processor itself and the P-states exposed to software are related to
|
||||
processor itself and the P-State exposed to software is related to
|
||||
performance levels. The idea that frequency can be set to a single
|
||||
frequency is fiction for Intel Core processors. Even if the scaling
|
||||
driver selects a single P state the actual frequency the processor
|
||||
frequency is fictional for Intel Core processors. Even if the scaling
|
||||
driver selects a single P-State, the actual frequency the processor
|
||||
will run at is selected by the processor itself.
|
||||
|
||||
For legacy mode debugfs files have also been added to allow tuning of
|
||||
the internal governor algorythm. These files are located at
|
||||
/sys/kernel/debug/pstate_snb/ These files are NOT present in HWP mode.
|
||||
Tuning Intel P-State driver
|
||||
|
||||
When HWP mode is not used, debugfs files have also been added to allow the
|
||||
tuning of the internal governor algorithm. These files are located at
|
||||
/sys/kernel/debug/pstate_snb/. The algorithm uses a PID (Proportional
|
||||
Integral Derivative) controller. The PID tunable parameters are:
|
||||
|
||||
deadband
|
||||
d_gain_pct
|
||||
|
|
@ -63,3 +133,90 @@ the internal governor algorythm. These files are located at
|
|||
p_gain_pct
|
||||
sample_rate_ms
|
||||
setpoint
|
||||
|
||||
To adjust these parameters, some understanding of driver implementation is
|
||||
necessary. There are some tweeks described here, but be very careful. Adjusting
|
||||
them requires expert level understanding of power and performance relationship.
|
||||
These limits are only useful when the "powersave" policy is active.
|
||||
|
||||
-To make the system more responsive to load changes, sample_rate_ms can
|
||||
be adjusted (current default is 10ms).
|
||||
-To make the system use higher performance, even if the load is lower, setpoint
|
||||
can be adjusted to a lower number. This will also lead to faster ramp up time
|
||||
to reach the maximum P-State.
|
||||
If there are no derivative and integral coefficients, The next P-State will be
|
||||
equal to:
|
||||
current P-State - ((setpoint - current cpu load) * p_gain_pct)
|
||||
|
||||
For example, if the current PID parameters are (Which are defaults for the core
|
||||
processors like SandyBridge):
|
||||
deadband = 0
|
||||
d_gain_pct = 0
|
||||
i_gain_pct = 0
|
||||
p_gain_pct = 20
|
||||
sample_rate_ms = 10
|
||||
setpoint = 97
|
||||
|
||||
If the current P-State = 0x08 and current load = 100, this will result in the
|
||||
next P-State = 0x08 - ((97 - 100) * 0.2) = 8.6 (rounded to 9). Here the P-State
|
||||
goes up by only 1. If during next sample interval the current load doesn't
|
||||
change and still 100, then P-State goes up by one again. This process will
|
||||
continue as long as the load is more than the setpoint until the maximum P-State
|
||||
is reached.
|
||||
|
||||
For the same load at setpoint = 60, this will result in the next P-State
|
||||
= 0x08 - ((60 - 100) * 0.2) = 16
|
||||
So by changing the setpoint from 97 to 60, there is an increase of the
|
||||
next P-State from 9 to 16. So this will make processor execute at higher
|
||||
P-State for the same CPU load. If the load continues to be more than the
|
||||
setpoint during next sample intervals, then P-State will go up again till the
|
||||
maximum P-State is reached. But the ramp up time to reach the maximum P-State
|
||||
will be much faster when the setpoint is 60 compared to 97.
|
||||
|
||||
Debugging Intel P-State driver
|
||||
|
||||
Event tracing
|
||||
To debug P-State transition, the Linux event tracing interface can be used.
|
||||
There are two specific events, which can be enabled (Provided the kernel
|
||||
configs related to event tracing are enabled).
|
||||
|
||||
# cd /sys/kernel/debug/tracing/
|
||||
# echo 1 > events/power/pstate_sample/enable
|
||||
# echo 1 > events/power/cpu_frequency/enable
|
||||
# cat trace
|
||||
gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107
|
||||
scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618
|
||||
freq=2474476
|
||||
cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
|
||||
|
||||
|
||||
Using ftrace
|
||||
|
||||
If function level tracing is required, the Linux ftrace interface can be used.
|
||||
For example if we want to check how often a function to set a P-State is
|
||||
called, we can set ftrace filter to intel_pstate_set_pstate.
|
||||
|
||||
# cd /sys/kernel/debug/tracing/
|
||||
# cat available_filter_functions | grep -i pstate
|
||||
intel_pstate_set_pstate
|
||||
intel_pstate_cpu_init
|
||||
...
|
||||
|
||||
# echo intel_pstate_set_pstate > set_ftrace_filter
|
||||
# echo function > current_tracer
|
||||
# cat trace | head -15
|
||||
# tracer: function
|
||||
#
|
||||
# entries-in-buffer/entries-written: 80/80 #P:4
|
||||
#
|
||||
# _-----=> irqs-off
|
||||
# / _----=> need-resched
|
||||
# | / _---=> hardirq/softirq
|
||||
# || / _--=> preempt-depth
|
||||
# ||| / delay
|
||||
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
|
||||
# | | | |||| | |
|
||||
Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func
|
||||
gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func
|
||||
gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
|
||||
<idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func
|
||||
|
|
|
|||
|
|
@ -159,8 +159,8 @@ to be strictly associated with a P-state.
|
|||
|
||||
2.2 cpuinfo_transition_latency:
|
||||
-------------------------------
|
||||
The cpuinfo_transition_latency field is 0. The PCC specification does
|
||||
not include a field to expose this value currently.
|
||||
The cpuinfo_transition_latency field is CPUFREQ_ETERNAL. The PCC specification
|
||||
does not include a field to expose this value currently.
|
||||
|
||||
2.3 cpuinfo_cur_freq:
|
||||
---------------------
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ an entry as shown below in the output.
|
|||
|
||||
If this is not mounted, do the following.
|
||||
|
||||
#mkdir /sysfs
|
||||
#mkdir /sys
|
||||
#mount -t sysfs sys /sys
|
||||
|
||||
Now you should see entries for all present cpu, the following is an example
|
||||
|
|
|
|||
|
|
@ -18,11 +18,11 @@ Construction Parameters
|
|||
|
||||
0 is the original format used in the Chromium OS.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
the rest of the block is padded with zeroes.
|
||||
|
||||
1 is the current format that should be used for new devices.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
padded with zeroes to the power of two.
|
||||
|
||||
<dev>
|
||||
This is the device containing data, the integrity of which needs to be
|
||||
|
|
@ -79,6 +79,37 @@ restart_on_corruption
|
|||
not compatible with ignore_corruption and requires user space support to
|
||||
avoid restart loops.
|
||||
|
||||
ignore_zero_blocks
|
||||
Do not verify blocks that are expected to contain zeroes and always return
|
||||
zeroes instead. This may be useful if the partition contains unused blocks
|
||||
that are not guaranteed to contain zeroes.
|
||||
|
||||
use_fec_from_device <fec_dev>
|
||||
Use forward error correction (FEC) to recover from corruption if hash
|
||||
verification fails. Use encoding data from the specified device. This
|
||||
may be the same device where data and hash blocks reside, in which case
|
||||
fec_start must be outside data and hash areas.
|
||||
|
||||
If the encoding data covers additional metadata, it must be accessible
|
||||
on the hash device after the hash blocks.
|
||||
|
||||
Note: block sizes for data and hash devices must match. Also, if the
|
||||
verity <dev> is encrypted the <fec_dev> should be too.
|
||||
|
||||
fec_roots <num>
|
||||
Number of generator roots. This equals to the number of parity bytes in
|
||||
the encoding data. For example, in RS(M, N) encoding, the number of roots
|
||||
is M-N.
|
||||
|
||||
fec_blocks <num>
|
||||
The number of encoding data blocks on the FEC device. The block size for
|
||||
the FEC device is <data_block_size>.
|
||||
|
||||
fec_start <offset>
|
||||
This is the offset, in <data_block_size> blocks, from the start of the
|
||||
FEC device to the beginning of the encoding data.
|
||||
|
||||
|
||||
Theory of operation
|
||||
===================
|
||||
|
||||
|
|
@ -98,6 +129,11 @@ per-block basis. This allows for a lightweight hash computation on first read
|
|||
into the page cache. Block hashes are stored linearly, aligned to the nearest
|
||||
block size.
|
||||
|
||||
If forward error correction (FEC) support is enabled any recovery of
|
||||
corrupted data will be verified using the cryptographic hash of the
|
||||
corresponding data. This is why combining error correction with
|
||||
integrity checking is essential.
|
||||
|
||||
Hash Tree
|
||||
---------
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Required properties:
|
|||
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
|
||||
|
||||
The rest of the properties should follow the generic mmio-sram description
|
||||
found in ../../misc/sysram.txt
|
||||
found in ../../sram/sram.txt
|
||||
|
||||
Each sub-node represents the reserved area for SCPI.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,10 @@ Raspberry Pi Model B+
|
|||
Required root node properties:
|
||||
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi 2 Model B
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
|
||||
|
||||
Raspberry Pi Compute Module
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,compute-module", "brcm,bcm2835";
|
||||
|
|
|
|||
|
|
@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following properties:
|
|||
|
||||
Required root node property:
|
||||
|
||||
bcm4708
|
||||
compatible = "brcm,bcm4708";
|
||||
|
||||
bcm4709
|
||||
compatible = "brcm,bcm4709";
|
||||
|
||||
bcm53012
|
||||
compatible = "brcm,bcm53012";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,39 @@
|
|||
Broadcom Northstar Plus SoC CPU Enable Method
|
||||
---------------------------------------------
|
||||
This binding defines the enable method used for starting secondary
|
||||
CPU in the following Broadcom SoCs:
|
||||
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
|
||||
|
||||
The enable method is specified by defining the following required
|
||||
properties in the corresponding secondary "cpu" device tree node:
|
||||
- enable-method = "brcm,bcm-nsp-smp";
|
||||
- secondary-boot-reg = <...>;
|
||||
|
||||
The secondary-boot-reg property is a u32 value that specifies the
|
||||
physical address of the register which should hold the common
|
||||
entry point for a secondary CPU. This entry is cpu node specific
|
||||
and should be added per cpu. E.g., in case of NSP (BCM58625) which
|
||||
is a dual core CPU SoC, this entry should be added to cpu1 node.
|
||||
|
||||
|
||||
Example:
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a9";
|
||||
next-level-cache = <&L2>;
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
cpu1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a9";
|
||||
next-level-cache = <&L2>;
|
||||
enable-method = "brcm,bcm-nsp-smp";
|
||||
secondary-boot-reg = <0xffff042c>;
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
25
Documentation/devicetree/bindings/arm/compulab-boards.txt
Normal file
25
Documentation/devicetree/bindings/arm/compulab-boards.txt
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
CompuLab SB-SOM is a multi-module baseboard capable of carrying:
|
||||
- CM-T43
|
||||
- CM-T54
|
||||
- CM-QS600
|
||||
- CL-SOM-AM57x
|
||||
- CL-SOM-iMX7
|
||||
modules with minor modifications to the SB-SOM assembly.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be "compulab,sb-som"
|
||||
|
||||
Compulab CL-SOM-iMX7 is a miniature System-on-Module (SoM) based on
|
||||
Freescale i.MX7 ARM Cortex-A7 System-on-Chip.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "compulab,cl-som-imx7", "fsl,imx7d";
|
||||
|
||||
Compulab SBC-iMX7 is a single board computer based on the
|
||||
Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with
|
||||
the CL-SOM-iMX7 System-on-Module providing most of the functions,
|
||||
and SB-SOM-iMX7 carrier board providing additional peripheral
|
||||
functions and connectors.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "compulab,sbc-imx7", "compulab,cl-som-imx7", "fsl,imx7d";
|
||||
|
|
@ -157,6 +157,7 @@ nodes to be present and contain the properties described below.
|
|||
"arm,cortex-a17"
|
||||
"arm,cortex-a53"
|
||||
"arm,cortex-a57"
|
||||
"arm,cortex-a72"
|
||||
"arm,cortex-m0"
|
||||
"arm,cortex-m0+"
|
||||
"arm,cortex-m1"
|
||||
|
|
@ -190,6 +191,8 @@ nodes to be present and contain the properties described below.
|
|||
"allwinner,sun6i-a31"
|
||||
"allwinner,sun8i-a23"
|
||||
"arm,psci"
|
||||
"arm,realview-smp"
|
||||
"brcm,bcm-nsp-smp"
|
||||
"brcm,brahma-b15"
|
||||
"marvell,armada-375-smp"
|
||||
"marvell,armada-380-smp"
|
||||
|
|
@ -200,6 +203,7 @@ nodes to be present and contain the properties described below.
|
|||
"qcom,gcc-msm8660"
|
||||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
"rockchip,rk3036-smp"
|
||||
"rockchip,rk3066-smp"
|
||||
"ste,dbx500-smp"
|
||||
|
||||
|
|
@ -242,6 +246,23 @@ nodes to be present and contain the properties described below.
|
|||
Definition: Specifies the syscon node controlling the cpu core
|
||||
power domains.
|
||||
|
||||
- dynamic-power-coefficient
|
||||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A u32 value that represents the running time dynamic
|
||||
power coefficient in units of mW/MHz/uVolt^2. The
|
||||
coefficient can either be calculated from power
|
||||
measurements or derived by analysis.
|
||||
|
||||
The dynamic power consumption of the CPU is
|
||||
proportional to the square of the Voltage (V) and
|
||||
the clock frequency (f). The coefficient is used to
|
||||
calculate the dynamic power as below -
|
||||
|
||||
Pdyn = dynamic-power-coefficient * V^2 * f
|
||||
|
||||
where voltage is in uV, frequency is in MHz.
|
||||
|
||||
Example 1 (dual-cluster big.LITTLE system 32-bit):
|
||||
|
||||
cpus {
|
||||
|
|
|
|||
|
|
@ -131,6 +131,10 @@ Example:
|
|||
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
|
||||
----------------------------------------------------------------
|
||||
|
||||
LS1043A ARMv8 based RDB Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a";
|
||||
|
||||
LS2080A ARMv8 based Simulator model
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
|
||||
|
|
|
|||
|
|
@ -187,6 +187,22 @@ Example:
|
|||
reg = <0xb0000000 0x10000>;
|
||||
};
|
||||
|
||||
Hisilicon HiP05 PERISUB system controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,hip05-perisubc", "syscon";
|
||||
- reg : Register address and size
|
||||
|
||||
The HiP05 PERISUB system controller is shared by peripheral controllers in
|
||||
HiP05 Soc to implement some basic configurations. The peripheral
|
||||
controllers include mdio, ddr, iic, uart, timer and so on.
|
||||
|
||||
Example:
|
||||
/* for HiP05 perisub-ctrl-c system */
|
||||
peri_c_subctrl: syscon@80000000 {
|
||||
compatible = "hisilicon,hip05-perisubc", "syscon";
|
||||
reg = <0x0 0x80000000 0x0 0x10000>;
|
||||
};
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon CPU controller
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
* ARM L2 Cache Controller
|
||||
|
||||
ARM cores often have a separate level 2 cache controller. There are various
|
||||
implementations of the L2 cache controller with compatible programming models.
|
||||
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
|
||||
PL310 and variants) based level 2 cache controller. All these various implementations
|
||||
of the L2 cache controller have compatible programming models (Note 1).
|
||||
Some of the properties that are just prefixed "cache-*" are taken from section
|
||||
3.7.3 of the ePAPR v1.1 specification which can be found at:
|
||||
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
|
||||
|
|
@ -67,12 +68,17 @@ Optional properties:
|
|||
disable if zero.
|
||||
- arm,prefetch-offset : Override prefetch offset value. Valid values are
|
||||
0-7, 15, 23, and 31.
|
||||
- arm,shared-override : The default behavior of the pl310 cache controller with
|
||||
respect to the shareable attribute is to transform "normal memory
|
||||
non-cacheable transactions" into "cacheable no allocate" (for reads) or
|
||||
"write through no write allocate" (for writes).
|
||||
- arm,shared-override : The default behavior of the L220 or PL310 cache
|
||||
controllers with respect to the shareable attribute is to transform "normal
|
||||
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
|
||||
or "write through no write allocate" (for writes).
|
||||
On systems where this may cause DMA buffer corruption, this property must be
|
||||
specified to indicate that such transforms are precluded.
|
||||
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
|
||||
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
|
||||
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
|
||||
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
|
||||
will randomly hang unless outer sync operations are disabled.
|
||||
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
|
||||
(forcibly enable), property absent (retain settings set by firmware)
|
||||
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
|
||||
|
|
@ -91,3 +97,9 @@ L2: cache-controller {
|
|||
cache-level = <2>;
|
||||
interrupts = <45>;
|
||||
};
|
||||
|
||||
Note 1: The description in this document doesn't apply to integrated L2
|
||||
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
|
||||
integrated L2 controllers are assumed to be all preconfigured by
|
||||
early secure boot code. Thus no need to deal with their configuration
|
||||
in the kernel at all.
|
||||
|
|
@ -24,6 +24,8 @@ board. Currently known boards are:
|
|||
"buffalo,lswxl"
|
||||
"buffalo,lsxhl"
|
||||
"buffalo,lsxl"
|
||||
"cloudengines,pogo02"
|
||||
"cloudengines,pogoplugv4"
|
||||
"dlink,dns-320"
|
||||
"dlink,dns-320-a1"
|
||||
"dlink,dns-325"
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ following property:
|
|||
Required root node property:
|
||||
|
||||
compatible: Must contain one of
|
||||
"mediatek,mt2701"
|
||||
"mediatek,mt6580"
|
||||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
|
|
@ -17,6 +18,9 @@ compatible: Must contain one of
|
|||
|
||||
Supported boards:
|
||||
|
||||
- Evaluation board for MT2701:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt2701-evb", "mediatek,mt2701";
|
||||
- Evaluation board for MT6580:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
|||
Also it uses the common reset controller binding from
|
||||
Documentation/devicetree/bindings/reset/reset.txt.
|
||||
The available reset outputs are defined in
|
||||
dt-bindings/reset-controller/mt*-resets.h
|
||||
dt-bindings/reset/mt*-resets.h
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
|||
Also it uses the common reset controller binding from
|
||||
Documentation/devicetree/bindings/reset/reset.txt.
|
||||
The available reset outputs are defined in
|
||||
dt-bindings/reset-controller/mt*-resets.h
|
||||
dt-bindings/reset/mt*-resets.h
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ Optional properties:
|
|||
during suspend.
|
||||
- ti,no-reset-on-init: When present, the module should not be reset at init
|
||||
- ti,no-idle-on-init: When present, the module should not be idled at init
|
||||
- ti,no-idle: When present, the module is never allowed to idle.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -138,9 +139,21 @@ Boards:
|
|||
- AM335X phyBOARD-WEGA: Single Board Computer dev kit
|
||||
compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
|
||||
|
||||
- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
|
||||
compatible = "compulab,cm-t335", "ti,am33xx"
|
||||
|
||||
- AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4
|
||||
compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx"
|
||||
|
||||
- OMAP5 EVM : Evaluation Module
|
||||
compatible = "ti,omap5-evm", "ti,omap5"
|
||||
|
||||
- AM437x CM-T43
|
||||
compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
|
||||
|
||||
- AM437x SBC-T43
|
||||
compatible = "compulab,am437x-sbc-t43", "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
|
||||
|
||||
- AM43x EPOS EVM
|
||||
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
|
||||
|
||||
|
|
@ -150,6 +163,12 @@ Boards:
|
|||
- AM437x SK EVM: AM437x StarterKit Evaluation Module
|
||||
compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
|
||||
|
||||
- AM57XX CL-SOM-AM57x
|
||||
compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
- AM57XX SBC-AM57x
|
||||
compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
- DRA742 EVM: Software Development Board for DRA742
|
||||
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
|
||||
|
||||
|
|
|
|||
|
|
@ -9,8 +9,9 @@ Required properties:
|
|||
- compatible : should be one of
|
||||
"apm,potenza-pmu"
|
||||
"arm,armv8-pmuv3"
|
||||
"arm.cortex-a57-pmu"
|
||||
"arm.cortex-a53-pmu"
|
||||
"arm,cortex-a72-pmu"
|
||||
"arm,cortex-a57-pmu"
|
||||
"arm,cortex-a53-pmu"
|
||||
"arm,cortex-a17-pmu"
|
||||
"arm,cortex-a15-pmu"
|
||||
"arm,cortex-a12-pmu"
|
||||
|
|
|
|||
|
|
@ -23,17 +23,20 @@ Main node required properties:
|
|||
|
||||
- compatible : should contain at least one of:
|
||||
|
||||
* "arm,psci" : for implementations complying to PSCI versions prior to
|
||||
0.2. For these cases function IDs must be provided.
|
||||
* "arm,psci" : For implementations complying to PSCI versions prior
|
||||
to 0.2.
|
||||
For these cases function IDs must be provided.
|
||||
|
||||
* "arm,psci-0.2" : for implementations complying to PSCI 0.2. Function
|
||||
IDs are not required and should be ignored by an OS with PSCI 0.2
|
||||
support, but are permitted to be present for compatibility with
|
||||
existing software when "arm,psci" is later in the compatible list.
|
||||
* "arm,psci-0.2" : For implementations complying to PSCI 0.2.
|
||||
Function IDs are not required and should be ignored by
|
||||
an OS with PSCI 0.2 support, but are permitted to be
|
||||
present for compatibility with existing software when
|
||||
"arm,psci" is later in the compatible list.
|
||||
|
||||
* "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is
|
||||
backward compatible with PSCI 0.2 with minor specification updates,
|
||||
as defined in the PSCI specification[2].
|
||||
* "arm,psci-1.0" : For implementations complying to PSCI 1.0.
|
||||
PSCI 1.0 is backward compatible with PSCI 0.2 with
|
||||
minor specification updates, as defined in the PSCI
|
||||
specification[2].
|
||||
|
||||
- method : The method of calling the PSCI firmware. Permitted
|
||||
values are:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,10 @@
|
|||
Rockchip platforms device tree bindings
|
||||
---------------------------------------
|
||||
|
||||
- Kylin RK3036 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
|
||||
|
||||
- MarsBoard RK3066 board:
|
||||
Required root node properties:
|
||||
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
|
||||
|
|
@ -35,6 +39,11 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "netxeon,r89", "rockchip,rk3288";
|
||||
|
||||
- Google Brain (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Jaq (Haier Chromebook 11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
|
||||
|
|
@ -49,6 +58,15 @@ Rockchip platforms device tree bindings
|
|||
"google,veyron-jerry-rev3", "google,veyron-jerry",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Mickey (Asus Chromebit CS10):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7",
|
||||
"google,veyron-mickey-rev6", "google,veyron-mickey-rev5",
|
||||
"google,veyron-mickey-rev4", "google,veyron-mickey-rev3",
|
||||
"google,veyron-mickey-rev2", "google,veyron-mickey-rev1",
|
||||
"google,veyron-mickey-rev0", "google,veyron-mickey",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Minnie (Asus Chromebook Flip C100P):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",
|
||||
|
|
@ -69,6 +87,14 @@ Rockchip platforms device tree bindings
|
|||
"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
|
||||
"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Rockchip RK3368 evb:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
|
||||
|
||||
- Rockchip R88 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,r88", "rockchip,rk3368";
|
||||
|
||||
- Rockchip RK3228 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
|
||||
|
|
|
|||
|
|
@ -47,6 +47,9 @@ Required properties:
|
|||
|
||||
- samsung,syscon-phandle Contains the PMU system controller node
|
||||
(To access the ADC_PHY register on Exynos5250/5420/5800/3250)
|
||||
Optional properties:
|
||||
- has-touchscreen: If present, indicates that a touchscreen is
|
||||
connected an usable.
|
||||
|
||||
Note: child nodes can be added for auto probing from device tree.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,10 +10,13 @@ References:
|
|||
Revision r2p0
|
||||
- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
|
||||
Revision r0p1
|
||||
- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
|
||||
Manial Revision r2p0
|
||||
|
||||
- compatible : Should be:
|
||||
"arm,cortex-a9-scu"
|
||||
"arm,cortex-a5-scu"
|
||||
"arm,arm11mp-scu"
|
||||
|
||||
- reg : Specify the base address and the size of the SCU register window.
|
||||
|
||||
|
|
|
|||
53
Documentation/devicetree/bindings/arm/secure.txt
Normal file
53
Documentation/devicetree/bindings/arm/secure.txt
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
* ARM Secure world bindings
|
||||
|
||||
ARM CPUs with TrustZone support have two distinct address spaces,
|
||||
"Normal" and "Secure". Most devicetree consumers (including the Linux
|
||||
kernel) are not TrustZone aware and run entirely in either the Normal
|
||||
world or the Secure world. However some devicetree consumers are
|
||||
TrustZone aware and need to be able to determine whether devices are
|
||||
visible only in the Secure address space, only in the Normal address
|
||||
space, or visible in both. (One example of that situation would be a
|
||||
virtual machine which boots Secure firmware and wants to tell the
|
||||
firmware about the layout of the machine via devicetree.)
|
||||
|
||||
The general principle of the naming scheme for Secure world bindings
|
||||
is that any property that needs a different value in the Secure world
|
||||
can be supported by prefixing the property name with "secure-". So for
|
||||
instance "secure-foo" would override "foo". For property names with
|
||||
a vendor prefix, the Secure variant of "vendor,foo" would be
|
||||
"vendor,secure-foo". If there is no "secure-" property then the Secure
|
||||
world value is the same as specified for the Normal world by the
|
||||
non-prefixed property. However, only the properties listed below may
|
||||
validly have "secure-" versions; this list will be enlarged on a
|
||||
case-by-case basis.
|
||||
|
||||
Defining the bindings in this way means that a device tree which has
|
||||
been annotated to indicate the presence of Secure-only devices can
|
||||
still be processed unmodified by existing Non-secure software (and in
|
||||
particular by the kernel).
|
||||
|
||||
Note that it is still valid for bindings intended for purely Secure
|
||||
world consumers (like kernels that run entirely in Secure) to simply
|
||||
describe the view of Secure world using the standard bindings. These
|
||||
secure- bindings only need to be used where both the Secure and Normal
|
||||
world views need to be described in a single device tree.
|
||||
|
||||
Valid Secure world properties:
|
||||
|
||||
- secure-status : specifies whether the device is present and usable
|
||||
in the secure world. The combination of this with "status" allows
|
||||
the various possible combinations of device visibility to be
|
||||
specified. If "secure-status" is not specified it defaults to the
|
||||
same value as "status"; if "status" is not specified either then
|
||||
both default to "okay". This means the following combinations are
|
||||
possible:
|
||||
|
||||
/* Neither specified: default to visible in both S and NS */
|
||||
secure-status = "okay"; /* visible in both */
|
||||
status = "okay"; /* visible in both */
|
||||
status = "okay"; secure-status = "okay"; /* visible in both */
|
||||
secure-status = "disabled"; /* NS-only */
|
||||
status = "okay"; secure-status = "disabled"; /* NS-only */
|
||||
status = "disabled"; secure-status = "okay"; /* S-only */
|
||||
status = "disabled"; /* disabled in both */
|
||||
status = "disabled"; secure-status = "disabled"; /* disabled in both */
|
||||
|
|
@ -27,6 +27,8 @@ SoCs:
|
|||
compatible = "renesas,r8a7793"
|
||||
- R-Car E2 (R8A77940)
|
||||
compatible = "renesas,r8a7794"
|
||||
- R-Car H3 (R8A77950)
|
||||
compatible = "renesas,r8a7795"
|
||||
|
||||
|
||||
Boards:
|
||||
|
|
@ -57,5 +59,7 @@ Boards:
|
|||
compatible = "renesas,marzen", "renesas,r8a7779"
|
||||
- Porter (M2-LCDP)
|
||||
compatible = "renesas,porter", "renesas,r8a7791"
|
||||
- Salvator-X (RTP0RC7795SIPB0010S)
|
||||
compatible = "renesas,salvator-x", "renesas,r8a7795";
|
||||
- SILK (RTP0RC7794LCB00011S)
|
||||
compatible = "renesas,silk", "renesas,r8a7794"
|
||||
|
|
|
|||
6
Documentation/devicetree/bindings/arm/technologic.txt
Normal file
6
Documentation/devicetree/bindings/arm/technologic.txt
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
Technologic Systems Platforms Device Tree Bindings
|
||||
--------------------------------------------------
|
||||
|
||||
TS-4800 board
|
||||
Required root node properties:
|
||||
- compatible = "technologic,imx51-ts4800", "fsl,imx51";
|
||||
|
|
@ -4,7 +4,9 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
|
|||
Each SATA controller should have its own node.
|
||||
|
||||
Required properties:
|
||||
- compatible : compatible list, may contain "brcm,bcm7445-ahci" and/or
|
||||
- compatible : should be one or more of
|
||||
"brcm,bcm7425-ahci"
|
||||
"brcm,bcm7445-ahci"
|
||||
"brcm,sata3-ahci"
|
||||
- reg : register mappings for AHCI and SATA_TOP_CTRL
|
||||
- reg-names : "ahci" and "top-ctrl"
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user