Merge branch 'linus/master' into rdma.git for-next
rdma.git merge resolution for the 4.19 merge window Conflicts: drivers/infiniband/core/rdma_core.c - Use the rdma code and revise with the new spelling for atomic_fetch_add_unless drivers/nvme/host/rdma.c - Replace max_sge with max_send_sge in new blk code drivers/nvme/target/rdma.c - Use the blk code and revise to use NULL for ib_post_recv when appropriate - Replace max_sge with max_recv_sge in new blk code net/rds/ib_send.c - Use the net code and revise to use NULL for ib_post_recv when appropriate Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
|
@ -382,7 +382,7 @@ IncludeIsMainRegex: '(Test)?$'
|
||||||
IndentCaseLabels: false
|
IndentCaseLabels: false
|
||||||
#IndentPPDirectives: None # Unknown to clang-format-5.0
|
#IndentPPDirectives: None # Unknown to clang-format-5.0
|
||||||
IndentWidth: 8
|
IndentWidth: 8
|
||||||
IndentWrappedFunctionNames: true
|
IndentWrappedFunctionNames: false
|
||||||
JavaScriptQuotes: Leave
|
JavaScriptQuotes: Leave
|
||||||
JavaScriptWrapImports: true
|
JavaScriptWrapImports: true
|
||||||
KeepEmptyLinesAtTheStartOfBlocks: false
|
KeepEmptyLinesAtTheStartOfBlocks: false
|
||||||
|
|
3
.mailmap
|
@ -83,6 +83,9 @@ Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||||
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
||||||
Jean Tourrilhes <jt@hpl.hp.com>
|
Jean Tourrilhes <jt@hpl.hp.com>
|
||||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||||
|
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||||
|
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||||
|
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||||
Jens Axboe <axboe@suse.de>
|
Jens Axboe <axboe@suse.de>
|
||||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||||
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||||
|
|
|
@ -11,7 +11,7 @@ KernelVersion: v2.6.22
|
||||||
Contact: linux-wireless@vger.kernel.org,
|
Contact: linux-wireless@vger.kernel.org,
|
||||||
Description: The rfkill class subsystem folder.
|
Description: The rfkill class subsystem folder.
|
||||||
Each registered rfkill driver is represented by an rfkillX
|
Each registered rfkill driver is represented by an rfkillX
|
||||||
subfolder (X being an integer > 0).
|
subfolder (X being an integer >= 0).
|
||||||
|
|
||||||
|
|
||||||
What: /sys/class/rfkill/rfkill[0-9]+/name
|
What: /sys/class/rfkill/rfkill[0-9]+/name
|
||||||
|
@ -48,8 +48,8 @@ Contact: linux-wireless@vger.kernel.org
|
||||||
Description: Current state of the transmitter.
|
Description: Current state of the transmitter.
|
||||||
This file was scheduled to be removed in 2014, but due to its
|
This file was scheduled to be removed in 2014, but due to its
|
||||||
large number of users it will be sticking around for a bit
|
large number of users it will be sticking around for a bit
|
||||||
longer. Despite it being marked as stabe, the newer "hard" and
|
longer. Despite it being marked as stable, the newer "hard" and
|
||||||
"soft" interfaces should be preffered, since it is not possible
|
"soft" interfaces should be preferred, since it is not possible
|
||||||
to express the 'soft and hard block' state of the rfkill driver
|
to express the 'soft and hard block' state of the rfkill driver
|
||||||
through this interface. There will likely be another attempt to
|
through this interface. There will likely be another attempt to
|
||||||
remove it in the future.
|
remove it in the future.
|
||||||
|
|
|
@ -5,6 +5,7 @@ Description:
|
||||||
The /proc/diskstats file displays the I/O statistics
|
The /proc/diskstats file displays the I/O statistics
|
||||||
of block devices. Each line contains the following 14
|
of block devices. Each line contains the following 14
|
||||||
fields:
|
fields:
|
||||||
|
|
||||||
1 - major number
|
1 - major number
|
||||||
2 - minor mumber
|
2 - minor mumber
|
||||||
3 - device name
|
3 - device name
|
||||||
|
@ -19,4 +20,13 @@ Description:
|
||||||
12 - I/Os currently in progress
|
12 - I/Os currently in progress
|
||||||
13 - time spent doing I/Os (ms)
|
13 - time spent doing I/Os (ms)
|
||||||
14 - weighted time spent doing I/Os (ms)
|
14 - weighted time spent doing I/Os (ms)
|
||||||
|
|
||||||
|
Kernel 4.18+ appends four more fields for discard
|
||||||
|
tracking putting the total at 18:
|
||||||
|
|
||||||
|
15 - discards completed successfully
|
||||||
|
16 - discards merged
|
||||||
|
17 - sectors discarded
|
||||||
|
18 - time spent discarding
|
||||||
|
|
||||||
For more details refer to Documentation/iostats.txt
|
For more details refer to Documentation/iostats.txt
|
||||||
|
|
122
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
Normal file
|
@ -0,0 +1,122 @@
|
||||||
|
==========================
|
||||||
|
PCIe Device AER statistics
|
||||||
|
==========================
|
||||||
|
These attributes show up under all the devices that are AER capable. These
|
||||||
|
statistical counters indicate the errors "as seen/reported by the device".
|
||||||
|
Note that this may mean that if an endpoint is causing problems, the AER
|
||||||
|
counters may increment at its link partner (e.g. root port) because the
|
||||||
|
errors may be "seen" / reported by the link partner and not the
|
||||||
|
problematic endpoint itself (which may report all counters as 0 as it never
|
||||||
|
saw any problems).
|
||||||
|
|
||||||
|
Where: /sys/bus/pci/devices/<dev>/aer_dev_correctable
|
||||||
|
Date: July 2018
|
||||||
|
Kernel Version: 4.19.0
|
||||||
|
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||||
|
Description: List of correctable errors seen and reported by this
|
||||||
|
PCI device using ERR_COR. Note that since multiple errors may
|
||||||
|
be reported using a single ERR_COR message, thus
|
||||||
|
TOTAL_ERR_COR at the end of the file may not match the actual
|
||||||
|
total of all the errors in the file. Sample output:
|
||||||
|
-------------------------------------------------------------------------
|
||||||
|
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_correctable
|
||||||
|
Receiver Error 2
|
||||||
|
Bad TLP 0
|
||||||
|
Bad DLLP 0
|
||||||
|
RELAY_NUM Rollover 0
|
||||||
|
Replay Timer Timeout 0
|
||||||
|
Advisory Non-Fatal 0
|
||||||
|
Corrected Internal Error 0
|
||||||
|
Header Log Overflow 0
|
||||||
|
TOTAL_ERR_COR 2
|
||||||
|
-------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Where: /sys/bus/pci/devices/<dev>/aer_dev_fatal
|
||||||
|
Date: July 2018
|
||||||
|
Kernel Version: 4.19.0
|
||||||
|
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||||
|
Description: List of uncorrectable fatal errors seen and reported by this
|
||||||
|
PCI device using ERR_FATAL. Note that since multiple errors may
|
||||||
|
be reported using a single ERR_FATAL message, thus
|
||||||
|
TOTAL_ERR_FATAL at the end of the file may not match the actual
|
||||||
|
total of all the errors in the file. Sample output:
|
||||||
|
-------------------------------------------------------------------------
|
||||||
|
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_fatal
|
||||||
|
Undefined 0
|
||||||
|
Data Link Protocol 0
|
||||||
|
Surprise Down Error 0
|
||||||
|
Poisoned TLP 0
|
||||||
|
Flow Control Protocol 0
|
||||||
|
Completion Timeout 0
|
||||||
|
Completer Abort 0
|
||||||
|
Unexpected Completion 0
|
||||||
|
Receiver Overflow 0
|
||||||
|
Malformed TLP 0
|
||||||
|
ECRC 0
|
||||||
|
Unsupported Request 0
|
||||||
|
ACS Violation 0
|
||||||
|
Uncorrectable Internal Error 0
|
||||||
|
MC Blocked TLP 0
|
||||||
|
AtomicOp Egress Blocked 0
|
||||||
|
TLP Prefix Blocked Error 0
|
||||||
|
TOTAL_ERR_FATAL 0
|
||||||
|
-------------------------------------------------------------------------
|
||||||
|
|
||||||
|
Where: /sys/bus/pci/devices/<dev>/aer_dev_nonfatal
|
||||||
|
Date: July 2018
|
||||||
|
Kernel Version: 4.19.0
|
||||||
|
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||||
|
Description: List of uncorrectable nonfatal errors seen and reported by this
|
||||||
|
PCI device using ERR_NONFATAL. Note that since multiple errors
|
||||||
|
may be reported using a single ERR_FATAL message, thus
|
||||||
|
TOTAL_ERR_NONFATAL at the end of the file may not match the
|
||||||
|
actual total of all the errors in the file. Sample output:
|
||||||
|
-------------------------------------------------------------------------
|
||||||
|
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_nonfatal
|
||||||
|
Undefined 0
|
||||||
|
Data Link Protocol 0
|
||||||
|
Surprise Down Error 0
|
||||||
|
Poisoned TLP 0
|
||||||
|
Flow Control Protocol 0
|
||||||
|
Completion Timeout 0
|
||||||
|
Completer Abort 0
|
||||||
|
Unexpected Completion 0
|
||||||
|
Receiver Overflow 0
|
||||||
|
Malformed TLP 0
|
||||||
|
ECRC 0
|
||||||
|
Unsupported Request 0
|
||||||
|
ACS Violation 0
|
||||||
|
Uncorrectable Internal Error 0
|
||||||
|
MC Blocked TLP 0
|
||||||
|
AtomicOp Egress Blocked 0
|
||||||
|
TLP Prefix Blocked Error 0
|
||||||
|
TOTAL_ERR_NONFATAL 0
|
||||||
|
-------------------------------------------------------------------------
|
||||||
|
|
||||||
|
============================
|
||||||
|
PCIe Rootport AER statistics
|
||||||
|
============================
|
||||||
|
These attributes show up under only the rootports (or root complex event
|
||||||
|
collectors) that are AER capable. These indicate the number of error messages as
|
||||||
|
"reported to" the rootport. Please note that the rootports also transmit
|
||||||
|
(internally) the ERR_* messages for errors seen by the internal rootport PCI
|
||||||
|
device, so these counters include them and are thus cumulative of all the error
|
||||||
|
messages on the PCI hierarchy originating at that root port.
|
||||||
|
|
||||||
|
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_cor
|
||||||
|
Date: July 2018
|
||||||
|
Kernel Version: 4.19.0
|
||||||
|
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||||
|
Description: Total number of ERR_COR messages reported to rootport.
|
||||||
|
|
||||||
|
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_fatal
|
||||||
|
Date: July 2018
|
||||||
|
Kernel Version: 4.19.0
|
||||||
|
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||||
|
Description: Total number of ERR_FATAL messages reported to rootport.
|
||||||
|
|
||||||
|
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_nonfatal
|
||||||
|
Date: July 2018
|
||||||
|
Kernel Version: 4.19.0
|
||||||
|
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||||
|
Description: Total number of ERR_NONFATAL messages reported to rootport.
|
|
@ -42,6 +42,17 @@ Description:
|
||||||
network device transmit queue. Possible vaules depend on the
|
network device transmit queue. Possible vaules depend on the
|
||||||
number of available CPU(s) in the system.
|
number of available CPU(s) in the system.
|
||||||
|
|
||||||
|
What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
|
||||||
|
Date: June 2018
|
||||||
|
KernelVersion: 4.18.0
|
||||||
|
Contact: netdev@vger.kernel.org
|
||||||
|
Description:
|
||||||
|
Mask of the receive queue(s) currently enabled to participate
|
||||||
|
into the Transmit Packet Steering packet processing flow for this
|
||||||
|
network device transmit queue. Possible values depend on the
|
||||||
|
number of available receive queue(s) in the network device.
|
||||||
|
Default is disabled.
|
||||||
|
|
||||||
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
|
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
|
||||||
Date: November 2011
|
Date: November 2011
|
||||||
KernelVersion: 3.3
|
KernelVersion: 3.3
|
||||||
|
|
|
@ -476,6 +476,7 @@ What: /sys/devices/system/cpu/vulnerabilities
|
||||||
/sys/devices/system/cpu/vulnerabilities/spectre_v1
|
/sys/devices/system/cpu/vulnerabilities/spectre_v1
|
||||||
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
||||||
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
|
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
|
||||||
|
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||||
Date: January 2018
|
Date: January 2018
|
||||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||||
Description: Information about CPU vulnerabilities
|
Description: Information about CPU vulnerabilities
|
||||||
|
@ -487,3 +488,26 @@ Description: Information about CPU vulnerabilities
|
||||||
"Not affected" CPU is not affected by the vulnerability
|
"Not affected" CPU is not affected by the vulnerability
|
||||||
"Vulnerable" CPU is affected and no mitigation in effect
|
"Vulnerable" CPU is affected and no mitigation in effect
|
||||||
"Mitigation: $M" CPU is affected and mitigation $M is in effect
|
"Mitigation: $M" CPU is affected and mitigation $M is in effect
|
||||||
|
|
||||||
|
Details about the l1tf file can be found in
|
||||||
|
Documentation/admin-guide/l1tf.rst
|
||||||
|
|
||||||
|
What: /sys/devices/system/cpu/smt
|
||||||
|
/sys/devices/system/cpu/smt/active
|
||||||
|
/sys/devices/system/cpu/smt/control
|
||||||
|
Date: June 2018
|
||||||
|
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||||
|
Description: Control Symetric Multi Threading (SMT)
|
||||||
|
|
||||||
|
active: Tells whether SMT is active (enabled and siblings online)
|
||||||
|
|
||||||
|
control: Read/write interface to control SMT. Possible
|
||||||
|
values:
|
||||||
|
|
||||||
|
"on" SMT is enabled
|
||||||
|
"off" SMT is disabled
|
||||||
|
"forceoff" SMT is force disabled. Cannot be changed.
|
||||||
|
"notsupported" SMT is not supported by the CPU
|
||||||
|
|
||||||
|
If control status is "forceoff" or "notsupported" writes
|
||||||
|
are rejected.
|
||||||
|
|
27
Documentation/ABI/testing/sysfs-driver-bd9571mwv-regulator
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
What: /sys/bus/i2c/devices/.../bd9571mwv-regulator.*.auto/backup_mode
|
||||||
|
Date: Jul 2018
|
||||||
|
KernelVersion: 4.19
|
||||||
|
Contact: Geert Uytterhoeven <geert+renesas@glider.be>
|
||||||
|
Description: Read/write the current state of DDR Backup Mode, which controls
|
||||||
|
if DDR power rails will be kept powered during system suspend.
|
||||||
|
("on"/"1" = enabled, "off"/"0" = disabled).
|
||||||
|
Two types of power switches (or control signals) can be used:
|
||||||
|
A. With a momentary power switch (or pulse signal), DDR
|
||||||
|
Backup Mode is enabled by default when available, as the
|
||||||
|
PMIC will be configured only during system suspend.
|
||||||
|
B. With a toggle power switch (or level signal), the
|
||||||
|
following steps must be followed exactly:
|
||||||
|
1. Configure PMIC for backup mode, to change the role of
|
||||||
|
the accessory power switch from a power switch to a
|
||||||
|
wake-up switch,
|
||||||
|
2. Switch accessory power switch off, to prepare for
|
||||||
|
system suspend, which is a manual step not controlled
|
||||||
|
by software,
|
||||||
|
3. Suspend system,
|
||||||
|
4. Switch accessory power switch on, to resume the
|
||||||
|
system.
|
||||||
|
DDR Backup Mode must be explicitly enabled by the user,
|
||||||
|
to invoke step 1.
|
||||||
|
See also Documentation/devicetree/bindings/mfd/bd9571mwv.txt.
|
||||||
|
Users: User space applications for embedded boards equipped with a
|
||||||
|
BD9571MWV PMIC.
|
|
@ -1,5 +1,7 @@
|
||||||
00-INDEX
|
00-INDEX
|
||||||
- this file
|
- this file
|
||||||
|
acpi-info.txt
|
||||||
|
- info on how PCI host bridges are represented in ACPI
|
||||||
MSI-HOWTO.txt
|
MSI-HOWTO.txt
|
||||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
||||||
PCIEBUS-HOWTO.txt
|
PCIEBUS-HOWTO.txt
|
||||||
|
|
187
Documentation/PCI/acpi-info.txt
Normal file
|
@ -0,0 +1,187 @@
|
||||||
|
ACPI considerations for PCI host bridges
|
||||||
|
|
||||||
|
The general rule is that the ACPI namespace should describe everything the
|
||||||
|
OS might use unless there's another way for the OS to find it [1, 2].
|
||||||
|
|
||||||
|
For example, there's no standard hardware mechanism for enumerating PCI
|
||||||
|
host bridges, so the ACPI namespace must describe each host bridge, the
|
||||||
|
method for accessing PCI config space below it, the address space windows
|
||||||
|
the host bridge forwards to PCI (using _CRS), and the routing of legacy
|
||||||
|
INTx interrupts (using _PRT).
|
||||||
|
|
||||||
|
PCI devices, which are below the host bridge, generally do not need to be
|
||||||
|
described via ACPI. The OS can discover them via the standard PCI
|
||||||
|
enumeration mechanism, using config accesses to discover and identify
|
||||||
|
devices and read and size their BARs. However, ACPI may describe PCI
|
||||||
|
devices if it provides power management or hotplug functionality for them
|
||||||
|
or if the device has INTx interrupts connected by platform interrupt
|
||||||
|
controllers and a _PRT is needed to describe those connections.
|
||||||
|
|
||||||
|
ACPI resource description is done via _CRS objects of devices in the ACPI
|
||||||
|
namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
|
||||||
|
_CRS and figure out what resource is being consumed even if it doesn't have
|
||||||
|
a driver for the device [3]. That's important because it means an old OS
|
||||||
|
can work correctly even on a system with new devices unknown to the OS.
|
||||||
|
The new devices might not do anything, but the OS can at least make sure no
|
||||||
|
resources conflict with them.
|
||||||
|
|
||||||
|
Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
|
||||||
|
reserving address space. The static tables are for things the OS needs to
|
||||||
|
know early in boot, before it can parse the ACPI namespace. If a new table
|
||||||
|
is defined, an old OS needs to operate correctly even though it ignores the
|
||||||
|
table. _CRS allows that because it is generic and understood by the old
|
||||||
|
OS; a static table does not.
|
||||||
|
|
||||||
|
If the OS is expected to manage a non-discoverable device described via
|
||||||
|
ACPI, that device will have a specific _HID/_CID that tells the OS what
|
||||||
|
driver to bind to it, and the _CRS tells the OS and the driver where the
|
||||||
|
device's registers are.
|
||||||
|
|
||||||
|
PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
|
||||||
|
describe all the address space they consume. This includes all the windows
|
||||||
|
they forward down to the PCI bus, as well as registers of the host bridge
|
||||||
|
itself that are not forwarded to PCI. The host bridge registers include
|
||||||
|
things like secondary/subordinate bus registers that determine the bus
|
||||||
|
range below the bridge, window registers that describe the apertures, etc.
|
||||||
|
These are all device-specific, non-architected things, so the only way a
|
||||||
|
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
|
||||||
|
the device-specific details. The host bridge registers also include ECAM
|
||||||
|
space, since it is consumed by the host bridge.
|
||||||
|
|
||||||
|
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
|
||||||
|
("Consumer") from the bridge apertures ("Producer") [4, 5], but early
|
||||||
|
BIOSes didn't use that bit correctly. The result is that the current ACPI
|
||||||
|
spec defines Consumer/Producer only for the Extended Address Space
|
||||||
|
descriptors; the bit should be ignored in the older QWord/DWord/Word
|
||||||
|
Address Space descriptors. Consequently, OSes have to assume all
|
||||||
|
QWord/DWord/Word descriptors are windows.
|
||||||
|
|
||||||
|
Prior to the addition of Extended Address Space descriptors, the failure of
|
||||||
|
Consumer/Producer meant there was no way to describe bridge registers in
|
||||||
|
the PNP0A03/PNP0A08 device itself. The workaround was to describe the
|
||||||
|
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
|
||||||
|
With the exception of ECAM, the bridge register space is device-specific
|
||||||
|
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
|
||||||
|
know about it.
|
||||||
|
|
||||||
|
New architectures should be able to use "Consumer" Extended Address Space
|
||||||
|
descriptors in the PNP0A03 device for bridge registers, including ECAM,
|
||||||
|
although a strict interpretation of [6] might prohibit this. Old x86 and
|
||||||
|
ia64 kernels assume all address space descriptors, including "Consumer"
|
||||||
|
Extended Address Space ones, are windows, so it would not be safe to
|
||||||
|
describe bridge registers this way on those architectures.
|
||||||
|
|
||||||
|
PNP0C02 "motherboard" devices are basically a catch-all. There's no
|
||||||
|
programming model for them other than "don't use these resources for
|
||||||
|
anything else." So a PNP0C02 _CRS should claim any address space that is
|
||||||
|
(1) not claimed by _CRS under any other device object in the ACPI namespace
|
||||||
|
and (2) should not be assigned by the OS to something else.
|
||||||
|
|
||||||
|
The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
|
||||||
|
unless there's a standard firmware interface for config access, e.g., the
|
||||||
|
ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
|
||||||
|
and converts memory accesses into PCI configuration accesses. The spec
|
||||||
|
defines the ECAM address space layout and functionality; only the base of
|
||||||
|
the address space is device-specific. An ACPI OS learns the base address
|
||||||
|
from either the static MCFG table or a _CBA method in the PNP0A03 device.
|
||||||
|
|
||||||
|
The MCFG table must describe the ECAM space of non-hot pluggable host
|
||||||
|
bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
|
||||||
|
a _CBA method in the PNP0A03 device describes the ECAM space of a
|
||||||
|
hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
|
||||||
|
address always corresponds to bus 0, even if the bus range below the bridge
|
||||||
|
(which is reported via _CRS) doesn't start at 0.
|
||||||
|
|
||||||
|
|
||||||
|
[1] ACPI 6.2, sec 6.1:
|
||||||
|
For any device that is on a non-enumerable type of bus (for example, an
|
||||||
|
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
|
||||||
|
system firmware must supply an _HID object ... for each device to
|
||||||
|
enable OSPM to do that.
|
||||||
|
|
||||||
|
[2] ACPI 6.2, sec 3.7:
|
||||||
|
The OS enumerates motherboard devices simply by reading through the
|
||||||
|
ACPI Namespace looking for devices with hardware IDs.
|
||||||
|
|
||||||
|
Each device enumerated by ACPI includes ACPI-defined objects in the
|
||||||
|
ACPI Namespace that report the hardware resources the device could
|
||||||
|
occupy [_PRS], an object that reports the resources that are currently
|
||||||
|
used by the device [_CRS], and objects for configuring those resources
|
||||||
|
[_SRS]. The information is used by the Plug and Play OS (OSPM) to
|
||||||
|
configure the devices.
|
||||||
|
|
||||||
|
[3] ACPI 6.2, sec 6.2:
|
||||||
|
OSPM uses device configuration objects to configure hardware resources
|
||||||
|
for devices enumerated via ACPI. Device configuration objects provide
|
||||||
|
information about current and possible resource requirements, the
|
||||||
|
relationship between shared resources, and methods for configuring
|
||||||
|
hardware resources.
|
||||||
|
|
||||||
|
When OSPM enumerates a device, it calls _PRS to determine the resource
|
||||||
|
requirements of the device. It may also call _CRS to find the current
|
||||||
|
resource settings for the device. Using this information, the Plug and
|
||||||
|
Play system determines what resources the device should consume and
|
||||||
|
sets those resources by calling the device’s _SRS control method.
|
||||||
|
|
||||||
|
In ACPI, devices can consume resources (for example, legacy keyboards),
|
||||||
|
provide resources (for example, a proprietary PCI bridge), or do both.
|
||||||
|
Unless otherwise specified, resources for a device are assumed to be
|
||||||
|
taken from the nearest matching resource above the device in the device
|
||||||
|
hierarchy.
|
||||||
|
|
||||||
|
[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
|
||||||
|
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
|
||||||
|
General Flags: Bit [0] Ignored
|
||||||
|
|
||||||
|
Extended Address Space Descriptor (.4)
|
||||||
|
General Flags: Bit [0] Consumer/Producer:
|
||||||
|
1–This device consumes this resource
|
||||||
|
0–This device produces and consumes this resource
|
||||||
|
|
||||||
|
[5] ACPI 6.2, sec 19.6.43:
|
||||||
|
ResourceUsage specifies whether the Memory range is consumed by
|
||||||
|
this device (ResourceConsumer) or passed on to child devices
|
||||||
|
(ResourceProducer). If nothing is specified, then
|
||||||
|
ResourceConsumer is assumed.
|
||||||
|
|
||||||
|
[6] PCI Firmware 3.2, sec 4.1.2:
|
||||||
|
If the operating system does not natively comprehend reserving the
|
||||||
|
MMCFG region, the MMCFG region must be reserved by firmware. The
|
||||||
|
address range reported in the MCFG table or by _CBA method (see Section
|
||||||
|
4.1.3) must be reserved by declaring a motherboard resource. For most
|
||||||
|
systems, the motherboard resource would appear at the root of the ACPI
|
||||||
|
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
|
||||||
|
the resources in this case should not be claimed in the root PCI bus’s
|
||||||
|
_CRS. The resources can optionally be returned in Int15 E820 or
|
||||||
|
EFIGetMemoryMap as reserved memory but must always be reported through
|
||||||
|
ACPI as a motherboard resource.
|
||||||
|
|
||||||
|
[7] PCI Express 4.0, sec 7.2.2:
|
||||||
|
For systems that are PC-compatible, or that do not implement a
|
||||||
|
processor-architecture-specific firmware interface standard that allows
|
||||||
|
access to the Configuration Space, the ECAM is required as defined in
|
||||||
|
this section.
|
||||||
|
|
||||||
|
[8] PCI Firmware 3.2, sec 4.1.2:
|
||||||
|
The MCFG table is an ACPI table that is used to communicate the base
|
||||||
|
addresses corresponding to the non-hot removable PCI Segment Groups
|
||||||
|
range within a PCI Segment Group available to the operating system at
|
||||||
|
boot. This is required for the PC-compatible systems.
|
||||||
|
|
||||||
|
The MCFG table is only used to communicate the base addresses
|
||||||
|
corresponding to the PCI Segment Groups available to the system at
|
||||||
|
boot.
|
||||||
|
|
||||||
|
[9] PCI Firmware 3.2, sec 4.1.3:
|
||||||
|
The _CBA (Memory mapped Configuration Base Address) control method is
|
||||||
|
an optional ACPI object that returns the 64-bit memory mapped
|
||||||
|
configuration base address for the hot plug capable host bridge. The
|
||||||
|
base address returned by _CBA is processor-relative address. The _CBA
|
||||||
|
control method evaluates to an Integer.
|
||||||
|
|
||||||
|
This control method appears under a host bridge object. When the _CBA
|
||||||
|
method appears under an active host bridge object, the operating system
|
||||||
|
evaluates this structure to identify the memory mapped configuration
|
||||||
|
base address corresponding to the PCI Segment Group for the bus number
|
||||||
|
range specified in _CRS method. An ACPI name space object that contains
|
||||||
|
the _CBA method must also contain a corresponding _SEG method.
|
|
@ -15,3 +15,5 @@ subsys_id : don't care
|
||||||
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
|
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
|
||||||
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
|
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
|
||||||
to test
|
to test
|
||||||
|
msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
|
||||||
|
interrupts to test
|
||||||
|
|
|
@ -44,7 +44,7 @@ by the PCI controller driver.
|
||||||
* clear_bar: ops to reset the BAR
|
* clear_bar: ops to reset the BAR
|
||||||
* alloc_addr_space: ops to allocate in PCI controller address space
|
* alloc_addr_space: ops to allocate in PCI controller address space
|
||||||
* free_addr_space: ops to free the allocated address space
|
* free_addr_space: ops to free the allocated address space
|
||||||
* raise_irq: ops to raise a legacy or MSI interrupt
|
* raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
|
||||||
* start: ops to start the PCI link
|
* start: ops to start the PCI link
|
||||||
* stop: ops to stop the PCI link
|
* stop: ops to stop the PCI link
|
||||||
|
|
||||||
|
@ -96,7 +96,7 @@ by the PCI endpoint function driver.
|
||||||
*) pci_epc_raise_irq()
|
*) pci_epc_raise_irq()
|
||||||
|
|
||||||
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
|
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
|
||||||
Legacy Interrupt or MSI Interrupt.
|
Legacy Interrupt, MSI or MSI-X Interrupt.
|
||||||
|
|
||||||
*) pci_epc_mem_alloc_addr()
|
*) pci_epc_mem_alloc_addr()
|
||||||
|
|
||||||
|
|
|
@ -20,6 +20,8 @@ The PCI endpoint test device has the following registers:
|
||||||
5) PCI_ENDPOINT_TEST_DST_ADDR
|
5) PCI_ENDPOINT_TEST_DST_ADDR
|
||||||
6) PCI_ENDPOINT_TEST_SIZE
|
6) PCI_ENDPOINT_TEST_SIZE
|
||||||
7) PCI_ENDPOINT_TEST_CHECKSUM
|
7) PCI_ENDPOINT_TEST_CHECKSUM
|
||||||
|
8) PCI_ENDPOINT_TEST_IRQ_TYPE
|
||||||
|
9) PCI_ENDPOINT_TEST_IRQ_NUMBER
|
||||||
|
|
||||||
*) PCI_ENDPOINT_TEST_MAGIC
|
*) PCI_ENDPOINT_TEST_MAGIC
|
||||||
|
|
||||||
|
@ -34,10 +36,10 @@ that the endpoint device must perform.
|
||||||
Bitfield Description:
|
Bitfield Description:
|
||||||
Bit 0 : raise legacy IRQ
|
Bit 0 : raise legacy IRQ
|
||||||
Bit 1 : raise MSI IRQ
|
Bit 1 : raise MSI IRQ
|
||||||
Bit 2 - 7 : MSI interrupt number
|
Bit 2 : raise MSI-X IRQ
|
||||||
Bit 8 : read command (read data from RC buffer)
|
Bit 3 : read command (read data from RC buffer)
|
||||||
Bit 9 : write command (write data to RC buffer)
|
Bit 4 : write command (write data to RC buffer)
|
||||||
Bit 10 : copy command (copy data from one RC buffer to another
|
Bit 5 : copy command (copy data from one RC buffer to another
|
||||||
RC buffer)
|
RC buffer)
|
||||||
|
|
||||||
*) PCI_ENDPOINT_TEST_STATUS
|
*) PCI_ENDPOINT_TEST_STATUS
|
||||||
|
@ -64,3 +66,22 @@ COPY/READ command.
|
||||||
|
|
||||||
This register contains the destination address (RC buffer address) for
|
This register contains the destination address (RC buffer address) for
|
||||||
the COPY/WRITE command.
|
the COPY/WRITE command.
|
||||||
|
|
||||||
|
*) PCI_ENDPOINT_TEST_IRQ_TYPE
|
||||||
|
|
||||||
|
This register contains the interrupt type (Legacy/MSI) triggered
|
||||||
|
for the READ/WRITE/COPY and raise IRQ (Legacy/MSI) commands.
|
||||||
|
|
||||||
|
Possible types:
|
||||||
|
- Legacy : 0
|
||||||
|
- MSI : 1
|
||||||
|
- MSI-X : 2
|
||||||
|
|
||||||
|
*) PCI_ENDPOINT_TEST_IRQ_NUMBER
|
||||||
|
|
||||||
|
This register contains the triggered ID interrupt.
|
||||||
|
|
||||||
|
Admissible values:
|
||||||
|
- Legacy : 0
|
||||||
|
- MSI : [1 .. 32]
|
||||||
|
- MSI-X : [1 .. 2048]
|
||||||
|
|
|
@ -45,9 +45,9 @@ The PCI endpoint framework populates the directory with the following
|
||||||
configurable fields.
|
configurable fields.
|
||||||
|
|
||||||
# ls functions/pci_epf_test/func1
|
# ls functions/pci_epf_test/func1
|
||||||
baseclass_code interrupt_pin revid subsys_vendor_id
|
baseclass_code interrupt_pin progif_code subsys_id
|
||||||
cache_line_size msi_interrupts subclass_code vendorid
|
cache_line_size msi_interrupts revid subsys_vendorid
|
||||||
deviceid progif_code subsys_id
|
deviceid msix_interrupts subclass_code vendorid
|
||||||
|
|
||||||
The PCI endpoint function driver populates these entries with default values
|
The PCI endpoint function driver populates these entries with default values
|
||||||
when the device is bound to the driver. The pci-epf-test driver populates
|
when the device is bound to the driver. The pci-epf-test driver populates
|
||||||
|
@ -67,6 +67,7 @@ device, the following commands can be used.
|
||||||
# echo 0x104c > functions/pci_epf_test/func1/vendorid
|
# echo 0x104c > functions/pci_epf_test/func1/vendorid
|
||||||
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
|
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
|
||||||
# echo 16 > functions/pci_epf_test/func1/msi_interrupts
|
# echo 16 > functions/pci_epf_test/func1/msi_interrupts
|
||||||
|
# echo 8 > functions/pci_epf_test/func1/msix_interrupts
|
||||||
|
|
||||||
1.5 Binding pci-epf-test Device to EP Controller
|
1.5 Binding pci-epf-test Device to EP Controller
|
||||||
|
|
||||||
|
@ -120,7 +121,9 @@ following commands.
|
||||||
|
|
||||||
Interrupt tests
|
Interrupt tests
|
||||||
|
|
||||||
|
SET IRQ TYPE TO LEGACY: OKAY
|
||||||
LEGACY IRQ: NOT OKAY
|
LEGACY IRQ: NOT OKAY
|
||||||
|
SET IRQ TYPE TO MSI: OKAY
|
||||||
MSI1: OKAY
|
MSI1: OKAY
|
||||||
MSI2: OKAY
|
MSI2: OKAY
|
||||||
MSI3: OKAY
|
MSI3: OKAY
|
||||||
|
@ -153,9 +156,30 @@ following commands.
|
||||||
MSI30: NOT OKAY
|
MSI30: NOT OKAY
|
||||||
MSI31: NOT OKAY
|
MSI31: NOT OKAY
|
||||||
MSI32: NOT OKAY
|
MSI32: NOT OKAY
|
||||||
|
SET IRQ TYPE TO MSI-X: OKAY
|
||||||
|
MSI-X1: OKAY
|
||||||
|
MSI-X2: OKAY
|
||||||
|
MSI-X3: OKAY
|
||||||
|
MSI-X4: OKAY
|
||||||
|
MSI-X5: OKAY
|
||||||
|
MSI-X6: OKAY
|
||||||
|
MSI-X7: OKAY
|
||||||
|
MSI-X8: OKAY
|
||||||
|
MSI-X9: NOT OKAY
|
||||||
|
MSI-X10: NOT OKAY
|
||||||
|
MSI-X11: NOT OKAY
|
||||||
|
MSI-X12: NOT OKAY
|
||||||
|
MSI-X13: NOT OKAY
|
||||||
|
MSI-X14: NOT OKAY
|
||||||
|
MSI-X15: NOT OKAY
|
||||||
|
MSI-X16: NOT OKAY
|
||||||
|
[...]
|
||||||
|
MSI-X2047: NOT OKAY
|
||||||
|
MSI-X2048: NOT OKAY
|
||||||
|
|
||||||
Read Tests
|
Read Tests
|
||||||
|
|
||||||
|
SET IRQ TYPE TO MSI: OKAY
|
||||||
READ ( 1 bytes): OKAY
|
READ ( 1 bytes): OKAY
|
||||||
READ ( 1024 bytes): OKAY
|
READ ( 1024 bytes): OKAY
|
||||||
READ ( 1025 bytes): OKAY
|
READ ( 1025 bytes): OKAY
|
||||||
|
|
|
@ -73,6 +73,11 @@ In the example, 'Requester ID' means the ID of the device who sends
|
||||||
the error message to root port. Pls. refer to pci express specs for
|
the error message to root port. Pls. refer to pci express specs for
|
||||||
other fields.
|
other fields.
|
||||||
|
|
||||||
|
2.4 AER Statistics / Counters
|
||||||
|
|
||||||
|
When PCIe AER errors are captured, the counters / statistics are also exposed
|
||||||
|
in the form of sysfs attributes which are documented at
|
||||||
|
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
|
||||||
|
|
||||||
3. Developer Guide
|
3. Developer Guide
|
||||||
|
|
||||||
|
|
|
@ -380,31 +380,26 @@ and therefore need no protection.
|
||||||
as follows:
|
as follows:
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
1 unsigned long gpnum;
|
1 unsigned long gp_seq;
|
||||||
2 unsigned long completed;
|
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>RCU grace periods are numbered, and
|
<p>RCU grace periods are numbered, and
|
||||||
the <tt>->gpnum</tt> field contains the number of the grace
|
the <tt>->gp_seq</tt> field contains the current grace-period
|
||||||
period that started most recently.
|
sequence number.
|
||||||
The <tt>->completed</tt> field contains the number of the
|
The bottom two bits are the state of the current grace period,
|
||||||
grace period that completed most recently.
|
which can be zero for not yet started or one for in progress.
|
||||||
If the two fields are equal, the RCU grace period that most recently
|
In other words, if the bottom two bits of <tt>->gp_seq</tt> are
|
||||||
started has already completed, and therefore the corresponding
|
zero, the corresponding flavor of RCU is idle.
|
||||||
flavor of RCU is idle.
|
Any other value in the bottom two bits indicates that something is broken.
|
||||||
If <tt>->gpnum</tt> is one greater than <tt>->completed</tt>,
|
This field is protected by the root <tt>rcu_node</tt> structure's
|
||||||
then <tt>->gpnum</tt> gives the number of the current RCU
|
|
||||||
grace period, which has not yet completed.
|
|
||||||
Any other combination of values indicates that something is broken.
|
|
||||||
These two fields are protected by the root <tt>rcu_node</tt>'s
|
|
||||||
<tt>->lock</tt> field.
|
<tt>->lock</tt> field.
|
||||||
|
|
||||||
</p><p>There are <tt>->gpnum</tt> and <tt>->completed</tt> fields
|
</p><p>There are <tt>->gp_seq</tt> fields
|
||||||
in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
|
in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
|
||||||
as well.
|
as well.
|
||||||
The fields in the <tt>rcu_state</tt> structure represent the
|
The fields in the <tt>rcu_state</tt> structure represent the
|
||||||
most current values, and those of the other structures are compared
|
most current value, and those of the other structures are compared
|
||||||
in order to detect the start of a new grace period in a distributed
|
in order to detect the beginnings and ends of grace periods in a distributed
|
||||||
fashion.
|
fashion.
|
||||||
The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
|
The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
|
||||||
(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
|
(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
|
||||||
|
@ -512,27 +507,47 @@ than to be heisenbugged out of existence.
|
||||||
as follows:
|
as follows:
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
1 unsigned long gpnum;
|
1 unsigned long gp_seq;
|
||||||
2 unsigned long completed;
|
2 unsigned long gp_seq_needed;
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>These fields are the counterparts of the fields of the same name in
|
<p>The <tt>rcu_node</tt> structures' <tt>->gp_seq</tt> fields are
|
||||||
the <tt>rcu_state</tt> structure.
|
the counterparts of the field of the same name in the <tt>rcu_state</tt>
|
||||||
They each may lag up to one behind their <tt>rcu_state</tt>
|
structure.
|
||||||
counterparts.
|
They each may lag up to one step behind their <tt>rcu_state</tt>
|
||||||
If a given <tt>rcu_node</tt> structure's <tt>->gpnum</tt> and
|
counterpart.
|
||||||
<tt>->complete</tt> fields are equal, then this <tt>rcu_node</tt>
|
If the bottom two bits of a given <tt>rcu_node</tt> structure's
|
||||||
|
<tt>->gp_seq</tt> field is zero, then this <tt>rcu_node</tt>
|
||||||
structure believes that RCU is idle.
|
structure believes that RCU is idle.
|
||||||
Otherwise, as with the <tt>rcu_state</tt> structure,
|
</p><p>The <tt>>gp_seq</tt> field of each <tt>rcu_node</tt>
|
||||||
the <tt>->gpnum</tt> field will be one greater than the
|
structure is updated at the beginning and the end
|
||||||
<tt>->complete</tt> fields, with <tt>->gpnum</tt>
|
of each grace period.
|
||||||
indicating which grace period this <tt>rcu_node</tt> believes
|
|
||||||
is still being waited for.
|
|
||||||
|
|
||||||
</p><p>The <tt>>gpnum</tt> field of each <tt>rcu_node</tt>
|
<p>The <tt>->gp_seq_needed</tt> fields record the
|
||||||
structure is updated at the beginning
|
furthest-in-the-future grace period request seen by the corresponding
|
||||||
of each grace period, and the <tt>->completed</tt> fields are
|
<tt>rcu_node</tt> structure. The request is considered fulfilled when
|
||||||
updated at the end of each grace period.
|
the value of the <tt>->gp_seq</tt> field equals or exceeds that of
|
||||||
|
the <tt>->gp_seq_needed</tt> field.
|
||||||
|
|
||||||
|
<table>
|
||||||
|
<tr><th> </th></tr>
|
||||||
|
<tr><th align="left">Quick Quiz:</th></tr>
|
||||||
|
<tr><td>
|
||||||
|
Suppose that this <tt>rcu_node</tt> structure doesn't see
|
||||||
|
a request for a very long time.
|
||||||
|
Won't wrapping of the <tt>->gp_seq</tt> field cause
|
||||||
|
problems?
|
||||||
|
</td></tr>
|
||||||
|
<tr><th align="left">Answer:</th></tr>
|
||||||
|
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||||
|
No, because if the <tt>->gp_seq_needed</tt> field lags behind the
|
||||||
|
<tt>->gp_seq</tt> field, the <tt>->gp_seq_needed</tt> field
|
||||||
|
will be updated at the end of the grace period.
|
||||||
|
Modulo-arithmetic comparisons therefore will always get the
|
||||||
|
correct answer, even with wrapping.
|
||||||
|
</font></td></tr>
|
||||||
|
<tr><td> </td></tr>
|
||||||
|
</table>
|
||||||
|
|
||||||
<h5>Quiescent-State Tracking</h5>
|
<h5>Quiescent-State Tracking</h5>
|
||||||
|
|
||||||
|
@ -626,9 +641,8 @@ normal and expedited grace periods, respectively.
|
||||||
</ol>
|
</ol>
|
||||||
|
|
||||||
<p><font color="ffffff">So the locking is absolutely required in
|
<p><font color="ffffff">So the locking is absolutely required in
|
||||||
order to coordinate
|
order to coordinate clearing of the bits with updating of the
|
||||||
clearing of the bits with the grace-period numbers in
|
grace-period sequence number in <tt>->gp_seq</tt>.
|
||||||
<tt>->gpnum</tt> and <tt>->completed</tt>.
|
|
||||||
</font></td></tr>
|
</font></td></tr>
|
||||||
<tr><td> </td></tr>
|
<tr><td> </td></tr>
|
||||||
</table>
|
</table>
|
||||||
|
@ -1038,15 +1052,15 @@ out any <tt>rcu_data</tt> structure for which this flag is not set.
|
||||||
as follows:
|
as follows:
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
1 unsigned long completed;
|
1 unsigned long gp_seq;
|
||||||
2 unsigned long gpnum;
|
2 unsigned long gp_seq_needed;
|
||||||
3 bool cpu_no_qs;
|
3 bool cpu_no_qs;
|
||||||
4 bool core_needs_qs;
|
4 bool core_needs_qs;
|
||||||
5 bool gpwrap;
|
5 bool gpwrap;
|
||||||
6 unsigned long rcu_qs_ctr_snap;
|
6 unsigned long rcu_qs_ctr_snap;
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
<p>The <tt>completed</tt> and <tt>gpnum</tt>
|
<p>The <tt>->gp_seq</tt> and <tt>->gp_seq_needed</tt>
|
||||||
fields are the counterparts of the fields of the same name
|
fields are the counterparts of the fields of the same name
|
||||||
in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures.
|
in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures.
|
||||||
They may each lag up to one behind their <tt>rcu_node</tt>
|
They may each lag up to one behind their <tt>rcu_node</tt>
|
||||||
|
@ -1054,15 +1068,9 @@ counterparts, but in <tt>CONFIG_NO_HZ_IDLE</tt> and
|
||||||
<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
|
<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
|
||||||
arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
|
arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
|
||||||
will catch up upon exit from dyntick-idle mode).
|
will catch up upon exit from dyntick-idle mode).
|
||||||
If a given <tt>rcu_data</tt> structure's <tt>->gpnum</tt> and
|
If the lower two bits of a given <tt>rcu_data</tt> structure's
|
||||||
<tt>->complete</tt> fields are equal, then this <tt>rcu_data</tt>
|
<tt>->gp_seq</tt> are zero, then this <tt>rcu_data</tt>
|
||||||
structure believes that RCU is idle.
|
structure believes that RCU is idle.
|
||||||
Otherwise, as with the <tt>rcu_state</tt> and <tt>rcu_node</tt>
|
|
||||||
structure,
|
|
||||||
the <tt>->gpnum</tt> field will be one greater than the
|
|
||||||
<tt>->complete</tt> fields, with <tt>->gpnum</tt>
|
|
||||||
indicating which grace period this <tt>rcu_data</tt> believes
|
|
||||||
is still being waited for.
|
|
||||||
|
|
||||||
<table>
|
<table>
|
||||||
<tr><th> </th></tr>
|
<tr><th> </th></tr>
|
||||||
|
@ -1070,13 +1078,13 @@ is still being waited for.
|
||||||
<tr><td>
|
<tr><td>
|
||||||
All this replication of the grace period numbers can only cause
|
All this replication of the grace period numbers can only cause
|
||||||
massive confusion.
|
massive confusion.
|
||||||
Why not just keep a global pair of counters and be done with it???
|
Why not just keep a global sequence number and be done with it???
|
||||||
</td></tr>
|
</td></tr>
|
||||||
<tr><th align="left">Answer:</th></tr>
|
<tr><th align="left">Answer:</th></tr>
|
||||||
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||||
Because if there was only a single global pair of grace-period
|
Because if there was only a single global sequence
|
||||||
numbers, there would need to be a single global lock to allow
|
numbers, there would need to be a single global lock to allow
|
||||||
safely accessing and updating them.
|
safely accessing and updating it.
|
||||||
And if we are not going to have a single global lock, we need
|
And if we are not going to have a single global lock, we need
|
||||||
to carefully manage the numbers on a per-node basis.
|
to carefully manage the numbers on a per-node basis.
|
||||||
Recall from the answer to a previous Quick Quiz that the consequences
|
Recall from the answer to a previous Quick Quiz that the consequences
|
||||||
|
@ -1091,8 +1099,8 @@ CPU has not yet passed through a quiescent state,
|
||||||
while the <tt>->core_needs_qs</tt> flag indicates that the
|
while the <tt>->core_needs_qs</tt> flag indicates that the
|
||||||
RCU core needs a quiescent state from the corresponding CPU.
|
RCU core needs a quiescent state from the corresponding CPU.
|
||||||
The <tt>->gpwrap</tt> field indicates that the corresponding
|
The <tt>->gpwrap</tt> field indicates that the corresponding
|
||||||
CPU has remained idle for so long that the <tt>completed</tt>
|
CPU has remained idle for so long that the
|
||||||
and <tt>gpnum</tt> counters are in danger of overflow, which
|
<tt>gp_seq</tt> counter is in danger of overflow, which
|
||||||
will cause the CPU to disregard the values of its counters on
|
will cause the CPU to disregard the values of its counters on
|
||||||
its next exit from idle.
|
its next exit from idle.
|
||||||
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
|
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
|
||||||
|
@ -1130,10 +1138,10 @@ The CPU advances the callbacks in its <tt>rcu_data</tt> structure
|
||||||
whenever it notices that another RCU grace period has completed.
|
whenever it notices that another RCU grace period has completed.
|
||||||
The CPU detects the completion of an RCU grace period by noticing
|
The CPU detects the completion of an RCU grace period by noticing
|
||||||
that the value of its <tt>rcu_data</tt> structure's
|
that the value of its <tt>rcu_data</tt> structure's
|
||||||
<tt>->completed</tt> field differs from that of its leaf
|
<tt>->gp_seq</tt> field differs from that of its leaf
|
||||||
<tt>rcu_node</tt> structure.
|
<tt>rcu_node</tt> structure.
|
||||||
Recall that each <tt>rcu_node</tt> structure's
|
Recall that each <tt>rcu_node</tt> structure's
|
||||||
<tt>->completed</tt> field is updated at the end of each
|
<tt>->gp_seq</tt> field is updated at the beginnings and ends of each
|
||||||
grace period.
|
grace period.
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
|
@ -357,7 +357,7 @@ parts, starting in this section with the various phases of
|
||||||
grace-period initialization.
|
grace-period initialization.
|
||||||
|
|
||||||
<p>The first ordering-related grace-period initialization action is to
|
<p>The first ordering-related grace-period initialization action is to
|
||||||
increment the <tt>rcu_state</tt> structure's <tt>->gpnum</tt>
|
advance the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt>
|
||||||
grace-period-number counter, as shown below:
|
grace-period-number counter, as shown below:
|
||||||
|
|
||||||
</p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
</p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
||||||
|
@ -388,7 +388,7 @@ its last CPU and if the next <tt>rcu_node</tt> structure has no online CPUs).
|
||||||
|
|
||||||
<p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>
|
<p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>
|
||||||
tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
||||||
<tt>->gpnum</tt> field to the newly incremented value from the
|
<tt>->gp_seq</tt> field to the newly advanced value from the
|
||||||
<tt>rcu_state</tt> structure, as shown in the following diagram.
|
<tt>rcu_state</tt> structure, as shown in the following diagram.
|
||||||
|
|
||||||
</p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
</p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
||||||
|
@ -398,9 +398,9 @@ tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
||||||
to notice that a new grace period has started, as described in the next
|
to notice that a new grace period has started, as described in the next
|
||||||
section.
|
section.
|
||||||
But because the grace-period kthread started the grace period at the
|
But because the grace-period kthread started the grace period at the
|
||||||
root (with the increment of the <tt>rcu_state</tt> structure's
|
root (with the advancing of the <tt>rcu_state</tt> structure's
|
||||||
<tt>->gpnum</tt> field) before setting each leaf <tt>rcu_node</tt>
|
<tt>->gp_seq</tt> field) before setting each leaf <tt>rcu_node</tt>
|
||||||
structure's <tt>->gpnum</tt> field, each CPU's observation of
|
structure's <tt>->gp_seq</tt> field, each CPU's observation of
|
||||||
the start of the grace period will happen after the actual start
|
the start of the grace period will happen after the actual start
|
||||||
of the grace period.
|
of the grace period.
|
||||||
|
|
||||||
|
@ -466,7 +466,7 @@ section that the grace period must wait on.
|
||||||
<tr><td>
|
<tr><td>
|
||||||
But a RCU read-side critical section might have started
|
But a RCU read-side critical section might have started
|
||||||
after the beginning of the grace period
|
after the beginning of the grace period
|
||||||
(the <tt>->gpnum++</tt> from earlier), so why should
|
(the advancing of <tt>->gp_seq</tt> from earlier), so why should
|
||||||
the grace period wait on such a critical section?
|
the grace period wait on such a critical section?
|
||||||
</td></tr>
|
</td></tr>
|
||||||
<tr><th align="left">Answer:</th></tr>
|
<tr><th align="left">Answer:</th></tr>
|
||||||
|
@ -609,10 +609,8 @@ states outstanding from other CPUs.
|
||||||
<h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>
|
<h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>
|
||||||
|
|
||||||
<p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree
|
<p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree
|
||||||
breadth-first setting all the <tt>->completed</tt> fields equal
|
breadth-first advancing all the <tt>->gp_seq</tt> fields, then it
|
||||||
to the number of the newly completed grace period, then it sets
|
advances the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt> field.
|
||||||
the <tt>rcu_state</tt> structure's <tt>->completed</tt> field,
|
|
||||||
again to the number of the newly completed grace period.
|
|
||||||
The ordering effects are shown below:
|
The ordering effects are shown below:
|
||||||
|
|
||||||
</p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">
|
</p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">
|
||||||
|
@ -634,7 +632,7 @@ grace-period cleanup is complete, the next grace period can begin.
|
||||||
CPU has reported its quiescent state, but it may be some
|
CPU has reported its quiescent state, but it may be some
|
||||||
milliseconds before RCU becomes aware of this.
|
milliseconds before RCU becomes aware of this.
|
||||||
The latest reasonable candidate is once the <tt>rcu_state</tt>
|
The latest reasonable candidate is once the <tt>rcu_state</tt>
|
||||||
structure's <tt>->completed</tt> field has been updated,
|
structure's <tt>->gp_seq</tt> field has been updated,
|
||||||
but it is quite possible that some CPUs have already completed
|
but it is quite possible that some CPUs have already completed
|
||||||
phase two of their updates by that time.
|
phase two of their updates by that time.
|
||||||
In short, if you are going to work with RCU, you need to
|
In short, if you are going to work with RCU, you need to
|
||||||
|
@ -647,7 +645,7 @@ grace-period cleanup is complete, the next grace period can begin.
|
||||||
<h4><a name="Callback Invocation">Callback Invocation</a></h4>
|
<h4><a name="Callback Invocation">Callback Invocation</a></h4>
|
||||||
|
|
||||||
<p>Once a given CPU's leaf <tt>rcu_node</tt> structure's
|
<p>Once a given CPU's leaf <tt>rcu_node</tt> structure's
|
||||||
<tt>->completed</tt> field has been updated, that CPU can begin
|
<tt>->gp_seq</tt> field has been updated, that CPU can begin
|
||||||
invoking its RCU callbacks that were waiting for this grace period
|
invoking its RCU callbacks that were waiting for this grace period
|
||||||
to end.
|
to end.
|
||||||
These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
|
These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
|
||||||
|
|
|
@ -384,11 +384,11 @@
|
||||||
inkscape:window-height="1144"
|
inkscape:window-height="1144"
|
||||||
id="namedview208"
|
id="namedview208"
|
||||||
showgrid="true"
|
showgrid="true"
|
||||||
inkscape:zoom="0.70710678"
|
inkscape:zoom="0.78716603"
|
||||||
inkscape:cx="617.89017"
|
inkscape:cx="513.06403"
|
||||||
inkscape:cy="542.52419"
|
inkscape:cy="623.1214"
|
||||||
inkscape:window-x="86"
|
inkscape:window-x="102"
|
||||||
inkscape:window-y="28"
|
inkscape:window-y="38"
|
||||||
inkscape:window-maximized="0"
|
inkscape:window-maximized="0"
|
||||||
inkscape:current-layer="g3188-3"
|
inkscape:current-layer="g3188-3"
|
||||||
fit-margin-top="5"
|
fit-margin-top="5"
|
||||||
|
@ -417,13 +417,15 @@
|
||||||
id="g3188">
|
id="g3188">
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3199.1516"
|
x="3145.9592"
|
||||||
y="13255.592"
|
y="13255.592"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202"
|
id="text202"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3143">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
<g
|
<g
|
||||||
id="g3107"
|
id="g3107"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
@ -502,13 +504,15 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5324.5371"
|
x="5264.4731"
|
||||||
y="15414.598"
|
y="15428.84"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-753"
|
id="text202-36-7"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-5">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
|
@ -547,15 +551,6 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="7479.5796"
|
|
||||||
y="17699.943"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-9"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
|
||||||
<path
|
<path
|
||||||
sodipodi:nodetypes="cc"
|
sodipodi:nodetypes="cc"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
|
@ -566,15 +561,6 @@
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(-737.93887,7732.6672)"
|
transform="translate(-737.93887,7732.6672)"
|
||||||
id="g3188-3">
|
id="g3188-3">
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="3225.7478"
|
|
||||||
y="13175.802"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-60"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->completed =</text>
|
|
||||||
<g
|
<g
|
||||||
id="g3107-62"
|
id="g3107-62"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
@ -607,15 +593,6 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-7">Root</tspan></text>
|
id="tspan3104-6-5-7">Root</tspan></text>
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="3225.7478"
|
|
||||||
y="13390.038"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-60-3"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"> rnp->completed</text>
|
|
||||||
<flowRoot
|
<flowRoot
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
id="flowRoot3356"
|
id="flowRoot3356"
|
||||||
|
@ -627,7 +604,18 @@
|
||||||
height="63.63961"
|
height="63.63961"
|
||||||
x="332.34018"
|
x="332.34018"
|
||||||
y="681.87292" /></flowRegion><flowPara
|
y="681.87292" /></flowRegion><flowPara
|
||||||
id="flowPara3362" /></flowRoot> </g>
|
id="flowPara3362" /></flowRoot> <text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="3156.6121"
|
||||||
|
y="13317.754"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-6"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-0">rcu_seq_end(&rsp->gp_seq)</tspan></text>
|
||||||
|
</g>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(-858.40227,7769.0342)"
|
transform="translate(-858.40227,7769.0342)"
|
||||||
|
@ -859,6 +847,17 @@
|
||||||
id="path3414-8-3-6-6"
|
id="path3414-8-3-6-6"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
sodipodi:nodetypes="cc" />
|
sodipodi:nodetypes="cc" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="7418.769"
|
||||||
|
y="17646.104"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-70"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-93">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-1642.5377,-11611.245)"
|
transform="translate(-1642.5377,-11611.245)"
|
||||||
|
@ -887,13 +886,15 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5327.3057"
|
x="5274.1133"
|
||||||
y="15428.84"
|
y="15428.84"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-36"
|
id="text202-36"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-151.71746,-11647.612)"
|
transform="translate(-151.71746,-11647.612)"
|
||||||
|
@ -972,13 +973,15 @@
|
||||||
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7486.4907"
|
x="7408.5918"
|
||||||
y="17670.119"
|
y="17619.504"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-6"
|
id="text202-36-2"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-9">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-6817.1997,-11647.612)"
|
transform="translate(-6817.1997,-11647.612)"
|
||||||
|
@ -1019,13 +1022,15 @@
|
||||||
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7474.1382"
|
x="7416.8003"
|
||||||
y="17688.926"
|
y="17619.504"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-5"
|
id="text202-36-3"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-56">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<path
|
<path
|
||||||
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||||
|
@ -1059,15 +1064,6 @@
|
||||||
id="path3414-8-3-6"
|
id="path3414-8-3-6"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
sodipodi:nodetypes="cc" />
|
sodipodi:nodetypes="cc" />
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="7318.9653"
|
|
||||||
y="6031.6353"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-2"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
id="g4504-3-9"
|
id="g4504-3-9"
|
||||||
|
@ -1123,4 +1119,15 @@
|
||||||
id="path3134-9-0-3-5"
|
id="path3134-9-0-3-5"
|
||||||
d="m 6875.6003,15833.906 1595.7755,0"
|
d="m 6875.6003,15833.906 1595.7755,0"
|
||||||
style="fill:none;stroke:#969696;stroke-width:53.19251633;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send-36)" />
|
style="fill:none;stroke:#969696;stroke-width:53.19251633;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send-36)" />
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="7275.2612"
|
||||||
|
y="5971.8916"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-1"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-2">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</svg>
|
</svg>
|
||||||
|
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
@ -272,13 +272,13 @@
|
||||||
inkscape:window-height="1144"
|
inkscape:window-height="1144"
|
||||||
id="namedview208"
|
id="namedview208"
|
||||||
showgrid="true"
|
showgrid="true"
|
||||||
inkscape:zoom="0.70710678"
|
inkscape:zoom="2.6330492"
|
||||||
inkscape:cx="617.89019"
|
inkscape:cx="524.82797"
|
||||||
inkscape:cy="636.57143"
|
inkscape:cy="519.31194"
|
||||||
inkscape:window-x="697"
|
inkscape:window-x="79"
|
||||||
inkscape:window-y="28"
|
inkscape:window-y="28"
|
||||||
inkscape:window-maximized="0"
|
inkscape:window-maximized="0"
|
||||||
inkscape:current-layer="svg2"
|
inkscape:current-layer="g3188"
|
||||||
fit-margin-top="5"
|
fit-margin-top="5"
|
||||||
fit-margin-right="5"
|
fit-margin-right="5"
|
||||||
fit-margin-left="5"
|
fit-margin-left="5"
|
||||||
|
@ -305,13 +305,15 @@
|
||||||
id="g3188">
|
id="g3188">
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3305.5364"
|
x="3119.363"
|
||||||
y="13255.592"
|
y="13255.592"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202"
|
id="text202"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->gpnum++</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3071">rcu_seq_start(rsp->gp_seq)</tspan></text>
|
||||||
<g
|
<g
|
||||||
id="g3107"
|
id="g3107"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 24 KiB |
|
@ -19,7 +19,7 @@
|
||||||
id="svg2"
|
id="svg2"
|
||||||
version="1.1"
|
version="1.1"
|
||||||
inkscape:version="0.48.4 r9939"
|
inkscape:version="0.48.4 r9939"
|
||||||
sodipodi:docname="TreeRCU-gp-init-2.svg">
|
sodipodi:docname="TreeRCU-gp-init-3.svg">
|
||||||
<metadata
|
<metadata
|
||||||
id="metadata212">
|
id="metadata212">
|
||||||
<rdf:RDF>
|
<rdf:RDF>
|
||||||
|
@ -257,18 +257,22 @@
|
||||||
inkscape:window-width="1087"
|
inkscape:window-width="1087"
|
||||||
inkscape:window-height="1144"
|
inkscape:window-height="1144"
|
||||||
id="namedview208"
|
id="namedview208"
|
||||||
showgrid="false"
|
showgrid="true"
|
||||||
inkscape:zoom="0.70710678"
|
inkscape:zoom="0.68224756"
|
||||||
inkscape:cx="617.89019"
|
inkscape:cx="617.89019"
|
||||||
inkscape:cy="625.84293"
|
inkscape:cy="625.84293"
|
||||||
inkscape:window-x="697"
|
inkscape:window-x="54"
|
||||||
inkscape:window-y="28"
|
inkscape:window-y="28"
|
||||||
inkscape:window-maximized="0"
|
inkscape:window-maximized="0"
|
||||||
inkscape:current-layer="svg2"
|
inkscape:current-layer="g3153"
|
||||||
fit-margin-top="5"
|
fit-margin-top="5"
|
||||||
fit-margin-right="5"
|
fit-margin-right="5"
|
||||||
fit-margin-left="5"
|
fit-margin-left="5"
|
||||||
fit-margin-bottom="5" />
|
fit-margin-bottom="5">
|
||||||
|
<inkscape:grid
|
||||||
|
type="xygrid"
|
||||||
|
id="grid3090" />
|
||||||
|
</sodipodi:namedview>
|
||||||
<path
|
<path
|
||||||
sodipodi:nodetypes="cccccccccccccccccccccccc"
|
sodipodi:nodetypes="cccccccccccccccccccccccc"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
|
@ -281,13 +285,13 @@
|
||||||
id="g3188">
|
id="g3188">
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3305.5364"
|
x="3145.9592"
|
||||||
y="13255.592"
|
y="13255.592"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202"
|
id="text202"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
<g
|
<g
|
||||||
id="g3107"
|
id="g3107"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
@ -366,13 +370,13 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5392.3345"
|
x="5253.6904"
|
||||||
y="15407.104"
|
y="15407.032"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-6"
|
id="text202-6"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
|
@ -413,13 +417,13 @@
|
||||||
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7536.4883"
|
x="7415.4365"
|
||||||
y="17640.934"
|
y="17670.572"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-9"
|
id="text202-9"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-1642.5375,-11610.962)"
|
transform="translate(-1642.5375,-11610.962)"
|
||||||
|
@ -448,13 +452,13 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5378.4146"
|
x="5258.0688"
|
||||||
y="15436.927"
|
y="15412.313"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-3"
|
id="text202-3"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-151.71726,-11647.329)"
|
transform="translate(-151.71726,-11647.329)"
|
||||||
|
@ -533,13 +537,13 @@
|
||||||
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7520.1294"
|
x="7405.2607"
|
||||||
y="17673.639"
|
y="17670.572"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-35"
|
id="text202-35"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-6817.1998,-11647.329)"
|
transform="translate(-6817.1998,-11647.329)"
|
||||||
|
@ -580,13 +584,13 @@
|
||||||
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7521.4663"
|
x="7413.4688"
|
||||||
y="17666.062"
|
y="17670.566"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-75"
|
id="text202-75"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<path
|
<path
|
||||||
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||||
|
@ -622,11 +626,11 @@
|
||||||
sodipodi:nodetypes="cc" />
|
sodipodi:nodetypes="cc" />
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7370.856"
|
x="7271.9297"
|
||||||
y="5997.5972"
|
y="6023.2412"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-62"
|
id="text202-62"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</svg>
|
</svg>
|
||||||
|
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 23 KiB |
|
@ -1070,13 +1070,13 @@
|
||||||
inkscape:window-height="1144"
|
inkscape:window-height="1144"
|
||||||
id="namedview208"
|
id="namedview208"
|
||||||
showgrid="true"
|
showgrid="true"
|
||||||
inkscape:zoom="0.6004608"
|
inkscape:zoom="0.81932583"
|
||||||
inkscape:cx="826.65969"
|
inkscape:cx="840.45848"
|
||||||
inkscape:cy="483.3047"
|
inkscape:cy="5052.4242"
|
||||||
inkscape:window-x="66"
|
inkscape:window-x="787"
|
||||||
inkscape:window-y="28"
|
inkscape:window-y="24"
|
||||||
inkscape:window-maximized="0"
|
inkscape:window-maximized="0"
|
||||||
inkscape:current-layer="svg2"
|
inkscape:current-layer="g4"
|
||||||
fit-margin-top="5"
|
fit-margin-top="5"
|
||||||
fit-margin-right="5"
|
fit-margin-right="5"
|
||||||
fit-margin-left="5"
|
fit-margin-left="5"
|
||||||
|
@ -1543,15 +1543,6 @@
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(1749.0282,658.72243)"
|
transform="translate(1749.0282,658.72243)"
|
||||||
id="g3188">
|
id="g3188">
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="3305.5364"
|
|
||||||
y="13255.592"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-5"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->gpnum++</text>
|
|
||||||
<g
|
<g
|
||||||
id="g3107-62"
|
id="g3107-62"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
@ -1584,6 +1575,17 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-7">Root</tspan></text>
|
id="tspan3104-6-5-7">Root</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="3137.9988"
|
||||||
|
y="13271.316"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-626"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3071">rcu_seq_start(rsp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<rect
|
<rect
|
||||||
ry="0"
|
ry="0"
|
||||||
|
@ -2318,15 +2320,6 @@
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(1739.0986,17188.625)"
|
transform="translate(1739.0986,17188.625)"
|
||||||
id="g3188-6">
|
id="g3188-6">
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="3305.5364"
|
|
||||||
y="13255.592"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-1"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gpnum = rsp->gpnum</text>
|
|
||||||
<g
|
<g
|
||||||
id="g3107-5"
|
id="g3107-5"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
@ -2359,6 +2352,15 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-1">Root</tspan></text>
|
id="tspan3104-6-5-1">Root</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="3147.9268"
|
||||||
|
y="13240.524"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-1"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
|
@ -2387,13 +2389,13 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5392.3345"
|
x="5263.1094"
|
||||||
y="15407.104"
|
y="15411.646"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-6-7"
|
id="text202-92"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
|
@ -2434,13 +2436,13 @@
|
||||||
id="tspan3104-6-5-6-0-94">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-94">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7536.4883"
|
x="7417.4053"
|
||||||
y="17640.934"
|
y="17655.502"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-9"
|
id="text202-759"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-2353.8462,17224.992)"
|
transform="translate(-2353.8462,17224.992)"
|
||||||
|
@ -2469,13 +2471,13 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5378.4146"
|
x="5246.1548"
|
||||||
y="15436.927"
|
y="15411.648"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-3"
|
id="text202-87"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-863.02613,17188.625)"
|
transform="translate(-863.02613,17188.625)"
|
||||||
|
@ -2554,13 +2556,13 @@
|
||||||
id="tspan3104-6-5-6-0-92-6">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-92-6">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7520.1294"
|
x="7433.8257"
|
||||||
y="17673.639"
|
y="17682.098"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-35"
|
id="text202-2"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-7528.5085,17188.625)"
|
transform="translate(-7528.5085,17188.625)"
|
||||||
|
@ -2601,13 +2603,13 @@
|
||||||
id="tspan3104-6-5-6-0-1-8">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-1-8">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7521.4663"
|
x="7415.4404"
|
||||||
y="17666.062"
|
y="17682.098"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-75-1"
|
id="text202-0"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
<path
|
<path
|
||||||
style="fill:none;stroke:#000000;stroke-width:13.29812813px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
style="fill:none;stroke:#000000;stroke-width:13.29812813px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||||
|
@ -2641,15 +2643,6 @@
|
||||||
id="path3414-8-3-6-4"
|
id="path3414-8-3-6-4"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
sodipodi:nodetypes="cc" />
|
sodipodi:nodetypes="cc" />
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="6659.5469"
|
|
||||||
y="34833.551"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-62"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
|
||||||
<path
|
<path
|
||||||
sodipodi:nodetypes="ccc"
|
sodipodi:nodetypes="ccc"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
|
@ -3844,7 +3837,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-6-6-5"
|
id="text202-6-6-5"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gp_seq</text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5035.4155"
|
x="5035.4155"
|
||||||
|
@ -4284,15 +4277,6 @@
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(1874.038,53203.538)"
|
transform="translate(1874.038,53203.538)"
|
||||||
id="g3188-7">
|
id="g3188-7">
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="3199.1516"
|
|
||||||
y="13255.592"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-82"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->completed = ->gpnum</text>
|
|
||||||
<g
|
<g
|
||||||
id="g3107-53"
|
id="g3107-53"
|
||||||
transform="translate(947.90548,11584.029)">
|
transform="translate(947.90548,11584.029)">
|
||||||
|
@ -4325,6 +4309,17 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-19">Root</tspan></text>
|
id="tspan3104-6-5-19">Root</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="3175.896"
|
||||||
|
y="13240.11"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-3"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<rect
|
<rect
|
||||||
ry="0"
|
ry="0"
|
||||||
|
@ -4371,13 +4366,15 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5324.5371"
|
x="5264.4829"
|
||||||
y="15414.598"
|
y="15411.231"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-753"
|
id="text202-36-7"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-5">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
|
@ -4412,30 +4409,12 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-6-0-4">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-4">Leaf</tspan></text>
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="10084.225"
|
|
||||||
y="70903.312"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-9-0"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
|
||||||
<path
|
<path
|
||||||
sodipodi:nodetypes="ccc"
|
sodipodi:nodetypes="ccc"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
id="path3134-9-0-3-9"
|
id="path3134-9-0-3-9"
|
||||||
d="m 6315.6122,72629.054 -20.9533,8108.684 1648.968,0"
|
d="m 6315.6122,72629.054 -20.9533,8108.684 1648.968,0"
|
||||||
style="fill:none;stroke:#969696;stroke-width:53.19251251;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send)" />
|
style="fill:none;stroke:#969696;stroke-width:53.19251251;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send)" />
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="5092.4683"
|
|
||||||
y="74111.672"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-60"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rsp->completed =</text>
|
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
id="g3107-62-6"
|
id="g3107-62-6"
|
||||||
|
@ -4469,15 +4448,6 @@
|
||||||
sodipodi:linespacing="125%"><tspan
|
sodipodi:linespacing="125%"><tspan
|
||||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||||
id="tspan3104-6-5-7-7">Root</tspan></text>
|
id="tspan3104-6-5-7-7">Root</tspan></text>
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="5092.4683"
|
|
||||||
y="74325.906"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-60-3"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"> rnp->completed</text>
|
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(1746.2528,60972.572)"
|
transform="translate(1746.2528,60972.572)"
|
||||||
|
@ -4736,13 +4706,15 @@
|
||||||
</g>
|
</g>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5327.3057"
|
x="5274.1216"
|
||||||
y="15428.84"
|
y="15411.231"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-36"
|
id="text202-36"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-6">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-728.08545,53203.538)"
|
transform="translate(-728.08545,53203.538)"
|
||||||
|
@ -4821,13 +4793,15 @@
|
||||||
id="tspan3104-6-5-6-0-92-5">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-92-5">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7486.4907"
|
x="7435.1987"
|
||||||
y="17670.119"
|
y="17708.281"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-6-2"
|
id="text202-36-9"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-1">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
transform="translate(-7393.5687,53203.538)"
|
transform="translate(-7393.5687,53203.538)"
|
||||||
|
@ -4868,13 +4842,15 @@
|
||||||
id="tspan3104-6-5-6-0-1-5">Leaf</tspan></text>
|
id="tspan3104-6-5-6-0-1-5">Leaf</tspan></text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="7474.1382"
|
x="7416.8125"
|
||||||
y="17688.926"
|
y="17708.281"
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-5-1"
|
id="text202-36-35"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-62">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
</g>
|
</g>
|
||||||
<path
|
<path
|
||||||
style="fill:none;stroke:#000000;stroke-width:13.29812813px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
style="fill:none;stroke:#000000;stroke-width:13.29812813px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||||
|
@ -4908,15 +4884,6 @@
|
||||||
id="path3414-8-3-6-67"
|
id="path3414-8-3-6-67"
|
||||||
inkscape:connector-curvature="0"
|
inkscape:connector-curvature="0"
|
||||||
sodipodi:nodetypes="cc" />
|
sodipodi:nodetypes="cc" />
|
||||||
<text
|
|
||||||
xml:space="preserve"
|
|
||||||
x="6742.6001"
|
|
||||||
y="70882.617"
|
|
||||||
font-style="normal"
|
|
||||||
font-weight="bold"
|
|
||||||
font-size="192"
|
|
||||||
id="text202-2"
|
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
id="g4504-3-9-6"
|
id="g4504-3-9-6"
|
||||||
|
@ -5131,5 +5098,47 @@
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-9-6-6-7"
|
id="text202-7-9-6-6-7"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_do_batch()</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_do_batch()</text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="6698.9019"
|
||||||
|
y="70885.211"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-2"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-7">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="10023.457"
|
||||||
|
y="70885.234"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-0"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-9">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="5023.3389"
|
||||||
|
y="74209.773"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-36-36"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||||
|
style="font-size:172.87567139px"
|
||||||
|
id="tspan3166-0">rcu_seq_end(&rsp->gp_seq)</tspan></text>
|
||||||
|
<text
|
||||||
|
xml:space="preserve"
|
||||||
|
x="6562.5884"
|
||||||
|
y="34870.727"
|
||||||
|
font-style="normal"
|
||||||
|
font-weight="bold"
|
||||||
|
font-size="192"
|
||||||
|
id="text202-3"
|
||||||
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||||
</g>
|
</g>
|
||||||
</svg>
|
</svg>
|
||||||
|
|
Before Width: | Height: | Size: 208 KiB After Width: | Height: | Size: 209 KiB |
|
@ -300,13 +300,13 @@
|
||||||
inkscape:window-height="1144"
|
inkscape:window-height="1144"
|
||||||
id="namedview208"
|
id="namedview208"
|
||||||
showgrid="true"
|
showgrid="true"
|
||||||
inkscape:zoom="0.70710678"
|
inkscape:zoom="0.96484375"
|
||||||
inkscape:cx="616.47598"
|
inkscape:cx="507.0191"
|
||||||
inkscape:cy="595.41964"
|
inkscape:cy="885.62207"
|
||||||
inkscape:window-x="813"
|
inkscape:window-x="47"
|
||||||
inkscape:window-y="28"
|
inkscape:window-y="28"
|
||||||
inkscape:window-maximized="0"
|
inkscape:window-maximized="0"
|
||||||
inkscape:current-layer="g4405"
|
inkscape:current-layer="g3115"
|
||||||
fit-margin-top="5"
|
fit-margin-top="5"
|
||||||
fit-margin-right="5"
|
fit-margin-right="5"
|
||||||
fit-margin-left="5"
|
fit-margin-left="5"
|
||||||
|
@ -710,7 +710,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-6-6"
|
id="text202-6-6"
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gpnum</text>
|
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gp_seq</text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="5035.4155"
|
x="5035.4155"
|
||||||
|
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
|
@ -172,7 +172,7 @@ it will print a message similar to the following:
|
||||||
INFO: rcu_sched detected stalls on CPUs/tasks:
|
INFO: rcu_sched detected stalls on CPUs/tasks:
|
||||||
2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0
|
2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0
|
||||||
16-...: (0 ticks this GP) idle=81c/0/0 softirq=764/764 fqs=0
|
16-...: (0 ticks this GP) idle=81c/0/0 softirq=764/764 fqs=0
|
||||||
(detected by 32, t=2603 jiffies, g=7073, c=7072, q=625)
|
(detected by 32, t=2603 jiffies, g=7075, q=625)
|
||||||
|
|
||||||
This message indicates that CPU 32 detected that CPUs 2 and 16 were both
|
This message indicates that CPU 32 detected that CPUs 2 and 16 were both
|
||||||
causing stalls, and that the stall was affecting RCU-sched. This message
|
causing stalls, and that the stall was affecting RCU-sched. This message
|
||||||
|
@ -215,11 +215,10 @@ CPU since the last time that this CPU noted the beginning of a grace
|
||||||
period.
|
period.
|
||||||
|
|
||||||
The "detected by" line indicates which CPU detected the stall (in this
|
The "detected by" line indicates which CPU detected the stall (in this
|
||||||
case, CPU 32), how many jiffies have elapsed since the start of the
|
case, CPU 32), how many jiffies have elapsed since the start of the grace
|
||||||
grace period (in this case 2603), the number of the last grace period
|
period (in this case 2603), the grace-period sequence number (7075), and
|
||||||
to start and to complete (7073 and 7072, respectively), and an estimate
|
an estimate of the total number of RCU callbacks queued across all CPUs
|
||||||
of the total number of RCU callbacks queued across all CPUs (625 in
|
(625 in this case).
|
||||||
this case).
|
|
||||||
|
|
||||||
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed
|
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed
|
||||||
for each CPU:
|
for each CPU:
|
||||||
|
@ -266,15 +265,16 @@ If the relevant grace-period kthread has been unable to run prior to
|
||||||
the stall warning, as was the case in the "All QSes seen" line above,
|
the stall warning, as was the case in the "All QSes seen" line above,
|
||||||
the following additional line is printed:
|
the following additional line is printed:
|
||||||
|
|
||||||
kthread starved for 23807 jiffies! g7073 c7072 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
|
kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5
|
||||||
|
|
||||||
Starving the grace-period kthreads of CPU time can of course result
|
Starving the grace-period kthreads of CPU time can of course result
|
||||||
in RCU CPU stall warnings even when all CPUs and tasks have passed
|
in RCU CPU stall warnings even when all CPUs and tasks have passed
|
||||||
through the required quiescent states. The "g" and "c" numbers flag the
|
through the required quiescent states. The "g" number shows the current
|
||||||
number of the last grace period started and completed, respectively,
|
grace-period sequence number, the "f" precedes the ->gp_flags command
|
||||||
the "f" precedes the ->gp_flags command to the grace-period kthread,
|
to the grace-period kthread, the "RCU_GP_WAIT_FQS" indicates that the
|
||||||
the "RCU_GP_WAIT_FQS" indicates that the kthread is waiting for a short
|
kthread is waiting for a short timeout, the "state" precedes value of the
|
||||||
timeout, and the "state" precedes value of the task_struct ->state field.
|
task_struct ->state field, and the "cpu" indicates that the grace-period
|
||||||
|
kthread last ran on CPU 5.
|
||||||
|
|
||||||
|
|
||||||
Multiple Warnings From One Stall
|
Multiple Warnings From One Stall
|
||||||
|
|
|
@ -588,6 +588,7 @@ It is extremely simple:
|
||||||
void synchronize_rcu(void)
|
void synchronize_rcu(void)
|
||||||
{
|
{
|
||||||
write_lock(&rcu_gp_mutex);
|
write_lock(&rcu_gp_mutex);
|
||||||
|
smp_mb__after_spinlock();
|
||||||
write_unlock(&rcu_gp_mutex);
|
write_unlock(&rcu_gp_mutex);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -609,12 +610,15 @@ don't forget about them when submitting patches making use of RCU!]
|
||||||
|
|
||||||
The rcu_read_lock() and rcu_read_unlock() primitive read-acquire
|
The rcu_read_lock() and rcu_read_unlock() primitive read-acquire
|
||||||
and release a global reader-writer lock. The synchronize_rcu()
|
and release a global reader-writer lock. The synchronize_rcu()
|
||||||
primitive write-acquires this same lock, then immediately releases
|
primitive write-acquires this same lock, then releases it. This means
|
||||||
it. This means that once synchronize_rcu() exits, all RCU read-side
|
that once synchronize_rcu() exits, all RCU read-side critical sections
|
||||||
critical sections that were in progress before synchronize_rcu() was
|
that were in progress before synchronize_rcu() was called are guaranteed
|
||||||
called are guaranteed to have completed -- there is no way that
|
to have completed -- there is no way that synchronize_rcu() would have
|
||||||
synchronize_rcu() would have been able to write-acquire the lock
|
been able to write-acquire the lock otherwise. The smp_mb__after_spinlock()
|
||||||
otherwise.
|
promotes synchronize_rcu() to a full memory barrier in compliance with
|
||||||
|
the "Memory-Barrier Guarantees" listed in:
|
||||||
|
|
||||||
|
Documentation/RCU/Design/Requirements/Requirements.html.
|
||||||
|
|
||||||
It is possible to nest rcu_read_lock(), since reader-writer locks may
|
It is possible to nest rcu_read_lock(), since reader-writer locks may
|
||||||
be recursively acquired. Note also that rcu_read_lock() is immune
|
be recursively acquired. Note also that rcu_read_lock() is immune
|
||||||
|
@ -816,11 +820,13 @@ RCU list traversal:
|
||||||
list_next_rcu
|
list_next_rcu
|
||||||
list_for_each_entry_rcu
|
list_for_each_entry_rcu
|
||||||
list_for_each_entry_continue_rcu
|
list_for_each_entry_continue_rcu
|
||||||
|
list_for_each_entry_from_rcu
|
||||||
hlist_first_rcu
|
hlist_first_rcu
|
||||||
hlist_next_rcu
|
hlist_next_rcu
|
||||||
hlist_pprev_rcu
|
hlist_pprev_rcu
|
||||||
hlist_for_each_entry_rcu
|
hlist_for_each_entry_rcu
|
||||||
hlist_for_each_entry_rcu_bh
|
hlist_for_each_entry_rcu_bh
|
||||||
|
hlist_for_each_entry_from_rcu
|
||||||
hlist_for_each_entry_continue_rcu
|
hlist_for_each_entry_continue_rcu
|
||||||
hlist_for_each_entry_continue_rcu_bh
|
hlist_for_each_entry_continue_rcu_bh
|
||||||
hlist_nulls_first_rcu
|
hlist_nulls_first_rcu
|
||||||
|
|
89
Documentation/acpi/dsd/data-node-references.txt
Normal file
|
@ -0,0 +1,89 @@
|
||||||
|
Copyright (C) 2018 Intel Corporation
|
||||||
|
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
|
||||||
|
|
||||||
|
|
||||||
|
Referencing hierarchical data nodes
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
ACPI in general allows referring to device objects in the tree only.
|
||||||
|
Hierarchical data extension nodes may not be referred to directly, hence this
|
||||||
|
document defines a scheme to implement such references.
|
||||||
|
|
||||||
|
A reference consist of the device object name followed by one or more
|
||||||
|
hierarchical data extension [1] keys. Specifically, the hierarchical data
|
||||||
|
extension node which is referred to by the key shall lie directly under the
|
||||||
|
parent object i.e. either the device object or another hierarchical data
|
||||||
|
extension node.
|
||||||
|
|
||||||
|
The keys in the hierarchical data nodes shall consist of the name of the node,
|
||||||
|
"@" character and the number of the node in hexadecimal notation (without pre-
|
||||||
|
or postfixes). The same ACPI object shall include the _DSD property extension
|
||||||
|
with a property "reg" that shall have the same numerical value as the number of
|
||||||
|
the node.
|
||||||
|
|
||||||
|
In case a hierarchical data extensions node has no numerical value, then the
|
||||||
|
"reg" property shall be omitted from the ACPI object's _DSD properties and the
|
||||||
|
"@" character and the number shall be omitted from the hierarchical data
|
||||||
|
extension key.
|
||||||
|
|
||||||
|
|
||||||
|
Example
|
||||||
|
-------
|
||||||
|
|
||||||
|
In the ASL snippet below, the "reference" _DSD property [2] contains a
|
||||||
|
device object reference to DEV0 and under that device object, a
|
||||||
|
hierarchical data extension key "node@1" referring to the NOD1 object
|
||||||
|
and lastly, a hierarchical data extension key "anothernode" referring to
|
||||||
|
the ANOD object which is also the final target node of the reference.
|
||||||
|
|
||||||
|
Device (DEV0)
|
||||||
|
{
|
||||||
|
Name (_DSD, Package () {
|
||||||
|
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||||
|
Package () {
|
||||||
|
Package () { "node@0", NOD0 },
|
||||||
|
Package () { "node@1", NOD1 },
|
||||||
|
}
|
||||||
|
})
|
||||||
|
Name (NOD0, Package() {
|
||||||
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
|
Package () {
|
||||||
|
Package () { "random-property", 3 },
|
||||||
|
}
|
||||||
|
})
|
||||||
|
Name (NOD1, Package() {
|
||||||
|
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||||
|
Package () {
|
||||||
|
Package () { "anothernode", ANOD },
|
||||||
|
}
|
||||||
|
})
|
||||||
|
Name (ANOD, Package() {
|
||||||
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
|
Package () {
|
||||||
|
Package () { "random-property", 0 },
|
||||||
|
}
|
||||||
|
})
|
||||||
|
}
|
||||||
|
|
||||||
|
Device (DEV1)
|
||||||
|
{
|
||||||
|
Name (_DSD, Package () {
|
||||||
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
|
Package () {
|
||||||
|
Package () { "reference", ^DEV0, "node@1", "anothernode" },
|
||||||
|
}
|
||||||
|
})
|
||||||
|
}
|
||||||
|
|
||||||
|
Please also see a graph example in graph.txt .
|
||||||
|
|
||||||
|
References
|
||||||
|
----------
|
||||||
|
|
||||||
|
[1] Hierarchical Data Extension UUID For _DSD.
|
||||||
|
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
|
||||||
|
referenced 2018-07-17.
|
||||||
|
|
||||||
|
[2] Device Properties UUID For _DSD.
|
||||||
|
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
|
||||||
|
referenced 2016-10-04.
|
|
@ -36,29 +36,41 @@ The port and endpoint concepts are very similar to those in Devicetree
|
||||||
[3]. A port represents an interface in a device, and an endpoint
|
[3]. A port represents an interface in a device, and an endpoint
|
||||||
represents a connection to that interface.
|
represents a connection to that interface.
|
||||||
|
|
||||||
All port nodes are located under the device's "_DSD" node in the
|
All port nodes are located under the device's "_DSD" node in the hierarchical
|
||||||
hierarchical data extension tree. The property extension related to
|
data extension tree. The data extension related to each port node must begin
|
||||||
each port node must contain the key "port" and an integer value which
|
with "port" and must be followed by the "@" character and the number of the port
|
||||||
is the number of the port. The object it refers to should be called "PRTX",
|
as its key. The target object it refers to should be called "PRTX", where "X" is
|
||||||
where "X" is the number of the port.
|
the number of the port. An example of such a package would be:
|
||||||
|
|
||||||
Further on, endpoints are located under the individual port nodes. The
|
Package() { "port@4", PRT4 }
|
||||||
first hierarchical data extension package list entry of the endpoint
|
|
||||||
nodes must begin with "endpoint" and must be followed by the number
|
|
||||||
of the endpoint. The object it refers to should be called "EPXY", where
|
|
||||||
"X" is the number of the port and "Y" is the number of the endpoint.
|
|
||||||
|
|
||||||
Each port node contains a property extension key "port", the value of
|
Further on, endpoints are located under the port nodes. The hierarchical
|
||||||
which is the number of the port node. The each endpoint is similarly numbered
|
data extension key of the endpoint nodes must begin with
|
||||||
with a property extension key "endpoint". Port numbers must be unique within a
|
"endpoint" and must be followed by the "@" character and the number of the
|
||||||
device and endpoint numbers must be unique within a port.
|
endpoint. The object it refers to should be called "EPXY", where "X" is the
|
||||||
|
number of the port and "Y" is the number of the endpoint. An example of such a
|
||||||
|
package would be:
|
||||||
|
|
||||||
|
Package() { "endpoint@0", EP40 }
|
||||||
|
|
||||||
|
Each port node contains a property extension key "port", the value of which is
|
||||||
|
the number of the port. Each endpoint is similarly numbered with a property
|
||||||
|
extension key "reg", the value of which is the number of the endpoint. Port
|
||||||
|
numbers must be unique within a device and endpoint numbers must be unique
|
||||||
|
within a port. If a device object may only has a single port, then the number
|
||||||
|
of that port shall be zero. Similarly, if a port may only have a single
|
||||||
|
endpoint, the number of that endpoint shall be zero.
|
||||||
|
|
||||||
The endpoint reference uses property extension with "remote-endpoint" property
|
The endpoint reference uses property extension with "remote-endpoint" property
|
||||||
name followed by a reference in the same package. Such references consist of the
|
name followed by a reference in the same package. Such references consist of the
|
||||||
the remote device reference, number of the port in the device and finally the
|
the remote device reference, the first package entry of the port data extension
|
||||||
number of the endpoint in that port. Individual references thus appear as:
|
reference under the device and finally the first package entry of the endpoint
|
||||||
|
data extension reference under the port. Individual references thus appear as:
|
||||||
|
|
||||||
Package() { device, port_number, endpoint_number }
|
Package() { device, "port@X", "endpoint@Y" }
|
||||||
|
|
||||||
|
In the above example, "X" is the number of the port and "Y" is the number of the
|
||||||
|
endpoint.
|
||||||
|
|
||||||
The references to endpoints must be always done both ways, to the
|
The references to endpoints must be always done both ways, to the
|
||||||
remote endpoint and back from the referred remote endpoint node.
|
remote endpoint and back from the referred remote endpoint node.
|
||||||
|
@ -76,24 +88,24 @@ A simple example of this is show below:
|
||||||
},
|
},
|
||||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "port0", "PRT0" },
|
Package () { "port@0", PRT0 },
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
Name (PRT0, Package() {
|
Name (PRT0, Package() {
|
||||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "port", 0 },
|
Package () { "reg", 0 },
|
||||||
},
|
},
|
||||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "endpoint0", "EP00" },
|
Package () { "endpoint@0", EP00 },
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
Name (EP00, Package() {
|
Name (EP00, Package() {
|
||||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "endpoint", 0 },
|
Package () { "reg", 0 },
|
||||||
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, 4, 0 } },
|
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } },
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
}
|
}
|
||||||
|
@ -106,26 +118,26 @@ A simple example of this is show below:
|
||||||
Name (_DSD, Package () {
|
Name (_DSD, Package () {
|
||||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "port4", "PRT4" },
|
Package () { "port@4", PRT4 },
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
|
|
||||||
Name (PRT4, Package() {
|
Name (PRT4, Package() {
|
||||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "port", 4 }, /* CSI-2 port number */
|
Package () { "reg", 4 }, /* CSI-2 port number */
|
||||||
},
|
},
|
||||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "endpoint0", "EP40" },
|
Package () { "endpoint@0", EP40 },
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
|
|
||||||
Name (EP40, Package() {
|
Name (EP40, Package() {
|
||||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||||
Package () {
|
Package () {
|
||||||
Package () { "endpoint", 0 },
|
Package () { "reg", 0 },
|
||||||
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, 0, 0 } },
|
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } },
|
||||||
}
|
}
|
||||||
})
|
})
|
||||||
}
|
}
|
||||||
|
@ -151,7 +163,7 @@ References
|
||||||
referenced 2016-10-04.
|
referenced 2016-10-04.
|
||||||
|
|
||||||
[5] Hierarchical Data Extension UUID For _DSD.
|
[5] Hierarchical Data Extension UUID For _DSD.
|
||||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf>,
|
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
|
||||||
referenced 2016-10-04.
|
referenced 2016-10-04.
|
||||||
|
|
||||||
[6] Advanced Configuration and Power Interface Specification.
|
[6] Advanced Configuration and Power Interface Specification.
|
||||||
|
|
|
@ -1,3 +1,5 @@
|
||||||
|
.. _readme:
|
||||||
|
|
||||||
Linux kernel release 4.x <http://kernel.org/>
|
Linux kernel release 4.x <http://kernel.org/>
|
||||||
=============================================
|
=============================================
|
||||||
|
|
||||||
|
|
|
@ -51,6 +51,9 @@ v1 is available under Documentation/cgroup-v1/.
|
||||||
5-3. IO
|
5-3. IO
|
||||||
5-3-1. IO Interface Files
|
5-3-1. IO Interface Files
|
||||||
5-3-2. Writeback
|
5-3-2. Writeback
|
||||||
|
5-3-3. IO Latency
|
||||||
|
5-3-3-1. How IO Latency Throttling Works
|
||||||
|
5-3-3-2. IO Latency Interface Files
|
||||||
5-4. PID
|
5-4. PID
|
||||||
5-4-1. PID Interface Files
|
5-4-1. PID Interface Files
|
||||||
5-5. Device
|
5-5. Device
|
||||||
|
@ -1314,17 +1317,19 @@ IO Interface Files
|
||||||
Lines are keyed by $MAJ:$MIN device numbers and not ordered.
|
Lines are keyed by $MAJ:$MIN device numbers and not ordered.
|
||||||
The following nested keys are defined.
|
The following nested keys are defined.
|
||||||
|
|
||||||
====== ===================
|
====== =====================
|
||||||
rbytes Bytes read
|
rbytes Bytes read
|
||||||
wbytes Bytes written
|
wbytes Bytes written
|
||||||
rios Number of read IOs
|
rios Number of read IOs
|
||||||
wios Number of write IOs
|
wios Number of write IOs
|
||||||
====== ===================
|
dbytes Bytes discarded
|
||||||
|
dios Number of discard IOs
|
||||||
|
====== =====================
|
||||||
|
|
||||||
An example read output follows:
|
An example read output follows:
|
||||||
|
|
||||||
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353
|
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0
|
||||||
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252
|
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021
|
||||||
|
|
||||||
io.weight
|
io.weight
|
||||||
A read-write flat-keyed file which exists on non-root cgroups.
|
A read-write flat-keyed file which exists on non-root cgroups.
|
||||||
|
@ -1446,6 +1451,85 @@ writeback as follows.
|
||||||
vm.dirty[_background]_ratio.
|
vm.dirty[_background]_ratio.
|
||||||
|
|
||||||
|
|
||||||
|
IO Latency
|
||||||
|
~~~~~~~~~~
|
||||||
|
|
||||||
|
This is a cgroup v2 controller for IO workload protection. You provide a group
|
||||||
|
with a latency target, and if the average latency exceeds that target the
|
||||||
|
controller will throttle any peers that have a lower latency target than the
|
||||||
|
protected workload.
|
||||||
|
|
||||||
|
The limits are only applied at the peer level in the hierarchy. This means that
|
||||||
|
in the diagram below, only groups A, B, and C will influence each other, and
|
||||||
|
groups D and F will influence each other. Group G will influence nobody.
|
||||||
|
|
||||||
|
[root]
|
||||||
|
/ | \
|
||||||
|
A B C
|
||||||
|
/ \ |
|
||||||
|
D F G
|
||||||
|
|
||||||
|
|
||||||
|
So the ideal way to configure this is to set io.latency in groups A, B, and C.
|
||||||
|
Generally you do not want to set a value lower than the latency your device
|
||||||
|
supports. Experiment to find the value that works best for your workload.
|
||||||
|
Start at higher than the expected latency for your device and watch the
|
||||||
|
avg_lat value in io.stat for your workload group to get an idea of the
|
||||||
|
latency you see during normal operation. Use the avg_lat value as a basis for
|
||||||
|
your real setting, setting at 10-15% higher than the value in io.stat.
|
||||||
|
|
||||||
|
How IO Latency Throttling Works
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
io.latency is work conserving; so as long as everybody is meeting their latency
|
||||||
|
target the controller doesn't do anything. Once a group starts missing its
|
||||||
|
target it begins throttling any peer group that has a higher target than itself.
|
||||||
|
This throttling takes 2 forms:
|
||||||
|
|
||||||
|
- Queue depth throttling. This is the number of outstanding IO's a group is
|
||||||
|
allowed to have. We will clamp down relatively quickly, starting at no limit
|
||||||
|
and going all the way down to 1 IO at a time.
|
||||||
|
|
||||||
|
- Artificial delay induction. There are certain types of IO that cannot be
|
||||||
|
throttled without possibly adversely affecting higher priority groups. This
|
||||||
|
includes swapping and metadata IO. These types of IO are allowed to occur
|
||||||
|
normally, however they are "charged" to the originating group. If the
|
||||||
|
originating group is being throttled you will see the use_delay and delay
|
||||||
|
fields in io.stat increase. The delay value is how many microseconds that are
|
||||||
|
being added to any process that runs in this group. Because this number can
|
||||||
|
grow quite large if there is a lot of swapping or metadata IO occurring we
|
||||||
|
limit the individual delay events to 1 second at a time.
|
||||||
|
|
||||||
|
Once the victimized group starts meeting its latency target again it will start
|
||||||
|
unthrottling any peer groups that were throttled previously. If the victimized
|
||||||
|
group simply stops doing IO the global counter will unthrottle appropriately.
|
||||||
|
|
||||||
|
IO Latency Interface Files
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
io.latency
|
||||||
|
This takes a similar format as the other controllers.
|
||||||
|
|
||||||
|
"MAJOR:MINOR target=<target time in microseconds"
|
||||||
|
|
||||||
|
io.stat
|
||||||
|
If the controller is enabled you will see extra stats in io.stat in
|
||||||
|
addition to the normal ones.
|
||||||
|
|
||||||
|
depth
|
||||||
|
This is the current queue depth for the group.
|
||||||
|
|
||||||
|
avg_lat
|
||||||
|
This is an exponential moving average with a decay rate of 1/exp
|
||||||
|
bound by the sampling interval. The decay rate interval can be
|
||||||
|
calculated by multiplying the win value in io.stat by the
|
||||||
|
corresponding number of samples based on the win value.
|
||||||
|
|
||||||
|
win
|
||||||
|
The sampling window size in milliseconds. This is the minimum
|
||||||
|
duration of time between evaluation events. Windows only elapse
|
||||||
|
with IO activity. Idle periods extend the most recent window.
|
||||||
|
|
||||||
PID
|
PID
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
@ -17,6 +17,15 @@ etc.
|
||||||
kernel-parameters
|
kernel-parameters
|
||||||
devices
|
devices
|
||||||
|
|
||||||
|
This section describes CPU vulnerabilities and provides an overview of the
|
||||||
|
possible mitigations along with guidance for selecting mitigations if they
|
||||||
|
are configurable at compile, boot or run time.
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
l1tf
|
||||||
|
|
||||||
Here is a set of documents aimed at users who are trying to track down
|
Here is a set of documents aimed at users who are trying to track down
|
||||||
problems and bugs in particular.
|
problems and bugs in particular.
|
||||||
|
|
||||||
|
|
|
@ -748,6 +748,14 @@
|
||||||
|
|
||||||
debug [KNL] Enable kernel debugging (events log level).
|
debug [KNL] Enable kernel debugging (events log level).
|
||||||
|
|
||||||
|
debug_boot_weak_hash
|
||||||
|
[KNL] Enable printing [hashed] pointers early in the
|
||||||
|
boot sequence. If enabled, we use a weak hash instead
|
||||||
|
of siphash to hash pointers. Use this option if you are
|
||||||
|
seeing instances of '(___ptrval___)') and need to see a
|
||||||
|
value (hashed pointer) instead. Cryptographically
|
||||||
|
insecure, please do not use on production kernels.
|
||||||
|
|
||||||
debug_locks_verbose=
|
debug_locks_verbose=
|
||||||
[KNL] verbose self-tests
|
[KNL] verbose self-tests
|
||||||
Format=<0|1>
|
Format=<0|1>
|
||||||
|
@ -816,6 +824,17 @@
|
||||||
disable= [IPV6]
|
disable= [IPV6]
|
||||||
See Documentation/networking/ipv6.txt.
|
See Documentation/networking/ipv6.txt.
|
||||||
|
|
||||||
|
hardened_usercopy=
|
||||||
|
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
|
||||||
|
hardening is enabled for this boot. Hardened
|
||||||
|
usercopy checking is used to protect the kernel
|
||||||
|
from reading or writing beyond known memory
|
||||||
|
allocation boundaries as a proactive defense
|
||||||
|
against bounds-checking flaws in the kernel's
|
||||||
|
copy_to_user()/copy_from_user() interface.
|
||||||
|
on Perform hardened usercopy checks (default).
|
||||||
|
off Disable hardened usercopy checks.
|
||||||
|
|
||||||
disable_radix [PPC]
|
disable_radix [PPC]
|
||||||
Disable RADIX MMU mode on POWER9
|
Disable RADIX MMU mode on POWER9
|
||||||
|
|
||||||
|
@ -1967,10 +1986,84 @@
|
||||||
(virtualized real and unpaged mode) on capable
|
(virtualized real and unpaged mode) on capable
|
||||||
Intel chips. Default is 1 (enabled)
|
Intel chips. Default is 1 (enabled)
|
||||||
|
|
||||||
|
kvm-intel.vmentry_l1d_flush=[KVM,Intel] Mitigation for L1 Terminal Fault
|
||||||
|
CVE-2018-3620.
|
||||||
|
|
||||||
|
Valid arguments: never, cond, always
|
||||||
|
|
||||||
|
always: L1D cache flush on every VMENTER.
|
||||||
|
cond: Flush L1D on VMENTER only when the code between
|
||||||
|
VMEXIT and VMENTER can leak host memory.
|
||||||
|
never: Disables the mitigation
|
||||||
|
|
||||||
|
Default is cond (do L1 cache flush in specific instances)
|
||||||
|
|
||||||
kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification
|
kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification
|
||||||
feature (tagged TLBs) on capable Intel chips.
|
feature (tagged TLBs) on capable Intel chips.
|
||||||
Default is 1 (enabled)
|
Default is 1 (enabled)
|
||||||
|
|
||||||
|
l1tf= [X86] Control mitigation of the L1TF vulnerability on
|
||||||
|
affected CPUs
|
||||||
|
|
||||||
|
The kernel PTE inversion protection is unconditionally
|
||||||
|
enabled and cannot be disabled.
|
||||||
|
|
||||||
|
full
|
||||||
|
Provides all available mitigations for the
|
||||||
|
L1TF vulnerability. Disables SMT and
|
||||||
|
enables all mitigations in the
|
||||||
|
hypervisors, i.e. unconditional L1D flush.
|
||||||
|
|
||||||
|
SMT control and L1D flush control via the
|
||||||
|
sysfs interface is still possible after
|
||||||
|
boot. Hypervisors will issue a warning
|
||||||
|
when the first VM is started in a
|
||||||
|
potentially insecure configuration,
|
||||||
|
i.e. SMT enabled or L1D flush disabled.
|
||||||
|
|
||||||
|
full,force
|
||||||
|
Same as 'full', but disables SMT and L1D
|
||||||
|
flush runtime control. Implies the
|
||||||
|
'nosmt=force' command line option.
|
||||||
|
(i.e. sysfs control of SMT is disabled.)
|
||||||
|
|
||||||
|
flush
|
||||||
|
Leaves SMT enabled and enables the default
|
||||||
|
hypervisor mitigation, i.e. conditional
|
||||||
|
L1D flush.
|
||||||
|
|
||||||
|
SMT control and L1D flush control via the
|
||||||
|
sysfs interface is still possible after
|
||||||
|
boot. Hypervisors will issue a warning
|
||||||
|
when the first VM is started in a
|
||||||
|
potentially insecure configuration,
|
||||||
|
i.e. SMT enabled or L1D flush disabled.
|
||||||
|
|
||||||
|
flush,nosmt
|
||||||
|
|
||||||
|
Disables SMT and enables the default
|
||||||
|
hypervisor mitigation.
|
||||||
|
|
||||||
|
SMT control and L1D flush control via the
|
||||||
|
sysfs interface is still possible after
|
||||||
|
boot. Hypervisors will issue a warning
|
||||||
|
when the first VM is started in a
|
||||||
|
potentially insecure configuration,
|
||||||
|
i.e. SMT enabled or L1D flush disabled.
|
||||||
|
|
||||||
|
flush,nowarn
|
||||||
|
Same as 'flush', but hypervisors will not
|
||||||
|
warn when a VM is started in a potentially
|
||||||
|
insecure configuration.
|
||||||
|
|
||||||
|
off
|
||||||
|
Disables hypervisor mitigations and doesn't
|
||||||
|
emit any warnings.
|
||||||
|
|
||||||
|
Default is 'flush'.
|
||||||
|
|
||||||
|
For details see: Documentation/admin-guide/l1tf.rst
|
||||||
|
|
||||||
l2cr= [PPC]
|
l2cr= [PPC]
|
||||||
|
|
||||||
l3cr= [PPC]
|
l3cr= [PPC]
|
||||||
|
@ -2687,6 +2780,10 @@
|
||||||
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
||||||
Equivalent to smt=1.
|
Equivalent to smt=1.
|
||||||
|
|
||||||
|
[KNL,x86] Disable symmetric multithreading (SMT).
|
||||||
|
nosmt=force: Force disable SMT, cannot be undone
|
||||||
|
via the sysfs control file.
|
||||||
|
|
||||||
nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2
|
nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2
|
||||||
(indirect branch prediction) vulnerability. System may
|
(indirect branch prediction) vulnerability. System may
|
||||||
allow data leaks with this option, which is equivalent
|
allow data leaks with this option, which is equivalent
|
||||||
|
@ -2835,8 +2932,6 @@
|
||||||
|
|
||||||
nosync [HW,M68K] Disables sync negotiation for all devices.
|
nosync [HW,M68K] Disables sync negotiation for all devices.
|
||||||
|
|
||||||
notsc [BUGS=X86-32] Disable Time Stamp Counter
|
|
||||||
|
|
||||||
nowatchdog [KNL] Disable both lockup detectors, i.e.
|
nowatchdog [KNL] Disable both lockup detectors, i.e.
|
||||||
soft-lockup and NMI watchdog (hard-lockup).
|
soft-lockup and NMI watchdog (hard-lockup).
|
||||||
|
|
||||||
|
@ -2994,8 +3089,31 @@
|
||||||
See header of drivers/block/paride/pcd.c.
|
See header of drivers/block/paride/pcd.c.
|
||||||
See also Documentation/blockdev/paride.txt.
|
See also Documentation/blockdev/paride.txt.
|
||||||
|
|
||||||
pci=option[,option...] [PCI] various PCI subsystem options:
|
pci=option[,option...] [PCI] various PCI subsystem options.
|
||||||
earlydump [X86] dump PCI config space before the kernel
|
|
||||||
|
Some options herein operate on a specific device
|
||||||
|
or a set of devices (<pci_dev>). These are
|
||||||
|
specified in one of the following formats:
|
||||||
|
|
||||||
|
[<domain>:]<bus>:<dev>.<func>[/<dev>.<func>]*
|
||||||
|
pci:<vendor>:<device>[:<subvendor>:<subdevice>]
|
||||||
|
|
||||||
|
Note: the first format specifies a PCI
|
||||||
|
bus/device/function address which may change
|
||||||
|
if new hardware is inserted, if motherboard
|
||||||
|
firmware changes, or due to changes caused
|
||||||
|
by other kernel parameters. If the
|
||||||
|
domain is left unspecified, it is
|
||||||
|
taken to be zero. Optionally, a path
|
||||||
|
to a device through multiple device/function
|
||||||
|
addresses can be specified after the base
|
||||||
|
address (this is more robust against
|
||||||
|
renumbering issues). The second format
|
||||||
|
selects devices using IDs from the
|
||||||
|
configuration space which may match multiple
|
||||||
|
devices in the system.
|
||||||
|
|
||||||
|
earlydump dump PCI config space before the kernel
|
||||||
changes anything
|
changes anything
|
||||||
off [X86] don't probe for the PCI bus
|
off [X86] don't probe for the PCI bus
|
||||||
bios [X86-32] force use of PCI BIOS, don't access
|
bios [X86-32] force use of PCI BIOS, don't access
|
||||||
|
@ -3123,11 +3241,10 @@
|
||||||
window. The default value is 64 megabytes.
|
window. The default value is 64 megabytes.
|
||||||
resource_alignment=
|
resource_alignment=
|
||||||
Format:
|
Format:
|
||||||
[<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...]
|
[<order of align>@]<pci_dev>[; ...]
|
||||||
[<order of align>@]pci:<vendor>:<device>\
|
|
||||||
[:<subvendor>:<subdevice>][; ...]
|
|
||||||
Specifies alignment and device to reassign
|
Specifies alignment and device to reassign
|
||||||
aligned memory resources.
|
aligned memory resources. How to
|
||||||
|
specify the device is described above.
|
||||||
If <order of align> is not specified,
|
If <order of align> is not specified,
|
||||||
PAGE_SIZE is used as alignment.
|
PAGE_SIZE is used as alignment.
|
||||||
PCI-PCI bridge can be specified, if resource
|
PCI-PCI bridge can be specified, if resource
|
||||||
|
@ -3170,6 +3287,15 @@
|
||||||
Adding the window is slightly risky (it may
|
Adding the window is slightly risky (it may
|
||||||
conflict with unreported devices), so this
|
conflict with unreported devices), so this
|
||||||
taints the kernel.
|
taints the kernel.
|
||||||
|
disable_acs_redir=<pci_dev>[; ...]
|
||||||
|
Specify one or more PCI devices (in the format
|
||||||
|
specified above) separated by semicolons.
|
||||||
|
Each device specified will have the PCI ACS
|
||||||
|
redirect capabilities forced off which will
|
||||||
|
allow P2P traffic between devices through
|
||||||
|
bridges without forcing it upstream. Note:
|
||||||
|
this removes isolation between devices and
|
||||||
|
may put more devices in an IOMMU group.
|
||||||
|
|
||||||
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
||||||
Management.
|
Management.
|
||||||
|
@ -3632,8 +3758,8 @@
|
||||||
Set time (s) after boot for CPU-hotplug testing.
|
Set time (s) after boot for CPU-hotplug testing.
|
||||||
|
|
||||||
rcutorture.onoff_interval= [KNL]
|
rcutorture.onoff_interval= [KNL]
|
||||||
Set time (s) between CPU-hotplug operations, or
|
Set time (jiffies) between CPU-hotplug operations,
|
||||||
zero to disable CPU-hotplug testing.
|
or zero to disable CPU-hotplug testing.
|
||||||
|
|
||||||
rcutorture.shuffle_interval= [KNL]
|
rcutorture.shuffle_interval= [KNL]
|
||||||
Set task-shuffle interval (s). Shuffling tasks
|
Set task-shuffle interval (s). Shuffling tasks
|
||||||
|
@ -4060,6 +4186,8 @@
|
||||||
This parameter controls whether the Speculative Store
|
This parameter controls whether the Speculative Store
|
||||||
Bypass optimization is used.
|
Bypass optimization is used.
|
||||||
|
|
||||||
|
On x86 the options are:
|
||||||
|
|
||||||
on - Unconditionally disable Speculative Store Bypass
|
on - Unconditionally disable Speculative Store Bypass
|
||||||
off - Unconditionally enable Speculative Store Bypass
|
off - Unconditionally enable Speculative Store Bypass
|
||||||
auto - Kernel detects whether the CPU model contains an
|
auto - Kernel detects whether the CPU model contains an
|
||||||
|
@ -4075,12 +4203,20 @@
|
||||||
seccomp - Same as "prctl" above, but all seccomp threads
|
seccomp - Same as "prctl" above, but all seccomp threads
|
||||||
will disable SSB unless they explicitly opt out.
|
will disable SSB unless they explicitly opt out.
|
||||||
|
|
||||||
Not specifying this option is equivalent to
|
|
||||||
spec_store_bypass_disable=auto.
|
|
||||||
|
|
||||||
Default mitigations:
|
Default mitigations:
|
||||||
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
|
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
|
||||||
|
|
||||||
|
On powerpc the options are:
|
||||||
|
|
||||||
|
on,auto - On Power8 and Power9 insert a store-forwarding
|
||||||
|
barrier on kernel entry and exit. On Power7
|
||||||
|
perform a software flush on kernel entry and
|
||||||
|
exit.
|
||||||
|
off - No action.
|
||||||
|
|
||||||
|
Not specifying this option is equivalent to
|
||||||
|
spec_store_bypass_disable=auto.
|
||||||
|
|
||||||
spia_io_base= [HW,MTD]
|
spia_io_base= [HW,MTD]
|
||||||
spia_fio_base=
|
spia_fio_base=
|
||||||
spia_pedr=
|
spia_pedr=
|
||||||
|
|
610
Documentation/admin-guide/l1tf.rst
Normal file
|
@ -0,0 +1,610 @@
|
||||||
|
L1TF - L1 Terminal Fault
|
||||||
|
========================
|
||||||
|
|
||||||
|
L1 Terminal Fault is a hardware vulnerability which allows unprivileged
|
||||||
|
speculative access to data which is available in the Level 1 Data Cache
|
||||||
|
when the page table entry controlling the virtual address, which is used
|
||||||
|
for the access, has the Present bit cleared or other reserved bits set.
|
||||||
|
|
||||||
|
Affected processors
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
This vulnerability affects a wide range of Intel processors. The
|
||||||
|
vulnerability is not present on:
|
||||||
|
|
||||||
|
- Processors from AMD, Centaur and other non Intel vendors
|
||||||
|
|
||||||
|
- Older processor models, where the CPU family is < 6
|
||||||
|
|
||||||
|
- A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
|
||||||
|
Penwell, Pineview, Silvermont, Airmont, Merrifield)
|
||||||
|
|
||||||
|
- The Intel XEON PHI family
|
||||||
|
|
||||||
|
- Intel processors which have the ARCH_CAP_RDCL_NO bit set in the
|
||||||
|
IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
|
||||||
|
by the Meltdown vulnerability either. These CPUs should become
|
||||||
|
available by end of 2018.
|
||||||
|
|
||||||
|
Whether a processor is affected or not can be read out from the L1TF
|
||||||
|
vulnerability file in sysfs. See :ref:`l1tf_sys_info`.
|
||||||
|
|
||||||
|
Related CVEs
|
||||||
|
------------
|
||||||
|
|
||||||
|
The following CVE entries are related to the L1TF vulnerability:
|
||||||
|
|
||||||
|
============= ================= ==============================
|
||||||
|
CVE-2018-3615 L1 Terminal Fault SGX related aspects
|
||||||
|
CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects
|
||||||
|
CVE-2018-3646 L1 Terminal Fault Virtualization related aspects
|
||||||
|
============= ================= ==============================
|
||||||
|
|
||||||
|
Problem
|
||||||
|
-------
|
||||||
|
|
||||||
|
If an instruction accesses a virtual address for which the relevant page
|
||||||
|
table entry (PTE) has the Present bit cleared or other reserved bits set,
|
||||||
|
then speculative execution ignores the invalid PTE and loads the referenced
|
||||||
|
data if it is present in the Level 1 Data Cache, as if the page referenced
|
||||||
|
by the address bits in the PTE was still present and accessible.
|
||||||
|
|
||||||
|
While this is a purely speculative mechanism and the instruction will raise
|
||||||
|
a page fault when it is retired eventually, the pure act of loading the
|
||||||
|
data and making it available to other speculative instructions opens up the
|
||||||
|
opportunity for side channel attacks to unprivileged malicious code,
|
||||||
|
similar to the Meltdown attack.
|
||||||
|
|
||||||
|
While Meltdown breaks the user space to kernel space protection, L1TF
|
||||||
|
allows to attack any physical memory address in the system and the attack
|
||||||
|
works across all protection domains. It allows an attack of SGX and also
|
||||||
|
works from inside virtual machines because the speculation bypasses the
|
||||||
|
extended page table (EPT) protection mechanism.
|
||||||
|
|
||||||
|
|
||||||
|
Attack scenarios
|
||||||
|
----------------
|
||||||
|
|
||||||
|
1. Malicious user space
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Operating Systems store arbitrary information in the address bits of a
|
||||||
|
PTE which is marked non present. This allows a malicious user space
|
||||||
|
application to attack the physical memory to which these PTEs resolve.
|
||||||
|
In some cases user-space can maliciously influence the information
|
||||||
|
encoded in the address bits of the PTE, thus making attacks more
|
||||||
|
deterministic and more practical.
|
||||||
|
|
||||||
|
The Linux kernel contains a mitigation for this attack vector, PTE
|
||||||
|
inversion, which is permanently enabled and has no performance
|
||||||
|
impact. The kernel ensures that the address bits of PTEs, which are not
|
||||||
|
marked present, never point to cacheable physical memory space.
|
||||||
|
|
||||||
|
A system with an up to date kernel is protected against attacks from
|
||||||
|
malicious user space applications.
|
||||||
|
|
||||||
|
2. Malicious guest in a virtual machine
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
The fact that L1TF breaks all domain protections allows malicious guest
|
||||||
|
OSes, which can control the PTEs directly, and malicious guest user
|
||||||
|
space applications, which run on an unprotected guest kernel lacking the
|
||||||
|
PTE inversion mitigation for L1TF, to attack physical host memory.
|
||||||
|
|
||||||
|
A special aspect of L1TF in the context of virtualization is symmetric
|
||||||
|
multi threading (SMT). The Intel implementation of SMT is called
|
||||||
|
HyperThreading. The fact that Hyperthreads on the affected processors
|
||||||
|
share the L1 Data Cache (L1D) is important for this. As the flaw allows
|
||||||
|
only to attack data which is present in L1D, a malicious guest running
|
||||||
|
on one Hyperthread can attack the data which is brought into the L1D by
|
||||||
|
the context which runs on the sibling Hyperthread of the same physical
|
||||||
|
core. This context can be host OS, host user space or a different guest.
|
||||||
|
|
||||||
|
If the processor does not support Extended Page Tables, the attack is
|
||||||
|
only possible, when the hypervisor does not sanitize the content of the
|
||||||
|
effective (shadow) page tables.
|
||||||
|
|
||||||
|
While solutions exist to mitigate these attack vectors fully, these
|
||||||
|
mitigations are not enabled by default in the Linux kernel because they
|
||||||
|
can affect performance significantly. The kernel provides several
|
||||||
|
mechanisms which can be utilized to address the problem depending on the
|
||||||
|
deployment scenario. The mitigations, their protection scope and impact
|
||||||
|
are described in the next sections.
|
||||||
|
|
||||||
|
The default mitigations and the rationale for choosing them are explained
|
||||||
|
at the end of this document. See :ref:`default_mitigations`.
|
||||||
|
|
||||||
|
.. _l1tf_sys_info:
|
||||||
|
|
||||||
|
L1TF system information
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
The Linux kernel provides a sysfs interface to enumerate the current L1TF
|
||||||
|
status of the system: whether the system is vulnerable, and which
|
||||||
|
mitigations are active. The relevant sysfs file is:
|
||||||
|
|
||||||
|
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||||
|
|
||||||
|
The possible values in this file are:
|
||||||
|
|
||||||
|
=========================== ===============================
|
||||||
|
'Not affected' The processor is not vulnerable
|
||||||
|
'Mitigation: PTE Inversion' The host protection is active
|
||||||
|
=========================== ===============================
|
||||||
|
|
||||||
|
If KVM/VMX is enabled and the processor is vulnerable then the following
|
||||||
|
information is appended to the 'Mitigation: PTE Inversion' part:
|
||||||
|
|
||||||
|
- SMT status:
|
||||||
|
|
||||||
|
===================== ================
|
||||||
|
'VMX: SMT vulnerable' SMT is enabled
|
||||||
|
'VMX: SMT disabled' SMT is disabled
|
||||||
|
===================== ================
|
||||||
|
|
||||||
|
- L1D Flush mode:
|
||||||
|
|
||||||
|
================================ ====================================
|
||||||
|
'L1D vulnerable' L1D flushing is disabled
|
||||||
|
|
||||||
|
'L1D conditional cache flushes' L1D flush is conditionally enabled
|
||||||
|
|
||||||
|
'L1D cache flushes' L1D flush is unconditionally enabled
|
||||||
|
================================ ====================================
|
||||||
|
|
||||||
|
The resulting grade of protection is discussed in the following sections.
|
||||||
|
|
||||||
|
|
||||||
|
Host mitigation mechanism
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
The kernel is unconditionally protected against L1TF attacks from malicious
|
||||||
|
user space running on the host.
|
||||||
|
|
||||||
|
|
||||||
|
Guest mitigation mechanisms
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
.. _l1d_flush:
|
||||||
|
|
||||||
|
1. L1D flush on VMENTER
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
To make sure that a guest cannot attack data which is present in the L1D
|
||||||
|
the hypervisor flushes the L1D before entering the guest.
|
||||||
|
|
||||||
|
Flushing the L1D evicts not only the data which should not be accessed
|
||||||
|
by a potentially malicious guest, it also flushes the guest
|
||||||
|
data. Flushing the L1D has a performance impact as the processor has to
|
||||||
|
bring the flushed guest data back into the L1D. Depending on the
|
||||||
|
frequency of VMEXIT/VMENTER and the type of computations in the guest
|
||||||
|
performance degradation in the range of 1% to 50% has been observed. For
|
||||||
|
scenarios where guest VMEXIT/VMENTER are rare the performance impact is
|
||||||
|
minimal. Virtio and mechanisms like posted interrupts are designed to
|
||||||
|
confine the VMEXITs to a bare minimum, but specific configurations and
|
||||||
|
application scenarios might still suffer from a high VMEXIT rate.
|
||||||
|
|
||||||
|
The kernel provides two L1D flush modes:
|
||||||
|
- conditional ('cond')
|
||||||
|
- unconditional ('always')
|
||||||
|
|
||||||
|
The conditional mode avoids L1D flushing after VMEXITs which execute
|
||||||
|
only audited code paths before the corresponding VMENTER. These code
|
||||||
|
paths have been verified that they cannot expose secrets or other
|
||||||
|
interesting data to an attacker, but they can leak information about the
|
||||||
|
address space layout of the hypervisor.
|
||||||
|
|
||||||
|
Unconditional mode flushes L1D on all VMENTER invocations and provides
|
||||||
|
maximum protection. It has a higher overhead than the conditional
|
||||||
|
mode. The overhead cannot be quantified correctly as it depends on the
|
||||||
|
workload scenario and the resulting number of VMEXITs.
|
||||||
|
|
||||||
|
The general recommendation is to enable L1D flush on VMENTER. The kernel
|
||||||
|
defaults to conditional mode on affected processors.
|
||||||
|
|
||||||
|
**Note**, that L1D flush does not prevent the SMT problem because the
|
||||||
|
sibling thread will also bring back its data into the L1D which makes it
|
||||||
|
attackable again.
|
||||||
|
|
||||||
|
L1D flush can be controlled by the administrator via the kernel command
|
||||||
|
line and sysfs control files. See :ref:`mitigation_control_command_line`
|
||||||
|
and :ref:`mitigation_control_kvm`.
|
||||||
|
|
||||||
|
.. _guest_confinement:
|
||||||
|
|
||||||
|
2. Guest VCPU confinement to dedicated physical cores
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
To address the SMT problem, it is possible to make a guest or a group of
|
||||||
|
guests affine to one or more physical cores. The proper mechanism for
|
||||||
|
that is to utilize exclusive cpusets to ensure that no other guest or
|
||||||
|
host tasks can run on these cores.
|
||||||
|
|
||||||
|
If only a single guest or related guests run on sibling SMT threads on
|
||||||
|
the same physical core then they can only attack their own memory and
|
||||||
|
restricted parts of the host memory.
|
||||||
|
|
||||||
|
Host memory is attackable, when one of the sibling SMT threads runs in
|
||||||
|
host OS (hypervisor) context and the other in guest context. The amount
|
||||||
|
of valuable information from the host OS context depends on the context
|
||||||
|
which the host OS executes, i.e. interrupts, soft interrupts and kernel
|
||||||
|
threads. The amount of valuable data from these contexts cannot be
|
||||||
|
declared as non-interesting for an attacker without deep inspection of
|
||||||
|
the code.
|
||||||
|
|
||||||
|
**Note**, that assigning guests to a fixed set of physical cores affects
|
||||||
|
the ability of the scheduler to do load balancing and might have
|
||||||
|
negative effects on CPU utilization depending on the hosting
|
||||||
|
scenario. Disabling SMT might be a viable alternative for particular
|
||||||
|
scenarios.
|
||||||
|
|
||||||
|
For further information about confining guests to a single or to a group
|
||||||
|
of cores consult the cpusets documentation:
|
||||||
|
|
||||||
|
https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt
|
||||||
|
|
||||||
|
.. _interrupt_isolation:
|
||||||
|
|
||||||
|
3. Interrupt affinity
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Interrupts can be made affine to logical CPUs. This is not universally
|
||||||
|
true because there are types of interrupts which are truly per CPU
|
||||||
|
interrupts, e.g. the local timer interrupt. Aside of that multi queue
|
||||||
|
devices affine their interrupts to single CPUs or groups of CPUs per
|
||||||
|
queue without allowing the administrator to control the affinities.
|
||||||
|
|
||||||
|
Moving the interrupts, which can be affinity controlled, away from CPUs
|
||||||
|
which run untrusted guests, reduces the attack vector space.
|
||||||
|
|
||||||
|
Whether the interrupts with are affine to CPUs, which run untrusted
|
||||||
|
guests, provide interesting data for an attacker depends on the system
|
||||||
|
configuration and the scenarios which run on the system. While for some
|
||||||
|
of the interrupts it can be assumed that they won't expose interesting
|
||||||
|
information beyond exposing hints about the host OS memory layout, there
|
||||||
|
is no way to make general assumptions.
|
||||||
|
|
||||||
|
Interrupt affinity can be controlled by the administrator via the
|
||||||
|
/proc/irq/$NR/smp_affinity[_list] files. Limited documentation is
|
||||||
|
available at:
|
||||||
|
|
||||||
|
https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
|
||||||
|
|
||||||
|
.. _smt_control:
|
||||||
|
|
||||||
|
4. SMT control
|
||||||
|
^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
To prevent the SMT issues of L1TF it might be necessary to disable SMT
|
||||||
|
completely. Disabling SMT can have a significant performance impact, but
|
||||||
|
the impact depends on the hosting scenario and the type of workloads.
|
||||||
|
The impact of disabling SMT needs also to be weighted against the impact
|
||||||
|
of other mitigation solutions like confining guests to dedicated cores.
|
||||||
|
|
||||||
|
The kernel provides a sysfs interface to retrieve the status of SMT and
|
||||||
|
to control it. It also provides a kernel command line interface to
|
||||||
|
control SMT.
|
||||||
|
|
||||||
|
The kernel command line interface consists of the following options:
|
||||||
|
|
||||||
|
=========== ==========================================================
|
||||||
|
nosmt Affects the bring up of the secondary CPUs during boot. The
|
||||||
|
kernel tries to bring all present CPUs online during the
|
||||||
|
boot process. "nosmt" makes sure that from each physical
|
||||||
|
core only one - the so called primary (hyper) thread is
|
||||||
|
activated. Due to a design flaw of Intel processors related
|
||||||
|
to Machine Check Exceptions the non primary siblings have
|
||||||
|
to be brought up at least partially and are then shut down
|
||||||
|
again. "nosmt" can be undone via the sysfs interface.
|
||||||
|
|
||||||
|
nosmt=force Has the same effect as "nosmt" but it does not allow to
|
||||||
|
undo the SMT disable via the sysfs interface.
|
||||||
|
=========== ==========================================================
|
||||||
|
|
||||||
|
The sysfs interface provides two files:
|
||||||
|
|
||||||
|
- /sys/devices/system/cpu/smt/control
|
||||||
|
- /sys/devices/system/cpu/smt/active
|
||||||
|
|
||||||
|
/sys/devices/system/cpu/smt/control:
|
||||||
|
|
||||||
|
This file allows to read out the SMT control state and provides the
|
||||||
|
ability to disable or (re)enable SMT. The possible states are:
|
||||||
|
|
||||||
|
============== ===================================================
|
||||||
|
on SMT is supported by the CPU and enabled. All
|
||||||
|
logical CPUs can be onlined and offlined without
|
||||||
|
restrictions.
|
||||||
|
|
||||||
|
off SMT is supported by the CPU and disabled. Only
|
||||||
|
the so called primary SMT threads can be onlined
|
||||||
|
and offlined without restrictions. An attempt to
|
||||||
|
online a non-primary sibling is rejected
|
||||||
|
|
||||||
|
forceoff Same as 'off' but the state cannot be controlled.
|
||||||
|
Attempts to write to the control file are rejected.
|
||||||
|
|
||||||
|
notsupported The processor does not support SMT. It's therefore
|
||||||
|
not affected by the SMT implications of L1TF.
|
||||||
|
Attempts to write to the control file are rejected.
|
||||||
|
============== ===================================================
|
||||||
|
|
||||||
|
The possible states which can be written into this file to control SMT
|
||||||
|
state are:
|
||||||
|
|
||||||
|
- on
|
||||||
|
- off
|
||||||
|
- forceoff
|
||||||
|
|
||||||
|
/sys/devices/system/cpu/smt/active:
|
||||||
|
|
||||||
|
This file reports whether SMT is enabled and active, i.e. if on any
|
||||||
|
physical core two or more sibling threads are online.
|
||||||
|
|
||||||
|
SMT control is also possible at boot time via the l1tf kernel command
|
||||||
|
line parameter in combination with L1D flush control. See
|
||||||
|
:ref:`mitigation_control_command_line`.
|
||||||
|
|
||||||
|
5. Disabling EPT
|
||||||
|
^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Disabling EPT for virtual machines provides full mitigation for L1TF even
|
||||||
|
with SMT enabled, because the effective page tables for guests are
|
||||||
|
managed and sanitized by the hypervisor. Though disabling EPT has a
|
||||||
|
significant performance impact especially when the Meltdown mitigation
|
||||||
|
KPTI is enabled.
|
||||||
|
|
||||||
|
EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
|
||||||
|
|
||||||
|
There is ongoing research and development for new mitigation mechanisms to
|
||||||
|
address the performance impact of disabling SMT or EPT.
|
||||||
|
|
||||||
|
.. _mitigation_control_command_line:
|
||||||
|
|
||||||
|
Mitigation control on the kernel command line
|
||||||
|
---------------------------------------------
|
||||||
|
|
||||||
|
The kernel command line allows to control the L1TF mitigations at boot
|
||||||
|
time with the option "l1tf=". The valid arguments for this option are:
|
||||||
|
|
||||||
|
============ =============================================================
|
||||||
|
full Provides all available mitigations for the L1TF
|
||||||
|
vulnerability. Disables SMT and enables all mitigations in
|
||||||
|
the hypervisors, i.e. unconditional L1D flushing
|
||||||
|
|
||||||
|
SMT control and L1D flush control via the sysfs interface
|
||||||
|
is still possible after boot. Hypervisors will issue a
|
||||||
|
warning when the first VM is started in a potentially
|
||||||
|
insecure configuration, i.e. SMT enabled or L1D flush
|
||||||
|
disabled.
|
||||||
|
|
||||||
|
full,force Same as 'full', but disables SMT and L1D flush runtime
|
||||||
|
control. Implies the 'nosmt=force' command line option.
|
||||||
|
(i.e. sysfs control of SMT is disabled.)
|
||||||
|
|
||||||
|
flush Leaves SMT enabled and enables the default hypervisor
|
||||||
|
mitigation, i.e. conditional L1D flushing
|
||||||
|
|
||||||
|
SMT control and L1D flush control via the sysfs interface
|
||||||
|
is still possible after boot. Hypervisors will issue a
|
||||||
|
warning when the first VM is started in a potentially
|
||||||
|
insecure configuration, i.e. SMT enabled or L1D flush
|
||||||
|
disabled.
|
||||||
|
|
||||||
|
flush,nosmt Disables SMT and enables the default hypervisor mitigation,
|
||||||
|
i.e. conditional L1D flushing.
|
||||||
|
|
||||||
|
SMT control and L1D flush control via the sysfs interface
|
||||||
|
is still possible after boot. Hypervisors will issue a
|
||||||
|
warning when the first VM is started in a potentially
|
||||||
|
insecure configuration, i.e. SMT enabled or L1D flush
|
||||||
|
disabled.
|
||||||
|
|
||||||
|
flush,nowarn Same as 'flush', but hypervisors will not warn when a VM is
|
||||||
|
started in a potentially insecure configuration.
|
||||||
|
|
||||||
|
off Disables hypervisor mitigations and doesn't emit any
|
||||||
|
warnings.
|
||||||
|
============ =============================================================
|
||||||
|
|
||||||
|
The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
|
||||||
|
|
||||||
|
|
||||||
|
.. _mitigation_control_kvm:
|
||||||
|
|
||||||
|
Mitigation control for KVM - module parameter
|
||||||
|
-------------------------------------------------------------
|
||||||
|
|
||||||
|
The KVM hypervisor mitigation mechanism, flushing the L1D cache when
|
||||||
|
entering a guest, can be controlled with a module parameter.
|
||||||
|
|
||||||
|
The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the
|
||||||
|
following arguments:
|
||||||
|
|
||||||
|
============ ==============================================================
|
||||||
|
always L1D cache flush on every VMENTER.
|
||||||
|
|
||||||
|
cond Flush L1D on VMENTER only when the code between VMEXIT and
|
||||||
|
VMENTER can leak host memory which is considered
|
||||||
|
interesting for an attacker. This still can leak host memory
|
||||||
|
which allows e.g. to determine the hosts address space layout.
|
||||||
|
|
||||||
|
never Disables the mitigation
|
||||||
|
============ ==============================================================
|
||||||
|
|
||||||
|
The parameter can be provided on the kernel command line, as a module
|
||||||
|
parameter when loading the modules and at runtime modified via the sysfs
|
||||||
|
file:
|
||||||
|
|
||||||
|
/sys/module/kvm_intel/parameters/vmentry_l1d_flush
|
||||||
|
|
||||||
|
The default is 'cond'. If 'l1tf=full,force' is given on the kernel command
|
||||||
|
line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
|
||||||
|
module parameter is ignored and writes to the sysfs file are rejected.
|
||||||
|
|
||||||
|
|
||||||
|
Mitigation selection guide
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
1. No virtualization in use
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
The system is protected by the kernel unconditionally and no further
|
||||||
|
action is required.
|
||||||
|
|
||||||
|
2. Virtualization with trusted guests
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
If the guest comes from a trusted source and the guest OS kernel is
|
||||||
|
guaranteed to have the L1TF mitigations in place the system is fully
|
||||||
|
protected against L1TF and no further action is required.
|
||||||
|
|
||||||
|
To avoid the overhead of the default L1D flushing on VMENTER the
|
||||||
|
administrator can disable the flushing via the kernel command line and
|
||||||
|
sysfs control files. See :ref:`mitigation_control_command_line` and
|
||||||
|
:ref:`mitigation_control_kvm`.
|
||||||
|
|
||||||
|
|
||||||
|
3. Virtualization with untrusted guests
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
3.1. SMT not supported or disabled
|
||||||
|
""""""""""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
If SMT is not supported by the processor or disabled in the BIOS or by
|
||||||
|
the kernel, it's only required to enforce L1D flushing on VMENTER.
|
||||||
|
|
||||||
|
Conditional L1D flushing is the default behaviour and can be tuned. See
|
||||||
|
:ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
|
||||||
|
|
||||||
|
3.2. EPT not supported or disabled
|
||||||
|
""""""""""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
If EPT is not supported by the processor or disabled in the hypervisor,
|
||||||
|
the system is fully protected. SMT can stay enabled and L1D flushing on
|
||||||
|
VMENTER is not required.
|
||||||
|
|
||||||
|
EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
|
||||||
|
|
||||||
|
3.3. SMT and EPT supported and active
|
||||||
|
"""""""""""""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
If SMT and EPT are supported and active then various degrees of
|
||||||
|
mitigations can be employed:
|
||||||
|
|
||||||
|
- L1D flushing on VMENTER:
|
||||||
|
|
||||||
|
L1D flushing on VMENTER is the minimal protection requirement, but it
|
||||||
|
is only potent in combination with other mitigation methods.
|
||||||
|
|
||||||
|
Conditional L1D flushing is the default behaviour and can be tuned. See
|
||||||
|
:ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
|
||||||
|
|
||||||
|
- Guest confinement:
|
||||||
|
|
||||||
|
Confinement of guests to a single or a group of physical cores which
|
||||||
|
are not running any other processes, can reduce the attack surface
|
||||||
|
significantly, but interrupts, soft interrupts and kernel threads can
|
||||||
|
still expose valuable data to a potential attacker. See
|
||||||
|
:ref:`guest_confinement`.
|
||||||
|
|
||||||
|
- Interrupt isolation:
|
||||||
|
|
||||||
|
Isolating the guest CPUs from interrupts can reduce the attack surface
|
||||||
|
further, but still allows a malicious guest to explore a limited amount
|
||||||
|
of host physical memory. This can at least be used to gain knowledge
|
||||||
|
about the host address space layout. The interrupts which have a fixed
|
||||||
|
affinity to the CPUs which run the untrusted guests can depending on
|
||||||
|
the scenario still trigger soft interrupts and schedule kernel threads
|
||||||
|
which might expose valuable information. See
|
||||||
|
:ref:`interrupt_isolation`.
|
||||||
|
|
||||||
|
The above three mitigation methods combined can provide protection to a
|
||||||
|
certain degree, but the risk of the remaining attack surface has to be
|
||||||
|
carefully analyzed. For full protection the following methods are
|
||||||
|
available:
|
||||||
|
|
||||||
|
- Disabling SMT:
|
||||||
|
|
||||||
|
Disabling SMT and enforcing the L1D flushing provides the maximum
|
||||||
|
amount of protection. This mitigation is not depending on any of the
|
||||||
|
above mitigation methods.
|
||||||
|
|
||||||
|
SMT control and L1D flushing can be tuned by the command line
|
||||||
|
parameters 'nosmt', 'l1tf', 'kvm-intel.vmentry_l1d_flush' and at run
|
||||||
|
time with the matching sysfs control files. See :ref:`smt_control`,
|
||||||
|
:ref:`mitigation_control_command_line` and
|
||||||
|
:ref:`mitigation_control_kvm`.
|
||||||
|
|
||||||
|
- Disabling EPT:
|
||||||
|
|
||||||
|
Disabling EPT provides the maximum amount of protection as well. It is
|
||||||
|
not depending on any of the above mitigation methods. SMT can stay
|
||||||
|
enabled and L1D flushing is not required, but the performance impact is
|
||||||
|
significant.
|
||||||
|
|
||||||
|
EPT can be disabled in the hypervisor via the 'kvm-intel.ept'
|
||||||
|
parameter.
|
||||||
|
|
||||||
|
3.4. Nested virtual machines
|
||||||
|
""""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
When nested virtualization is in use, three operating systems are involved:
|
||||||
|
the bare metal hypervisor, the nested hypervisor and the nested virtual
|
||||||
|
machine. VMENTER operations from the nested hypervisor into the nested
|
||||||
|
guest will always be processed by the bare metal hypervisor. If KVM is the
|
||||||
|
bare metal hypervisor it wiil:
|
||||||
|
|
||||||
|
- Flush the L1D cache on every switch from the nested hypervisor to the
|
||||||
|
nested virtual machine, so that the nested hypervisor's secrets are not
|
||||||
|
exposed to the nested virtual machine;
|
||||||
|
|
||||||
|
- Flush the L1D cache on every switch from the nested virtual machine to
|
||||||
|
the nested hypervisor; this is a complex operation, and flushing the L1D
|
||||||
|
cache avoids that the bare metal hypervisor's secrets are exposed to the
|
||||||
|
nested virtual machine;
|
||||||
|
|
||||||
|
- Instruct the nested hypervisor to not perform any L1D cache flush. This
|
||||||
|
is an optimization to avoid double L1D flushing.
|
||||||
|
|
||||||
|
|
||||||
|
.. _default_mitigations:
|
||||||
|
|
||||||
|
Default mitigations
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
The kernel default mitigations for vulnerable processors are:
|
||||||
|
|
||||||
|
- PTE inversion to protect against malicious user space. This is done
|
||||||
|
unconditionally and cannot be controlled.
|
||||||
|
|
||||||
|
- L1D conditional flushing on VMENTER when EPT is enabled for
|
||||||
|
a guest.
|
||||||
|
|
||||||
|
The kernel does not by default enforce the disabling of SMT, which leaves
|
||||||
|
SMT systems vulnerable when running untrusted guests with EPT enabled.
|
||||||
|
|
||||||
|
The rationale for this choice is:
|
||||||
|
|
||||||
|
- Force disabling SMT can break existing setups, especially with
|
||||||
|
unattended updates.
|
||||||
|
|
||||||
|
- If regular users run untrusted guests on their machine, then L1TF is
|
||||||
|
just an add on to other malware which might be embedded in an untrusted
|
||||||
|
guest, e.g. spam-bots or attacks on the local network.
|
||||||
|
|
||||||
|
There is no technical way to prevent a user from running untrusted code
|
||||||
|
on their machines blindly.
|
||||||
|
|
||||||
|
- It's technically extremely unlikely and from today's knowledge even
|
||||||
|
impossible that L1TF can be exploited via the most popular attack
|
||||||
|
mechanisms like JavaScript because these mechanisms have no way to
|
||||||
|
control PTEs. If this would be possible and not other mitigation would
|
||||||
|
be possible, then the default might be different.
|
||||||
|
|
||||||
|
- The administrators of cloud and hosting setups have to carefully
|
||||||
|
analyze the risk for their scenarios and make the appropriate
|
||||||
|
mitigation choices, which might even vary across their deployed
|
||||||
|
machines and also result in other changes of their overall setup.
|
||||||
|
There is no way for the kernel to provide a sensible default for this
|
||||||
|
kind of scenarios.
|
|
@ -85,3 +85,10 @@ shared_tags=[0/1]: Default: 0
|
||||||
0: Tag set is not shared.
|
0: Tag set is not shared.
|
||||||
1: Tag set shared between devices for blk-mq. Only makes sense with
|
1: Tag set shared between devices for blk-mq. Only makes sense with
|
||||||
nr_devices > 1, otherwise there's no tag set to share.
|
nr_devices > 1, otherwise there's no tag set to share.
|
||||||
|
|
||||||
|
zoned=[0/1]: Default: 0
|
||||||
|
0: Block device is exposed as a random-access block device.
|
||||||
|
1: Block device is exposed as a host-managed zoned block device.
|
||||||
|
|
||||||
|
zone_size=[MB]: Default: 256
|
||||||
|
Per zone size when exposed as a zoned block device. Must be a power of two.
|
||||||
|
|
|
@ -31,28 +31,32 @@ write ticks milliseconds total wait time for write requests
|
||||||
in_flight requests number of I/Os currently in flight
|
in_flight requests number of I/Os currently in flight
|
||||||
io_ticks milliseconds total time this block device has been active
|
io_ticks milliseconds total time this block device has been active
|
||||||
time_in_queue milliseconds total wait time for all requests
|
time_in_queue milliseconds total wait time for all requests
|
||||||
|
discard I/Os requests number of discard I/Os processed
|
||||||
|
discard merges requests number of discard I/Os merged with in-queue I/O
|
||||||
|
discard sectors sectors number of sectors discarded
|
||||||
|
discard ticks milliseconds total wait time for discard requests
|
||||||
|
|
||||||
read I/Os, write I/Os
|
read I/Os, write I/Os, discard I/0s
|
||||||
=====================
|
===================================
|
||||||
|
|
||||||
These values increment when an I/O request completes.
|
These values increment when an I/O request completes.
|
||||||
|
|
||||||
read merges, write merges
|
read merges, write merges, discard merges
|
||||||
=========================
|
=========================================
|
||||||
|
|
||||||
These values increment when an I/O request is merged with an
|
These values increment when an I/O request is merged with an
|
||||||
already-queued I/O request.
|
already-queued I/O request.
|
||||||
|
|
||||||
read sectors, write sectors
|
read sectors, write sectors, discard_sectors
|
||||||
===========================
|
============================================
|
||||||
|
|
||||||
These values count the number of sectors read from or written to this
|
These values count the number of sectors read from, written to, or
|
||||||
block device. The "sectors" in question are the standard UNIX 512-byte
|
discarded from this block device. The "sectors" in question are the
|
||||||
sectors, not any device- or filesystem-specific block size. The
|
standard UNIX 512-byte sectors, not any device- or filesystem-specific
|
||||||
counters are incremented when the I/O completes.
|
block size. The counters are incremented when the I/O completes.
|
||||||
|
|
||||||
read ticks, write ticks
|
read ticks, write ticks, discard ticks
|
||||||
=======================
|
======================================
|
||||||
|
|
||||||
These values count the number of milliseconds that I/O requests have
|
These values count the number of milliseconds that I/O requests have
|
||||||
waited on this block device. If there are multiple I/O requests waiting,
|
waited on this block device. If there are multiple I/O requests waiting,
|
||||||
|
|
|
@ -106,9 +106,9 @@ into the bpf-next tree will make their way into net-next tree. net and
|
||||||
net-next are both run by David S. Miller. From there, they will go
|
net-next are both run by David S. Miller. From there, they will go
|
||||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||||
process of net and net-next being merged into the mainline tree, see
|
process of net and net-next being merged into the mainline tree, see
|
||||||
the `netdev FAQ`_ under:
|
the :ref:`netdev-FAQ`
|
||||||
|
|
||||||
|
|
||||||
`Documentation/networking/netdev-FAQ.txt`_
|
|
||||||
|
|
||||||
Occasionally, to prevent merge conflicts, we might send pull requests
|
Occasionally, to prevent merge conflicts, we might send pull requests
|
||||||
to other trees (e.g. tracing) with a small subset of the patches, but
|
to other trees (e.g. tracing) with a small subset of the patches, but
|
||||||
|
@ -125,8 +125,8 @@ request)::
|
||||||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
||||||
---------------------------------------------------------------------------------
|
---------------------------------------------------------------------------------
|
||||||
|
|
||||||
A: The process is the very same as described in the `netdev FAQ`_, so
|
A: The process is the very same as described in the :ref:`netdev-FAQ`,
|
||||||
please read up on it. The subject line must indicate whether the
|
so please read up on it. The subject line must indicate whether the
|
||||||
patch is a fix or rather "next-like" content in order to let the
|
patch is a fix or rather "next-like" content in order to let the
|
||||||
maintainers know whether it is targeted at bpf or bpf-next.
|
maintainers know whether it is targeted at bpf or bpf-next.
|
||||||
|
|
||||||
|
@ -184,7 +184,7 @@ ii) run extensive BPF test suite and
|
||||||
Once the BPF pull request was accepted by David S. Miller, then
|
Once the BPF pull request was accepted by David S. Miller, then
|
||||||
the patches end up in net or net-next tree, respectively, and
|
the patches end up in net or net-next tree, respectively, and
|
||||||
make their way from there further into mainline. Again, see the
|
make their way from there further into mainline. Again, see the
|
||||||
`netdev FAQ`_ for additional information e.g. on how often they are
|
:ref:`netdev-FAQ` for additional information e.g. on how often they are
|
||||||
merged to mainline.
|
merged to mainline.
|
||||||
|
|
||||||
Q: How long do I need to wait for feedback on my BPF patches?
|
Q: How long do I need to wait for feedback on my BPF patches?
|
||||||
|
@ -208,7 +208,7 @@ Q: Are patches applied to bpf-next when the merge window is open?
|
||||||
-----------------------------------------------------------------
|
-----------------------------------------------------------------
|
||||||
A: For the time when the merge window is open, bpf-next will not be
|
A: For the time when the merge window is open, bpf-next will not be
|
||||||
processed. This is roughly analogous to net-next patch processing,
|
processed. This is roughly analogous to net-next patch processing,
|
||||||
so feel free to read up on the `netdev FAQ`_ about further details.
|
so feel free to read up on the :ref:`netdev-FAQ` about further details.
|
||||||
|
|
||||||
During those two weeks of merge window, we might ask you to resend
|
During those two weeks of merge window, we might ask you to resend
|
||||||
your patch series once bpf-next is open again. Once Linus released
|
your patch series once bpf-next is open again. Once Linus released
|
||||||
|
@ -372,7 +372,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
||||||
netdev@vger.kernel.org
|
netdev@vger.kernel.org
|
||||||
|
|
||||||
The process in general is the same as on netdev itself, see also the
|
The process in general is the same as on netdev itself, see also the
|
||||||
`netdev FAQ`_ document.
|
:ref:`netdev-FAQ`.
|
||||||
|
|
||||||
Q: Do you also backport to kernels not currently maintained as stable?
|
Q: Do you also backport to kernels not currently maintained as stable?
|
||||||
----------------------------------------------------------------------
|
----------------------------------------------------------------------
|
||||||
|
@ -388,9 +388,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
|
||||||
What should I do?
|
What should I do?
|
||||||
|
|
||||||
A: The same rules apply as with netdev patch submissions in general, see
|
A: The same rules apply as with netdev patch submissions in general, see
|
||||||
`netdev FAQ`_ under:
|
the :ref:`netdev-FAQ`.
|
||||||
|
|
||||||
`Documentation/networking/netdev-FAQ.txt`_
|
|
||||||
|
|
||||||
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
||||||
ask the BPF maintainers to queue the patches instead. This can be done
|
ask the BPF maintainers to queue the patches instead. This can be done
|
||||||
|
@ -630,8 +628,7 @@ when:
|
||||||
.. Links
|
.. Links
|
||||||
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
|
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
|
||||||
.. _MAINTAINERS: ../../MAINTAINERS
|
.. _MAINTAINERS: ../../MAINTAINERS
|
||||||
.. _Documentation/networking/netdev-FAQ.txt: ../networking/netdev-FAQ.txt
|
.. _netdev-FAQ: ../networking/netdev-FAQ.rst
|
||||||
.. _netdev FAQ: ../networking/netdev-FAQ.txt
|
|
||||||
.. _samples/bpf/: ../../samples/bpf/
|
.. _samples/bpf/: ../../samples/bpf/
|
||||||
.. _selftests: ../../tools/testing/selftests/bpf/
|
.. _selftests: ../../tools/testing/selftests/bpf/
|
||||||
.. _Documentation/dev-tools/kselftest.rst:
|
.. _Documentation/dev-tools/kselftest.rst:
|
||||||
|
|
|
@ -1,5 +1,5 @@
|
||||||
=================
|
=================
|
||||||
BPF documentation
|
BPF Documentation
|
||||||
=================
|
=================
|
||||||
|
|
||||||
This directory contains documentation for the BPF (Berkeley Packet
|
This directory contains documentation for the BPF (Berkeley Packet
|
||||||
|
@ -22,14 +22,14 @@ Frequently asked questions (FAQ)
|
||||||
|
|
||||||
Two sets of Questions and Answers (Q&A) are maintained.
|
Two sets of Questions and Answers (Q&A) are maintained.
|
||||||
|
|
||||||
* QA for common questions about BPF see: bpf_design_QA_
|
.. toctree::
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
* QA for developers interacting with BPF subsystem: bpf_devel_QA_
|
bpf_design_QA
|
||||||
|
bpf_devel_QA
|
||||||
|
|
||||||
|
|
||||||
.. Links:
|
.. Links:
|
||||||
.. _bpf_design_QA: bpf_design_QA.rst
|
|
||||||
.. _bpf_devel_QA: bpf_devel_QA.rst
|
|
||||||
.. _Documentation/networking/filter.txt: ../networking/filter.txt
|
.. _Documentation/networking/filter.txt: ../networking/filter.txt
|
||||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||||
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
|
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
|
|
@ -34,7 +34,7 @@ needs_sphinx = '1.3'
|
||||||
# Add any Sphinx extension module names here, as strings. They can be
|
# Add any Sphinx extension module names here, as strings. They can be
|
||||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||||
# ones.
|
# ones.
|
||||||
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure']
|
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
|
||||||
|
|
||||||
# The name of the math extension changed on Sphinx 1.4
|
# The name of the math extension changed on Sphinx 1.4
|
||||||
if major == 1 and minor > 3:
|
if major == 1 and minor > 3:
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
Console Drivers
|
Console Drivers
|
||||||
===============
|
===============
|
||||||
|
|
||||||
The linux kernel has 2 general types of console drivers. The first type is
|
The Linux kernel has 2 general types of console drivers. The first type is
|
||||||
assigned by the kernel to all the virtual consoles during the boot process.
|
assigned by the kernel to all the virtual consoles during the boot process.
|
||||||
This type will be called 'system driver', and only one system driver is allowed
|
This type will be called 'system driver', and only one system driver is allowed
|
||||||
to exist. The system driver is persistent and it can never be unloaded, though
|
to exist. The system driver is persistent and it can never be unloaded, though
|
||||||
|
@ -17,10 +17,11 @@ of driver occupying the consoles.) They can only take over the console that is
|
||||||
occupied by the system driver. In the same token, if the modular driver is
|
occupied by the system driver. In the same token, if the modular driver is
|
||||||
released by the console, the system driver will take over.
|
released by the console, the system driver will take over.
|
||||||
|
|
||||||
Modular drivers, from the programmer's point of view, has to call:
|
Modular drivers, from the programmer's point of view, have to call:
|
||||||
|
|
||||||
do_take_over_console() - load and bind driver to console layer
|
do_take_over_console() - load and bind driver to console layer
|
||||||
give_up_console() - unload driver, it will only work if driver is fully unbond
|
give_up_console() - unload driver; it will only work if driver
|
||||||
|
is fully unbound
|
||||||
|
|
||||||
In newer kernels, the following are also available:
|
In newer kernels, the following are also available:
|
||||||
|
|
||||||
|
@ -56,7 +57,7 @@ What do these files signify?
|
||||||
cat /sys/class/vtconsole/vtcon0/name
|
cat /sys/class/vtconsole/vtcon0/name
|
||||||
(S) VGA+
|
(S) VGA+
|
||||||
|
|
||||||
'(S)' stands for a (S)ystem driver, ie, it cannot be directly
|
'(S)' stands for a (S)ystem driver, i.e., it cannot be directly
|
||||||
commanded to bind or unbind
|
commanded to bind or unbind
|
||||||
|
|
||||||
'VGA+' is the name of the driver
|
'VGA+' is the name of the driver
|
||||||
|
@ -89,7 +90,7 @@ driver, make changes, recompile, reload and rebind the driver without any need
|
||||||
for rebooting the kernel. For regular users who may want to switch from
|
for rebooting the kernel. For regular users who may want to switch from
|
||||||
framebuffer console to VGA console and vice versa, this feature also makes
|
framebuffer console to VGA console and vice versa, this feature also makes
|
||||||
this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
|
this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
|
||||||
for more details).
|
for more details.)
|
||||||
|
|
||||||
Notes for developers:
|
Notes for developers:
|
||||||
=====================
|
=====================
|
||||||
|
@ -110,8 +111,8 @@ In order for binding to and unbinding from the console to properly work,
|
||||||
console drivers must follow these guidelines:
|
console drivers must follow these guidelines:
|
||||||
|
|
||||||
1. All drivers, except system drivers, must call either do_register_con_driver()
|
1. All drivers, except system drivers, must call either do_register_con_driver()
|
||||||
or do_take_over_console(). do_register_con_driver() will just add the driver to
|
or do_take_over_console(). do_register_con_driver() will just add the driver
|
||||||
the console's internal list. It won't take over the
|
to the console's internal list. It won't take over the
|
||||||
console. do_take_over_console(), as it name implies, will also take over (or
|
console. do_take_over_console(), as it name implies, will also take over (or
|
||||||
bind to) the console.
|
bind to) the console.
|
||||||
|
|
||||||
|
|
|
@ -29,7 +29,7 @@ updated by one CPU, local_t is probably more appropriate. Please see
|
||||||
local_t.
|
local_t.
|
||||||
|
|
||||||
The first operations to implement for atomic_t's are the initializers and
|
The first operations to implement for atomic_t's are the initializers and
|
||||||
plain reads. ::
|
plain writes. ::
|
||||||
|
|
||||||
#define ATOMIC_INIT(i) { (i) }
|
#define ATOMIC_INIT(i) { (i) }
|
||||||
#define atomic_set(v, i) ((v)->counter = (i))
|
#define atomic_set(v, i) ((v)->counter = (i))
|
||||||
|
|
92
Documentation/core-api/boot-time-mm.rst
Normal file
|
@ -0,0 +1,92 @@
|
||||||
|
===========================
|
||||||
|
Boot time memory management
|
||||||
|
===========================
|
||||||
|
|
||||||
|
Early system initialization cannot use "normal" memory management
|
||||||
|
simply because it is not set up yet. But there is still need to
|
||||||
|
allocate memory for various data structures, for instance for the
|
||||||
|
physical page allocator. To address this, a specialized allocator
|
||||||
|
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
|
||||||
|
introduced. Several years later PowerPC developers added a "Logical
|
||||||
|
Memory Blocks" allocator, which was later adopted by other
|
||||||
|
architectures and renamed to :ref:`memblock <memblock>`. There is also
|
||||||
|
a compatibility layer called `nobootmem` that translates bootmem
|
||||||
|
allocation interfaces to memblock calls.
|
||||||
|
|
||||||
|
The selection of the early allocator is done using
|
||||||
|
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
|
||||||
|
configuration options. These options are enabled or disabled
|
||||||
|
statically by the architectures' Kconfig files.
|
||||||
|
|
||||||
|
* Architectures that rely only on bootmem select
|
||||||
|
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
|
||||||
|
* The users of memblock with the nobootmem compatibility layer set
|
||||||
|
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
|
||||||
|
* And for those that use both memblock and bootmem the configuration
|
||||||
|
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
|
||||||
|
|
||||||
|
Whichever allocator is used, it is the responsibility of the
|
||||||
|
architecture specific initialization to set it up in
|
||||||
|
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
|
||||||
|
|
||||||
|
Once the early memory management is available it offers a variety of
|
||||||
|
functions and macros for memory allocations. The allocation request
|
||||||
|
may be directed to the first (and probably the only) node or to a
|
||||||
|
particular node in a NUMA system. There are API variants that panic
|
||||||
|
when an allocation fails and those that don't. And more recent and
|
||||||
|
advanced memblock even allows controlling its own behaviour.
|
||||||
|
|
||||||
|
.. _bootmem:
|
||||||
|
|
||||||
|
Bootmem
|
||||||
|
=======
|
||||||
|
|
||||||
|
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
|
||||||
|
Memory Manager" `book`_)
|
||||||
|
|
||||||
|
.. _book: https://www.kernel.org/doc/gorman/
|
||||||
|
|
||||||
|
.. kernel-doc:: mm/bootmem.c
|
||||||
|
:doc: bootmem overview
|
||||||
|
|
||||||
|
.. _memblock:
|
||||||
|
|
||||||
|
Memblock
|
||||||
|
========
|
||||||
|
|
||||||
|
.. kernel-doc:: mm/memblock.c
|
||||||
|
:doc: memblock overview
|
||||||
|
|
||||||
|
|
||||||
|
Functions and structures
|
||||||
|
========================
|
||||||
|
|
||||||
|
Common API
|
||||||
|
----------
|
||||||
|
|
||||||
|
The functions that are described in this section are available
|
||||||
|
regardless of what early memory manager is enabled.
|
||||||
|
|
||||||
|
.. kernel-doc:: mm/nobootmem.c
|
||||||
|
|
||||||
|
Bootmem specific API
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
|
||||||
|
|
||||||
|
.. kernel-doc:: include/linux/bootmem.h
|
||||||
|
.. kernel-doc:: mm/bootmem.c
|
||||||
|
:nodocs:
|
||||||
|
|
||||||
|
Memblock specific API
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Here is the description of memblock data structures, functions and
|
||||||
|
macros. Some of them are actually internal, but since they are
|
||||||
|
documented it would be silly to omit them. Besides, reading the
|
||||||
|
descriptions for the internal functions can help to understand what
|
||||||
|
really happens under the hood.
|
||||||
|
|
||||||
|
.. kernel-doc:: include/linux/memblock.h
|
||||||
|
.. kernel-doc:: mm/memblock.c
|
||||||
|
:nodocs:
|
|
@ -76,4 +76,6 @@ Functions and structures
|
||||||
========================
|
========================
|
||||||
|
|
||||||
.. kernel-doc:: include/linux/idr.h
|
.. kernel-doc:: include/linux/idr.h
|
||||||
|
:functions:
|
||||||
.. kernel-doc:: lib/idr.c
|
.. kernel-doc:: lib/idr.c
|
||||||
|
:functions:
|
||||||
|
|
|
@ -28,6 +28,8 @@ Core utilities
|
||||||
printk-formats
|
printk-formats
|
||||||
circular-buffers
|
circular-buffers
|
||||||
gfp_mask-from-fs-io
|
gfp_mask-from-fs-io
|
||||||
|
timekeeping
|
||||||
|
boot-time-mm
|
||||||
|
|
||||||
Interfaces for kernel debugging
|
Interfaces for kernel debugging
|
||||||
===============================
|
===============================
|
||||||
|
|
185
Documentation/core-api/timekeeping.rst
Normal file
|
@ -0,0 +1,185 @@
|
||||||
|
ktime accessors
|
||||||
|
===============
|
||||||
|
|
||||||
|
Device drivers can read the current time using ktime_get() and the many
|
||||||
|
related functions declared in linux/timekeeping.h. As a rule of thumb,
|
||||||
|
using an accessor with a shorter name is preferred over one with a longer
|
||||||
|
name if both are equally fit for a particular use case.
|
||||||
|
|
||||||
|
Basic ktime_t based interfaces
|
||||||
|
------------------------------
|
||||||
|
|
||||||
|
The recommended simplest form returns an opaque ktime_t, with variants
|
||||||
|
that return time for different clock references:
|
||||||
|
|
||||||
|
|
||||||
|
.. c:function:: ktime_t ktime_get( void )
|
||||||
|
|
||||||
|
CLOCK_MONOTONIC
|
||||||
|
|
||||||
|
Useful for reliable timestamps and measuring short time intervals
|
||||||
|
accurately. Starts at system boot time but stops during suspend.
|
||||||
|
|
||||||
|
.. c:function:: ktime_t ktime_get_boottime( void )
|
||||||
|
|
||||||
|
CLOCK_BOOTTIME
|
||||||
|
|
||||||
|
Like ktime_get(), but does not stop when suspended. This can be
|
||||||
|
used e.g. for key expiration times that need to be synchronized
|
||||||
|
with other machines across a suspend operation.
|
||||||
|
|
||||||
|
.. c:function:: ktime_t ktime_get_real( void )
|
||||||
|
|
||||||
|
CLOCK_REALTIME
|
||||||
|
|
||||||
|
Returns the time in relative to the UNIX epoch starting in 1970
|
||||||
|
using the Coordinated Universal Time (UTC), same as gettimeofday()
|
||||||
|
user space. This is used for all timestamps that need to
|
||||||
|
persist across a reboot, like inode times, but should be avoided
|
||||||
|
for internal uses, since it can jump backwards due to a leap
|
||||||
|
second update, NTP adjustment settimeofday() operation from user
|
||||||
|
space.
|
||||||
|
|
||||||
|
.. c:function:: ktime_t ktime_get_clocktai( void )
|
||||||
|
|
||||||
|
CLOCK_TAI
|
||||||
|
|
||||||
|
Like ktime_get_real(), but uses the International Atomic Time (TAI)
|
||||||
|
reference instead of UTC to avoid jumping on leap second updates.
|
||||||
|
This is rarely useful in the kernel.
|
||||||
|
|
||||||
|
.. c:function:: ktime_t ktime_get_raw( void )
|
||||||
|
|
||||||
|
CLOCK_MONOTONIC_RAW
|
||||||
|
|
||||||
|
Like ktime_get(), but runs at the same rate as the hardware
|
||||||
|
clocksource without (NTP) adjustments for clock drift. This is
|
||||||
|
also rarely needed in the kernel.
|
||||||
|
|
||||||
|
nanosecond, timespec64, and second output
|
||||||
|
-----------------------------------------
|
||||||
|
|
||||||
|
For all of the above, there are variants that return the time in a
|
||||||
|
different format depending on what is required by the user:
|
||||||
|
|
||||||
|
.. c:function:: u64 ktime_get_ns( void )
|
||||||
|
u64 ktime_get_boottime_ns( void )
|
||||||
|
u64 ktime_get_real_ns( void )
|
||||||
|
u64 ktime_get_tai_ns( void )
|
||||||
|
u64 ktime_get_raw_ns( void )
|
||||||
|
|
||||||
|
Same as the plain ktime_get functions, but returning a u64 number
|
||||||
|
of nanoseconds in the respective time reference, which may be
|
||||||
|
more convenient for some callers.
|
||||||
|
|
||||||
|
.. c:function:: void ktime_get_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_boottime_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_real_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_clocktai_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_raw_ts64( struct timespec64 * )
|
||||||
|
|
||||||
|
Same above, but returns the time in a 'struct timespec64', split
|
||||||
|
into seconds and nanoseconds. This can avoid an extra division
|
||||||
|
when printing the time, or when passing it into an external
|
||||||
|
interface that expects a 'timespec' or 'timeval' structure.
|
||||||
|
|
||||||
|
.. c:function:: time64_t ktime_get_seconds( void )
|
||||||
|
time64_t ktime_get_boottime_seconds( void )
|
||||||
|
time64_t ktime_get_real_seconds( void )
|
||||||
|
time64_t ktime_get_clocktai_seconds( void )
|
||||||
|
time64_t ktime_get_raw_seconds( void )
|
||||||
|
|
||||||
|
Return a coarse-grained version of the time as a scalar
|
||||||
|
time64_t. This avoids accessing the clock hardware and rounds
|
||||||
|
down the seconds to the full seconds of the last timer tick
|
||||||
|
using the respective reference.
|
||||||
|
|
||||||
|
Coarse and fast_ns access
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
Some additional variants exist for more specialized cases:
|
||||||
|
|
||||||
|
.. c:function:: ktime_t ktime_get_coarse_boottime( void )
|
||||||
|
ktime_t ktime_get_coarse_real( void )
|
||||||
|
ktime_t ktime_get_coarse_clocktai( void )
|
||||||
|
ktime_t ktime_get_coarse_raw( void )
|
||||||
|
|
||||||
|
.. c:function:: void ktime_get_coarse_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_coarse_boottime_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_coarse_real_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_coarse_clocktai_ts64( struct timespec64 * )
|
||||||
|
void ktime_get_coarse_raw_ts64( struct timespec64 * )
|
||||||
|
|
||||||
|
These are quicker than the non-coarse versions, but less accurate,
|
||||||
|
corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
|
||||||
|
in user space, along with the equivalent boottime/tai/raw
|
||||||
|
timebase not available in user space.
|
||||||
|
|
||||||
|
The time returned here corresponds to the last timer tick, which
|
||||||
|
may be as much as 10ms in the past (for CONFIG_HZ=100), same as
|
||||||
|
reading the 'jiffies' variable. These are only useful when called
|
||||||
|
in a fast path and one still expects better than second accuracy,
|
||||||
|
but can't easily use 'jiffies', e.g. for inode timestamps.
|
||||||
|
Skipping the hardware clock access saves around 100 CPU cycles
|
||||||
|
on most modern machines with a reliable cycle counter, but
|
||||||
|
up to several microseconds on older hardware with an external
|
||||||
|
clocksource.
|
||||||
|
|
||||||
|
.. c:function:: u64 ktime_get_mono_fast_ns( void )
|
||||||
|
u64 ktime_get_raw_fast_ns( void )
|
||||||
|
u64 ktime_get_boot_fast_ns( void )
|
||||||
|
u64 ktime_get_real_fast_ns( void )
|
||||||
|
|
||||||
|
These variants are safe to call from any context, including from
|
||||||
|
a non-maskable interrupt (NMI) during a timekeeper update, and
|
||||||
|
while we are entering suspend with the clocksource powered down.
|
||||||
|
This is useful in some tracing or debugging code as well as
|
||||||
|
machine check reporting, but most drivers should never call them,
|
||||||
|
since the time is allowed to jump under certain conditions.
|
||||||
|
|
||||||
|
Deprecated time interfaces
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
Older kernels used some other interfaces that are now being phased out
|
||||||
|
but may appear in third-party drivers being ported here. In particular,
|
||||||
|
all interfaces returning a 'struct timeval' or 'struct timespec' have
|
||||||
|
been replaced because the tv_sec member overflows in year 2038 on 32-bit
|
||||||
|
architectures. These are the recommended replacements:
|
||||||
|
|
||||||
|
.. c:function:: void ktime_get_ts( struct timespec * )
|
||||||
|
|
||||||
|
Use ktime_get() or ktime_get_ts64() instead.
|
||||||
|
|
||||||
|
.. c:function:: struct timeval do_gettimeofday( void )
|
||||||
|
struct timespec getnstimeofday( void )
|
||||||
|
struct timespec64 getnstimeofday64( void )
|
||||||
|
void ktime_get_real_ts( struct timespec * )
|
||||||
|
|
||||||
|
ktime_get_real_ts64() is a direct replacement, but consider using
|
||||||
|
monotonic time (ktime_get_ts64()) and/or a ktime_t based interface
|
||||||
|
(ktime_get()/ktime_get_real()).
|
||||||
|
|
||||||
|
.. c:function:: struct timespec current_kernel_time( void )
|
||||||
|
struct timespec64 current_kernel_time64( void )
|
||||||
|
struct timespec get_monotonic_coarse( void )
|
||||||
|
struct timespec64 get_monotonic_coarse64( void )
|
||||||
|
|
||||||
|
These are replaced by ktime_get_coarse_real_ts64() and
|
||||||
|
ktime_get_coarse_ts64(). However, A lot of code that wants
|
||||||
|
coarse-grained times can use the simple 'jiffies' instead, while
|
||||||
|
some drivers may actually want the higher resolution accessors
|
||||||
|
these days.
|
||||||
|
|
||||||
|
.. c:function:: struct timespec getrawmonotonic( void )
|
||||||
|
struct timespec64 getrawmonotonic64( void )
|
||||||
|
struct timespec timekeeping_clocktai( void )
|
||||||
|
struct timespec64 timekeeping_clocktai64( void )
|
||||||
|
struct timespec get_monotonic_boottime( void )
|
||||||
|
struct timespec64 get_monotonic_boottime64( void )
|
||||||
|
|
||||||
|
These are replaced by ktime_get_raw()/ktime_get_raw_ts64(),
|
||||||
|
ktime_get_clocktai()/ktime_get_clocktai_ts64() as well
|
||||||
|
as ktime_get_boottime()/ktime_get_boottime_ts64().
|
||||||
|
However, if the particular choice of clock source is not
|
||||||
|
important for the user, consider converting to
|
||||||
|
ktime_get()/ktime_get_ts64() instead for consistency.
|
|
@ -162,7 +162,7 @@ Code Example For Use of Operational State Memory With SHASH
|
||||||
char *hash_alg_name = "sha1-padlock-nano";
|
char *hash_alg_name = "sha1-padlock-nano";
|
||||||
int ret;
|
int ret;
|
||||||
|
|
||||||
alg = crypto_alloc_shash(hash_alg_name, CRYPTO_ALG_TYPE_SHASH, 0);
|
alg = crypto_alloc_shash(hash_alg_name, 0, 0);
|
||||||
if (IS_ERR(alg)) {
|
if (IS_ERR(alg)) {
|
||||||
pr_info("can't alloc alg %s\n", hash_alg_name);
|
pr_info("can't alloc alg %s\n", hash_alg_name);
|
||||||
return PTR_ERR(alg);
|
return PTR_ERR(alg);
|
||||||
|
|
|
@ -156,6 +156,11 @@ Contributing new tests (details)
|
||||||
installed by the distro on the system should be the primary focus to be able
|
installed by the distro on the system should be the primary focus to be able
|
||||||
to find regressions.
|
to find regressions.
|
||||||
|
|
||||||
|
* If a test needs specific kernel config options enabled, add a config file in
|
||||||
|
the test directory to enable them.
|
||||||
|
|
||||||
|
e.g: tools/testing/selftests/android/ion/config
|
||||||
|
|
||||||
Test Harness
|
Test Harness
|
||||||
============
|
============
|
||||||
|
|
||||||
|
|
|
@ -18,9 +18,6 @@ Required properties:
|
||||||
assignment of the interrupt router is required.
|
assignment of the interrupt router is required.
|
||||||
Flags get passed only when using GIC as parent. Flags
|
Flags get passed only when using GIC as parent. Flags
|
||||||
encoding as documented by the GIC bindings.
|
encoding as documented by the GIC bindings.
|
||||||
- interrupt-parent: Should be the phandle for the interrupt controller of
|
|
||||||
the CPU the device tree is intended to be used on. This
|
|
||||||
is either the node of the GIC or NVIC controller.
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
mscm_ir: interrupt-controller@40001800 {
|
mscm_ir: interrupt-controller@40001800 {
|
||||||
|
|
|
@ -2,14 +2,17 @@ Marvell Armada AP806 System Controller
|
||||||
======================================
|
======================================
|
||||||
|
|
||||||
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
||||||
SoCs. It contains a system controller, which provides a number
|
SoCs. It contains system controllers, which provide several registers
|
||||||
registers giving access to numerous features: clocks, pin-muxing and
|
giving access to numerous features: clocks, pin-muxing and many other
|
||||||
many other SoC configuration items. This DT binding allows to describe
|
SoC configuration items. This DT binding allows to describe these
|
||||||
this system controller.
|
system controllers.
|
||||||
|
|
||||||
For the top level node:
|
For the top level node:
|
||||||
- compatible: must be: "syscon", "simple-mfd";
|
- compatible: must be: "syscon", "simple-mfd";
|
||||||
- reg: register area of the AP806 system controller
|
- reg: register area of the AP806 system controller
|
||||||
|
|
||||||
|
SYSTEM CONTROLLER 0
|
||||||
|
===================
|
||||||
|
|
||||||
Clocks:
|
Clocks:
|
||||||
-------
|
-------
|
||||||
|
@ -98,3 +101,38 @@ ap_syscon: system-controller@6f4000 {
|
||||||
gpio-ranges = <&ap_pinctrl 0 0 19>;
|
gpio-ranges = <&ap_pinctrl 0 0 19>;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
SYSTEM CONTROLLER 1
|
||||||
|
===================
|
||||||
|
|
||||||
|
Thermal:
|
||||||
|
--------
|
||||||
|
|
||||||
|
For common binding part and usage, refer to
|
||||||
|
Documentation/devicetree/bindings/thermal/thermal.txt
|
||||||
|
|
||||||
|
The thermal IP can probe the temperature all around the processor. It
|
||||||
|
may feature several channels, each of them wired to one sensor.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: must be one of:
|
||||||
|
* marvell,armada-ap806-thermal
|
||||||
|
- reg: register range associated with the thermal functions.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
|
||||||
|
to this IP and represents the channel ID. There is one sensor per
|
||||||
|
channel. O refers to the thermal IP internal channel, while positive
|
||||||
|
IDs refer to each CPU.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
ap_syscon1: system-controller@6f8000 {
|
||||||
|
compatible = "syscon", "simple-mfd";
|
||||||
|
reg = <0x6f8000 0x1000>;
|
||||||
|
|
||||||
|
ap_thermal: thermal-sensor@80 {
|
||||||
|
compatible = "marvell,armada-ap806-thermal";
|
||||||
|
reg = <0x80 0x10>;
|
||||||
|
#thermal-sensor-cells = <1>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
|
@ -33,3 +33,18 @@ nb_pm: syscon@14000 {
|
||||||
compatible = "marvell,armada-3700-nb-pm", "syscon";
|
compatible = "marvell,armada-3700-nb-pm", "syscon";
|
||||||
reg = <0x14000 0x60>;
|
reg = <0x14000 0x60>;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
AVS
|
||||||
|
---
|
||||||
|
|
||||||
|
For AVS an other component is needed:
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : should contain "marvell,armada-3700-avs", "syscon";
|
||||||
|
- reg : the register start and length for the AVS
|
||||||
|
|
||||||
|
Example:
|
||||||
|
avs: avs@11500 {
|
||||||
|
compatible = "marvell,armada-3700-avs", "syscon";
|
||||||
|
reg = <0x11500 0x40>;
|
||||||
|
}
|
||||||
|
|
|
@ -1,15 +1,18 @@
|
||||||
Marvell Armada CP110 System Controller 0
|
Marvell Armada CP110 System Controller
|
||||||
========================================
|
======================================
|
||||||
|
|
||||||
The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
||||||
SoCs. It contains two sets of system control registers, System
|
SoCs. It contains system controllers, which provide several registers
|
||||||
Controller 0 and System Controller 1. This Device Tree binding allows
|
giving access to numerous features: clocks, pin-muxing and many other
|
||||||
to describe the first system controller, which provides registers to
|
SoC configuration items. This DT binding allows to describe these
|
||||||
configure various aspects of the SoC.
|
system controllers.
|
||||||
|
|
||||||
For the top level node:
|
For the top level node:
|
||||||
- compatible: must be: "syscon", "simple-mfd";
|
- compatible: must be: "syscon", "simple-mfd";
|
||||||
- reg: register area of the CP110 system controller 0
|
- reg: register area of the CP110 system controller
|
||||||
|
|
||||||
|
SYSTEM CONTROLLER 0
|
||||||
|
===================
|
||||||
|
|
||||||
Clocks:
|
Clocks:
|
||||||
-------
|
-------
|
||||||
|
@ -163,26 +166,60 @@ Required properties:
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
cpm_syscon0: system-controller@440000 {
|
CP110_LABEL(syscon0): system-controller@440000 {
|
||||||
compatible = "syscon", "simple-mfd";
|
compatible = "syscon", "simple-mfd";
|
||||||
reg = <0x440000 0x1000>;
|
reg = <0x440000 0x1000>;
|
||||||
|
|
||||||
cpm_clk: clock {
|
CP110_LABEL(clk): clock {
|
||||||
compatible = "marvell,cp110-clock";
|
compatible = "marvell,cp110-clock";
|
||||||
#clock-cells = <2>;
|
#clock-cells = <2>;
|
||||||
};
|
};
|
||||||
|
|
||||||
cpm_pinctrl: pinctrl {
|
CP110_LABEL(pinctrl): pinctrl {
|
||||||
compatible = "marvell,armada-8k-cpm-pinctrl";
|
compatible = "marvell,armada-8k-cpm-pinctrl";
|
||||||
};
|
};
|
||||||
|
|
||||||
cpm_gpio1: gpio@100 {
|
CP110_LABEL(gpio1): gpio@100 {
|
||||||
compatible = "marvell,armada-8k-gpio";
|
compatible = "marvell,armada-8k-gpio";
|
||||||
offset = <0x100>;
|
offset = <0x100>;
|
||||||
ngpios = <32>;
|
ngpios = <32>;
|
||||||
gpio-controller;
|
gpio-controller;
|
||||||
#gpio-cells = <2>;
|
#gpio-cells = <2>;
|
||||||
gpio-ranges = <&cpm_pinctrl 0 0 32>;
|
gpio-ranges = <&CP110_LABEL(pinctrl) 0 0 32>;
|
||||||
};
|
};
|
||||||
|
|
||||||
};
|
};
|
||||||
|
|
||||||
|
SYSTEM CONTROLLER 1
|
||||||
|
===================
|
||||||
|
|
||||||
|
Thermal:
|
||||||
|
--------
|
||||||
|
|
||||||
|
The thermal IP can probe the temperature all around the processor. It
|
||||||
|
may feature several channels, each of them wired to one sensor.
|
||||||
|
|
||||||
|
For common binding part and usage, refer to
|
||||||
|
Documentation/devicetree/bindings/thermal/thermal.txt
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: must be one of:
|
||||||
|
* marvell,armada-cp110-thermal
|
||||||
|
- reg: register range associated with the thermal functions.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
|
||||||
|
to this IP and represents the channel ID. There is one sensor per
|
||||||
|
channel. O refers to the thermal IP internal channel.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
CP110_LABEL(syscon1): system-controller@6f8000 {
|
||||||
|
compatible = "syscon", "simple-mfd";
|
||||||
|
reg = <0x6f8000 0x1000>;
|
||||||
|
|
||||||
|
CP110_LABEL(thermal): thermal-sensor@70 {
|
||||||
|
compatible = "marvell,armada-cp110-thermal";
|
||||||
|
reg = <0x70 0x10>;
|
||||||
|
#thermal-sensor-cells = <1>;
|
||||||
|
};
|
||||||
|
};
|
26
Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
Normal file
|
@ -0,0 +1,26 @@
|
||||||
|
== Introduction==
|
||||||
|
|
||||||
|
LLCC (Last Level Cache Controller) provides last level of cache memory in SOC,
|
||||||
|
that can be shared by multiple clients. Clients here are different cores in the
|
||||||
|
SOC, the idea is to minimize the local caches at the clients and migrate to
|
||||||
|
common pool of memory. Cache memory is divided into partitions called slices
|
||||||
|
which are assigned to clients. Clients can query the slice details, activate
|
||||||
|
and deactivate them.
|
||||||
|
|
||||||
|
Properties:
|
||||||
|
- compatible:
|
||||||
|
Usage: required
|
||||||
|
Value type: <string>
|
||||||
|
Definition: must be "qcom,sdm845-llcc"
|
||||||
|
|
||||||
|
- reg:
|
||||||
|
Usage: required
|
||||||
|
Value Type: <prop-encoded-array>
|
||||||
|
Definition: Start address and the the size of the register region.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
cache-controller@1100000 {
|
||||||
|
compatible = "qcom,sdm845-llcc";
|
||||||
|
reg = <0x1100000 0x250000>;
|
||||||
|
};
|
|
@ -10,7 +10,6 @@ Required properties:
|
||||||
- compatible : Should be "ti,irq-crossbar"
|
- compatible : Should be "ti,irq-crossbar"
|
||||||
- reg: Base address and the size of the crossbar registers.
|
- reg: Base address and the size of the crossbar registers.
|
||||||
- interrupt-controller: indicates that this block is an interrupt controller.
|
- interrupt-controller: indicates that this block is an interrupt controller.
|
||||||
- interrupt-parent: the interrupt controller this block is connected to.
|
|
||||||
- ti,max-irqs: Total number of irqs available at the parent interrupt controller.
|
- ti,max-irqs: Total number of irqs available at the parent interrupt controller.
|
||||||
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
|
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
|
||||||
- ti,reg-size: Size of a individual register in bytes. Every individual
|
- ti,reg-size: Size of a individual register in bytes. Every individual
|
||||||
|
|
|
@ -40,9 +40,6 @@ following properties:
|
||||||
- #interrupt-cells: must be identical to the that of the parent interrupt
|
- #interrupt-cells: must be identical to the that of the parent interrupt
|
||||||
controller.
|
controller.
|
||||||
|
|
||||||
- interrupt-parent: a phandle indicating which interrupt controller
|
|
||||||
this PMU signals interrupts to.
|
|
||||||
|
|
||||||
|
|
||||||
Optional nodes:
|
Optional nodes:
|
||||||
|
|
||||||
|
|
|
@ -16,7 +16,6 @@ Required properties:
|
||||||
4 for controller @ 0x1b000
|
4 for controller @ 0x1b000
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- interrupt-parent : optional, if needed for interrupt mapping
|
|
||||||
- reg : <registers mapping>
|
- reg : <registers mapping>
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
|
@ -3,8 +3,6 @@
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: "arasan,cf-spear1340"
|
- compatible: "arasan,cf-spear1340"
|
||||||
- reg: Address range of the CF registers
|
- reg: Address range of the CF registers
|
||||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
|
||||||
that services interrupts for this device
|
|
||||||
- interrupt: Should contain the CF interrupt number
|
- interrupt: Should contain the CF interrupt number
|
||||||
- clock-frequency: Interface clock rate, in Hz, one of
|
- clock-frequency: Interface clock rate, in Hz, one of
|
||||||
25000000
|
25000000
|
||||||
|
|
|
@ -29,7 +29,6 @@ Required properties:
|
||||||
- reg: should contain the address and the length of the FPGA register set.
|
- reg: should contain the address and the length of the FPGA register set.
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- interrupt-parent: should specify phandle for the interrupt controller.
|
|
||||||
- interrupts: should specify event (wakeup) IRQ.
|
- interrupts: should specify event (wakeup) IRQ.
|
||||||
|
|
||||||
Example (P1022DS):
|
Example (P1022DS):
|
||||||
|
|
|
@ -9,8 +9,6 @@ Required properties:
|
||||||
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
|
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
|
||||||
"brcm,bcm7038-gisb-arb" for 130nm chips
|
"brcm,bcm7038-gisb-arb" for 130nm chips
|
||||||
- reg: specifies the base physical address and size of the registers
|
- reg: specifies the base physical address and size of the registers
|
||||||
- interrupt-parent: specifies the phandle to the parent interrupt controller
|
|
||||||
this arbiter gets interrupt line from
|
|
||||||
- interrupts: specifies the two interrupts (timeout and TEA) to be used from
|
- interrupts: specifies the two interrupts (timeout and TEA) to be used from
|
||||||
the parent interrupt controller
|
the parent interrupt controller
|
||||||
|
|
||||||
|
|
|
@ -1,12 +1,14 @@
|
||||||
* Actions S900 Clock Management Unit (CMU)
|
* Actions Semi Owl Clock Management Unit (CMU)
|
||||||
|
|
||||||
The Actions S900 clock management unit generates and supplies clock to various
|
The Actions Semi Owl Clock Management Unit generates and supplies clock
|
||||||
controllers within the SoC. The clock binding described here is applicable to
|
to various controllers within the SoC. The clock binding described here is
|
||||||
S900 SoC.
|
applicable to S900 and S700 SoC's.
|
||||||
|
|
||||||
Required Properties:
|
Required Properties:
|
||||||
|
|
||||||
- compatible: should be "actions,s900-cmu"
|
- compatible: should be one of the following,
|
||||||
|
"actions,s900-cmu"
|
||||||
|
"actions,s700-cmu"
|
||||||
- reg: physical base address of the controller and length of memory mapped
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
region.
|
region.
|
||||||
- clocks: Reference to the parent clocks ("hosc", "losc")
|
- clocks: Reference to the parent clocks ("hosc", "losc")
|
||||||
|
@ -15,16 +17,16 @@ Required Properties:
|
||||||
Each clock is assigned an identifier, and client nodes can use this identifier
|
Each clock is assigned an identifier, and client nodes can use this identifier
|
||||||
to specify the clock which they consume.
|
to specify the clock which they consume.
|
||||||
|
|
||||||
All available clocks are defined as preprocessor macros in
|
All available clocks are defined as preprocessor macros in corresponding
|
||||||
dt-bindings/clock/actions,s900-cmu.h header and can be used in device
|
dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h header and can be
|
||||||
tree sources.
|
used in device tree sources.
|
||||||
|
|
||||||
External clocks:
|
External clocks:
|
||||||
|
|
||||||
The hosc clock used as input for the plls is generated outside the SoC. It is
|
The hosc clock used as input for the plls is generated outside the SoC. It is
|
||||||
expected that it is defined using standard clock bindings as "hosc".
|
expected that it is defined using standard clock bindings as "hosc".
|
||||||
|
|
||||||
Actions S900 CMU also requires one more clock:
|
Actions Semi S900 CMU also requires one more clock:
|
||||||
- "losc" - internal low frequency oscillator
|
- "losc" - internal low frequency oscillator
|
||||||
|
|
||||||
Example: Clock Management Unit node:
|
Example: Clock Management Unit node:
|
|
@ -0,0 +1,56 @@
|
||||||
|
* Amlogic AXG Audio Clock Controllers
|
||||||
|
|
||||||
|
The Amlogic AXG audio clock controller generates and supplies clock to the
|
||||||
|
other elements of the audio subsystem, such as fifos, i2s, spdif and pdm
|
||||||
|
devices.
|
||||||
|
|
||||||
|
Required Properties:
|
||||||
|
|
||||||
|
- compatible : should be "amlogic,axg-audio-clkc" for the A113X and A113D
|
||||||
|
- reg : physical base address of the clock controller and length of
|
||||||
|
memory mapped region.
|
||||||
|
- clocks : a list of phandle + clock-specifier pairs for the clocks listed
|
||||||
|
in clock-names.
|
||||||
|
- clock-names : must contain the following:
|
||||||
|
* "pclk" - Main peripheral bus clock
|
||||||
|
may contain the following:
|
||||||
|
* "mst_in[0-7]" - 8 input plls to generate clock signals
|
||||||
|
* "slv_sclk[0-9]" - 10 slave bit clocks provided by external
|
||||||
|
components.
|
||||||
|
* "slv_lrclk[0-9]" - 10 slave sample clocks provided by external
|
||||||
|
components.
|
||||||
|
- resets : phandle of the internal reset line
|
||||||
|
- #clock-cells : should be 1.
|
||||||
|
|
||||||
|
Each clock is assigned an identifier and client nodes can use this identifier
|
||||||
|
to specify the clock which they consume. All available clocks are defined as
|
||||||
|
preprocessor macros in the dt-bindings/clock/axg-audio-clkc.h header and can be
|
||||||
|
used in device tree sources.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
clkc_audio: clock-controller@0 {
|
||||||
|
compatible = "amlogic,axg-audio-clkc";
|
||||||
|
reg = <0x0 0x0 0x0 0xb4>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
|
||||||
|
clocks = <&clkc CLKID_AUDIO>,
|
||||||
|
<&clkc CLKID_MPLL0>,
|
||||||
|
<&clkc CLKID_MPLL1>,
|
||||||
|
<&clkc CLKID_MPLL2>,
|
||||||
|
<&clkc CLKID_MPLL3>,
|
||||||
|
<&clkc CLKID_HIFI_PLL>,
|
||||||
|
<&clkc CLKID_FCLK_DIV3>,
|
||||||
|
<&clkc CLKID_FCLK_DIV4>,
|
||||||
|
<&clkc CLKID_GP0_PLL>;
|
||||||
|
clock-names = "pclk",
|
||||||
|
"mst_in0",
|
||||||
|
"mst_in1",
|
||||||
|
"mst_in2",
|
||||||
|
"mst_in3",
|
||||||
|
"mst_in4",
|
||||||
|
"mst_in5",
|
||||||
|
"mst_in6",
|
||||||
|
"mst_in7";
|
||||||
|
resets = <&reset RESET_AUDIO>;
|
||||||
|
};
|
|
@ -91,6 +91,9 @@ Required properties:
|
||||||
at91 audio pll output on AUDIOPLLCLK that feeds the PMC
|
at91 audio pll output on AUDIOPLLCLK that feeds the PMC
|
||||||
and can be used by peripheral clock or generic clock
|
and can be used by peripheral clock or generic clock
|
||||||
|
|
||||||
|
"atmel,sama5d2-clk-i2s-mux" (under pmc node):
|
||||||
|
at91 I2S clock source selection
|
||||||
|
|
||||||
Required properties for SCKC node:
|
Required properties for SCKC node:
|
||||||
- reg : defines the IO memory reserved for the SCKC.
|
- reg : defines the IO memory reserved for the SCKC.
|
||||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||||
|
@ -180,7 +183,6 @@ For example:
|
||||||
};
|
};
|
||||||
|
|
||||||
Required properties for main clock internal RC oscillator:
|
Required properties for main clock internal RC oscillator:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- interrupts : shall be set to "<0>".
|
- interrupts : shall be set to "<0>".
|
||||||
- clock-frequency : define the internal RC oscillator frequency.
|
- clock-frequency : define the internal RC oscillator frequency.
|
||||||
|
|
||||||
|
@ -197,7 +199,6 @@ For example:
|
||||||
};
|
};
|
||||||
|
|
||||||
Required properties for main clock oscillator:
|
Required properties for main clock oscillator:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- interrupts : shall be set to "<0>".
|
- interrupts : shall be set to "<0>".
|
||||||
- #clock-cells : from common clock binding; shall be set to 0.
|
- #clock-cells : from common clock binding; shall be set to 0.
|
||||||
- clocks : shall encode the main osc source clk sources (see atmel datasheet).
|
- clocks : shall encode the main osc source clk sources (see atmel datasheet).
|
||||||
|
@ -218,7 +219,6 @@ For example:
|
||||||
};
|
};
|
||||||
|
|
||||||
Required properties for main clock:
|
Required properties for main clock:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- interrupts : shall be set to "<0>".
|
- interrupts : shall be set to "<0>".
|
||||||
- #clock-cells : from common clock binding; shall be set to 0.
|
- #clock-cells : from common clock binding; shall be set to 0.
|
||||||
- clocks : shall encode the main clk sources (see atmel datasheet).
|
- clocks : shall encode the main clk sources (see atmel datasheet).
|
||||||
|
@ -233,7 +233,6 @@ For example:
|
||||||
};
|
};
|
||||||
|
|
||||||
Required properties for master clock:
|
Required properties for master clock:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- interrupts : shall be set to "<3>".
|
- interrupts : shall be set to "<3>".
|
||||||
- #clock-cells : from common clock binding; shall be set to 0.
|
- #clock-cells : from common clock binding; shall be set to 0.
|
||||||
- clocks : shall be the master clock sources (see atmel datasheet) phandles.
|
- clocks : shall be the master clock sources (see atmel datasheet) phandles.
|
||||||
|
@ -292,7 +291,6 @@ For example:
|
||||||
|
|
||||||
|
|
||||||
Required properties for pll clocks:
|
Required properties for pll clocks:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- interrupts : shall be set to "<1>".
|
- interrupts : shall be set to "<1>".
|
||||||
- #clock-cells : from common clock binding; shall be set to 0.
|
- #clock-cells : from common clock binding; shall be set to 0.
|
||||||
- clocks : shall be the main clock phandle.
|
- clocks : shall be the main clock phandle.
|
||||||
|
@ -348,7 +346,6 @@ For example:
|
||||||
};
|
};
|
||||||
|
|
||||||
Required properties for programmable clocks:
|
Required properties for programmable clocks:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||||
- clocks : shall be the programmable clock source phandles.
|
- clocks : shall be the programmable clock source phandles.
|
||||||
|
@ -451,7 +448,6 @@ For example:
|
||||||
|
|
||||||
|
|
||||||
Required properties for utmi clock:
|
Required properties for utmi clock:
|
||||||
- interrupt-parent : must reference the PMC node.
|
|
||||||
- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>".
|
- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>".
|
||||||
- #clock-cells : from common clock binding; shall be set to 0.
|
- #clock-cells : from common clock binding; shall be set to 0.
|
||||||
- clocks : shall be the main clock source phandle.
|
- clocks : shall be the main clock source phandle.
|
||||||
|
@ -507,3 +503,35 @@ For example:
|
||||||
atmel,clk-output-range = <0 83000000>;
|
atmel,clk-output-range = <0 83000000>;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
Required properties for I2S mux clocks:
|
||||||
|
- #size-cells : shall be 0 (reg is used to encode I2S bus id).
|
||||||
|
- #address-cells : shall be 1 (reg is used to encode I2S bus id).
|
||||||
|
- name: device tree node describing a specific mux clock.
|
||||||
|
* #clock-cells : from common clock binding; shall be set to 0.
|
||||||
|
* clocks : shall be the mux clock parent phandles; shall be 2 phandles:
|
||||||
|
peripheral and generated clock; the first phandle shall belong to the
|
||||||
|
peripheral clock and the second one shall belong to the generated
|
||||||
|
clock; "clock-indices" property can be user to specify
|
||||||
|
the correct order.
|
||||||
|
* reg: I2S bus id of the corresponding mux clock.
|
||||||
|
e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
|
||||||
|
|
||||||
|
For example:
|
||||||
|
i2s_clkmux {
|
||||||
|
compatible = "atmel,sama5d2-clk-i2s-mux";
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
i2s0muxck: i2s0_muxclk {
|
||||||
|
clocks = <&i2s0_clk>, <&i2s0_gclk>;
|
||||||
|
#clock-cells = <0>;
|
||||||
|
reg = <0>;
|
||||||
|
};
|
||||||
|
|
||||||
|
i2s1muxck: i2s1_muxclk {
|
||||||
|
clocks = <&i2s1_clk>, <&i2s1_gclk>;
|
||||||
|
#clock-cells = <0>;
|
||||||
|
reg = <1>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
59
Documentation/devicetree/bindings/clock/maxim,max9485.txt
Normal file
|
@ -0,0 +1,59 @@
|
||||||
|
Devicetree bindings for Maxim MAX9485 Programmable Audio Clock Generator
|
||||||
|
|
||||||
|
This device exposes 4 clocks in total:
|
||||||
|
|
||||||
|
- MAX9485_MCLKOUT: A gated, buffered output of the input clock of 27 MHz
|
||||||
|
- MAX9485_CLKOUT: A PLL that can be configured to 16 different discrete
|
||||||
|
frequencies
|
||||||
|
- MAX9485_CLKOUT[1,2]: Two gated outputs for MAX9485_CLKOUT
|
||||||
|
|
||||||
|
MAX9485_CLKOUT[1,2] are children of MAX9485_CLKOUT which upchain all rate set
|
||||||
|
requests.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "maxim,max9485"
|
||||||
|
- clocks: Input clock, must provice 27.000 MHz
|
||||||
|
- clock-names: Must be set to "xclk"
|
||||||
|
- #clock-cells: From common clock binding; shall be set to 1
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- reset-gpios: GPIO descriptor connected to the #RESET input pin
|
||||||
|
- vdd-supply: A regulator node for Vdd
|
||||||
|
- clock-output-names: Name of output clocks, as defined in common clock
|
||||||
|
bindings
|
||||||
|
|
||||||
|
If not explicitly set, the output names are "mclkout", "clkout", "clkout1"
|
||||||
|
and "clkout2".
|
||||||
|
|
||||||
|
Clocks are defined as preprocessor macros in the dt-binding header.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
#include <dt-bindings/clock/maxim,max9485.h>
|
||||||
|
|
||||||
|
xo-27mhz: xo-27mhz {
|
||||||
|
compatible = "fixed-clock";
|
||||||
|
#clock-cells = <0>;
|
||||||
|
clock-frequency = <27000000>;
|
||||||
|
};
|
||||||
|
|
||||||
|
&i2c0 {
|
||||||
|
max9485: audio-clock@63 {
|
||||||
|
reg = <0x63>;
|
||||||
|
compatible = "maxim,max9485";
|
||||||
|
clock-names = "xclk";
|
||||||
|
clocks = <&xo-27mhz>;
|
||||||
|
reset-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
|
||||||
|
vdd-supply = <&3v3-reg>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
// Clock consumer node
|
||||||
|
|
||||||
|
foo@0 {
|
||||||
|
compatible = "bar,foo";
|
||||||
|
/* ... */
|
||||||
|
clock-names = "foo-input-clk";
|
||||||
|
clocks = <&max9485 MAX9485_CLKOUT1>;
|
||||||
|
};
|
19
Documentation/devicetree/bindings/clock/qcom,dispcc.txt
Normal file
|
@ -0,0 +1,19 @@
|
||||||
|
Qualcomm Technologies, Inc. Display Clock Controller Binding
|
||||||
|
------------------------------------------------------------
|
||||||
|
|
||||||
|
Required properties :
|
||||||
|
|
||||||
|
- compatible : shall contain "qcom,sdm845-dispcc"
|
||||||
|
- reg : shall contain base register location and length.
|
||||||
|
- #clock-cells : from common clock binding, shall contain 1.
|
||||||
|
- #reset-cells : from common reset binding, shall contain 1.
|
||||||
|
- #power-domain-cells : from generic power domain binding, shall contain 1.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
dispcc: clock-controller@af00000 {
|
||||||
|
compatible = "qcom,sdm845-dispcc";
|
||||||
|
reg = <0xaf00000 0x100000>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
#reset-cells = <1>;
|
||||||
|
#power-domain-cells = <1>;
|
||||||
|
};
|
|
@ -0,0 +1,43 @@
|
||||||
|
* Renesas R9A06G032 SYSCTRL
|
||||||
|
|
||||||
|
Required Properties:
|
||||||
|
|
||||||
|
- compatible: Must be:
|
||||||
|
- "renesas,r9a06g032-sysctrl"
|
||||||
|
- reg: Base address and length of the SYSCTRL IO block.
|
||||||
|
- #clock-cells: Must be 1
|
||||||
|
- clocks: References to the parent clocks:
|
||||||
|
- external 40mhz crystal.
|
||||||
|
- external (optional) 32.768khz
|
||||||
|
- external (optional) jtag input
|
||||||
|
- external (optional) RGMII_REFCLK
|
||||||
|
- clock-names: Must be:
|
||||||
|
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
|
||||||
|
|
||||||
|
Examples
|
||||||
|
--------
|
||||||
|
|
||||||
|
- SYSCTRL node:
|
||||||
|
|
||||||
|
sysctrl: system-controller@4000c000 {
|
||||||
|
compatible = "renesas,r9a06g032-sysctrl";
|
||||||
|
reg = <0x4000c000 0x1000>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
|
||||||
|
clocks = <&ext_mclk>, <&ext_rtc_clk>,
|
||||||
|
<&ext_jtag_clk>, <&ext_rgmii_ref>;
|
||||||
|
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
|
||||||
|
};
|
||||||
|
|
||||||
|
- Other nodes can use the clocks provided by SYSCTRL as in:
|
||||||
|
|
||||||
|
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
|
||||||
|
uart0: serial@40060000 {
|
||||||
|
compatible = "snps,dw-apb-uart";
|
||||||
|
reg = <0x40060000 0x400>;
|
||||||
|
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
reg-shift = <2>;
|
||||||
|
reg-io-width = <4>;
|
||||||
|
clocks = <&sysctrl R9A06G032_CLK_UART0>;
|
||||||
|
clock-names = "baudclk";
|
||||||
|
};
|
|
@ -0,0 +1,65 @@
|
||||||
|
* Rockchip PX30 Clock and Reset Unit
|
||||||
|
|
||||||
|
The PX30 clock controller generates and supplies clock to various
|
||||||
|
controllers within the SoC and also implements a reset controller for SoC
|
||||||
|
peripherals.
|
||||||
|
|
||||||
|
Required Properties:
|
||||||
|
|
||||||
|
- compatible: PMU for CRU should be "rockchip,px30-pmu-cru"
|
||||||
|
- compatible: CRU should be "rockchip,px30-cru"
|
||||||
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
|
region.
|
||||||
|
- #clock-cells: should be 1.
|
||||||
|
- #reset-cells: should be 1.
|
||||||
|
|
||||||
|
Optional Properties:
|
||||||
|
|
||||||
|
- rockchip,grf: phandle to the syscon managing the "general register files"
|
||||||
|
If missing, pll rates are not changeable, due to the missing pll lock status.
|
||||||
|
|
||||||
|
Each clock is assigned an identifier and client nodes can use this identifier
|
||||||
|
to specify the clock which they consume. All available clocks are defined as
|
||||||
|
preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be
|
||||||
|
used in device tree sources. Similar macros exist for the reset sources in
|
||||||
|
these files.
|
||||||
|
|
||||||
|
External clocks:
|
||||||
|
|
||||||
|
There are several clocks that are generated outside the SoC. It is expected
|
||||||
|
that they are defined using standard clock bindings with following
|
||||||
|
clock-output-names:
|
||||||
|
- "xin24m" - crystal input - required,
|
||||||
|
- "xin32k" - rtc clock - optional,
|
||||||
|
- "i2sx_clkin" - external I2S clock - optional,
|
||||||
|
- "gmac_clkin" - external GMAC clock - optional
|
||||||
|
|
||||||
|
Example: Clock controller node:
|
||||||
|
|
||||||
|
pmucru: clock-controller@ff2bc000 {
|
||||||
|
compatible = "rockchip,px30-pmucru";
|
||||||
|
reg = <0x0 0xff2bc000 0x0 0x1000>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
#reset-cells = <1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
cru: clock-controller@ff2b0000 {
|
||||||
|
compatible = "rockchip,px30-cru";
|
||||||
|
reg = <0x0 0xff2b0000 0x0 0x1000>;
|
||||||
|
rockchip,grf = <&grf>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
#reset-cells = <1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
Example: UART controller node that consumes the clock generated by the clock
|
||||||
|
controller:
|
||||||
|
|
||||||
|
uart0: serial@ff030000 {
|
||||||
|
compatible = "rockchip,px30-uart", "snps,dw-apb-uart";
|
||||||
|
reg = <0x0 0xff030000 0x0 0x100>;
|
||||||
|
interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
clocks = <&pmucru SCLK_UART0_PMU>, <&pmucru PCLK_UART0_PMU>;
|
||||||
|
clock-names = "baudclk", "apb_pclk";
|
||||||
|
reg-shift = <2>;
|
||||||
|
reg-io-width = <4>;
|
||||||
|
};
|
|
@ -6,6 +6,7 @@ Required properties :
|
||||||
- "allwinner,sun8i-a83t-de2-clk"
|
- "allwinner,sun8i-a83t-de2-clk"
|
||||||
- "allwinner,sun8i-h3-de2-clk"
|
- "allwinner,sun8i-h3-de2-clk"
|
||||||
- "allwinner,sun8i-v3s-de2-clk"
|
- "allwinner,sun8i-v3s-de2-clk"
|
||||||
|
- "allwinner,sun50i-a64-de2-clk"
|
||||||
- "allwinner,sun50i-h5-de2-clk"
|
- "allwinner,sun50i-h5-de2-clk"
|
||||||
|
|
||||||
- reg: Must contain the registers base address and length
|
- reg: Must contain the registers base address and length
|
||||||
|
|
|
@ -29,8 +29,6 @@ Required properties:
|
||||||
- reg: Specifies base physical address and size of the registers.
|
- reg: Specifies base physical address and size of the registers.
|
||||||
- interrupts: The interrupt that the AVS CPU will use to interrupt the host
|
- interrupts: The interrupt that the AVS CPU will use to interrupt the host
|
||||||
when a command completed.
|
when a command completed.
|
||||||
- interrupt-parent: The interrupt controller the above interrupt is routed
|
|
||||||
through.
|
|
||||||
- interrupt-names: The name of the interrupt used to interrupt the host.
|
- interrupt-names: The name of the interrupt used to interrupt the host.
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
|
|
|
@ -3,8 +3,6 @@
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: Should be "amd,ccp-seattle-v1a"
|
- compatible: Should be "amd,ccp-seattle-v1a"
|
||||||
- reg: Address and length of the register set for the device
|
- reg: Address and length of the register set for the device
|
||||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
|
||||||
that services interrupts for this device
|
|
||||||
- interrupts: Should contain the CCP interrupt
|
- interrupts: Should contain the CCP interrupt
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
|
|
|
@ -7,8 +7,6 @@ Required properties:
|
||||||
- interrupts: Interrupt number for the device.
|
- interrupts: Interrupt number for the device.
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- interrupt-parent: The phandle for the interrupt controller that services
|
|
||||||
interrupts for this device.
|
|
||||||
- clocks: Reference to the crypto engine clock.
|
- clocks: Reference to the crypto engine clock.
|
||||||
- dma-coherent: Present if dma operations are coherent.
|
- dma-coherent: Present if dma operations are coherent.
|
||||||
|
|
||||||
|
|
|
@ -50,11 +50,6 @@ remaining bits are reserved for future SEC EUs.
|
||||||
|
|
||||||
..and so on and so forth.
|
..and so on and so forth.
|
||||||
|
|
||||||
Optional properties:
|
|
||||||
|
|
||||||
- interrupt-parent : the phandle for the interrupt controller that
|
|
||||||
services interrupts for this device.
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
/* MPC8548E */
|
/* MPC8548E */
|
||||||
|
|
|
@ -99,13 +99,6 @@ PROPERTIES
|
||||||
of the specifier is defined by the binding document
|
of the specifier is defined by the binding document
|
||||||
describing the node's interrupt parent.
|
describing the node's interrupt parent.
|
||||||
|
|
||||||
- interrupt-parent
|
|
||||||
Usage: (required if interrupt property is defined)
|
|
||||||
Value type: <phandle>
|
|
||||||
Definition: A single <phandle> value that points
|
|
||||||
to the interrupt parent to which the child domain
|
|
||||||
is being mapped.
|
|
||||||
|
|
||||||
- clocks
|
- clocks
|
||||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||||
Value type: <prop_encoded-array>
|
Value type: <prop_encoded-array>
|
||||||
|
@ -199,13 +192,6 @@ Job Ring (JR) Node
|
||||||
of the specifier is defined by the binding document
|
of the specifier is defined by the binding document
|
||||||
describing the node's interrupt parent.
|
describing the node's interrupt parent.
|
||||||
|
|
||||||
- interrupt-parent
|
|
||||||
Usage: (required if interrupt property is defined)
|
|
||||||
Value type: <phandle>
|
|
||||||
Definition: A single <phandle> value that points
|
|
||||||
to the interrupt parent to which the child domain
|
|
||||||
is being mapped.
|
|
||||||
|
|
||||||
EXAMPLE
|
EXAMPLE
|
||||||
jr@1000 {
|
jr@1000 {
|
||||||
compatible = "fsl,sec-v4.0-job-ring";
|
compatible = "fsl,sec-v4.0-job-ring";
|
||||||
|
@ -370,13 +356,6 @@ Secure Non-Volatile Storage (SNVS) Node
|
||||||
of the specifier is defined by the binding document
|
of the specifier is defined by the binding document
|
||||||
describing the node's interrupt parent.
|
describing the node's interrupt parent.
|
||||||
|
|
||||||
- interrupt-parent
|
|
||||||
Usage: (required if interrupt property is defined)
|
|
||||||
Value type: <phandle>
|
|
||||||
Definition: A single <phandle> value that points
|
|
||||||
to the interrupt parent to which the child domain
|
|
||||||
is being mapped.
|
|
||||||
|
|
||||||
EXAMPLE
|
EXAMPLE
|
||||||
sec_mon@314000 {
|
sec_mon@314000 {
|
||||||
compatible = "fsl,sec-v4.0-mon", "syscon";
|
compatible = "fsl,sec-v4.0-mon", "syscon";
|
||||||
|
|
|
@ -0,0 +1,67 @@
|
||||||
|
* Hisilicon hip07 Security Accelerator (SEC)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: Must contain one of
|
||||||
|
- "hisilicon,hip06-sec"
|
||||||
|
- "hisilicon,hip07-sec"
|
||||||
|
- reg: Memory addresses and lengths of the memory regions through which
|
||||||
|
this device is controlled.
|
||||||
|
Region 0 has registers to control the backend processing engines.
|
||||||
|
Region 1 has registers for functionality common to all queues.
|
||||||
|
Regions 2-18 have registers for the 16 individual queues which are isolated
|
||||||
|
both in hardware and within the driver.
|
||||||
|
- interrupts: Interrupt specifiers.
|
||||||
|
Refer to interrupt-controller/interrupts.txt for generic interrupt client node
|
||||||
|
bindings.
|
||||||
|
Interrupt 0 is for the SEC unit error queue.
|
||||||
|
Interrupt 2N + 1 is the completion interrupt for queue N.
|
||||||
|
Interrupt 2N + 2 is the error interrupt for queue N.
|
||||||
|
- dma-coherent: The driver assumes coherent dma is possible.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- iommus: The SEC units are behind smmu-v3 iommus.
|
||||||
|
Refer to iommu/arm,smmu-v3.txt for more information.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
p1_sec_a: crypto@400,d2000000 {
|
||||||
|
compatible = "hisilicon,hip07-sec";
|
||||||
|
reg = <0x400 0xd0000000 0x0 0x10000
|
||||||
|
0x400 0xd2000000 0x0 0x10000
|
||||||
|
0x400 0xd2010000 0x0 0x10000
|
||||||
|
0x400 0xd2020000 0x0 0x10000
|
||||||
|
0x400 0xd2030000 0x0 0x10000
|
||||||
|
0x400 0xd2040000 0x0 0x10000
|
||||||
|
0x400 0xd2050000 0x0 0x10000
|
||||||
|
0x400 0xd2060000 0x0 0x10000
|
||||||
|
0x400 0xd2070000 0x0 0x10000
|
||||||
|
0x400 0xd2080000 0x0 0x10000
|
||||||
|
0x400 0xd2090000 0x0 0x10000
|
||||||
|
0x400 0xd20a0000 0x0 0x10000
|
||||||
|
0x400 0xd20b0000 0x0 0x10000
|
||||||
|
0x400 0xd20c0000 0x0 0x10000
|
||||||
|
0x400 0xd20d0000 0x0 0x10000
|
||||||
|
0x400 0xd20e0000 0x0 0x10000
|
||||||
|
0x400 0xd20f0000 0x0 0x10000
|
||||||
|
0x400 0xd2100000 0x0 0x10000>;
|
||||||
|
interrupt-parent = <&p1_mbigen_sec_a>;
|
||||||
|
iommus = <&p1_smmu_alg_a 0x600>;
|
||||||
|
dma-coherent;
|
||||||
|
interrupts = <576 4>,
|
||||||
|
<577 1>, <578 4>,
|
||||||
|
<579 1>, <580 4>,
|
||||||
|
<581 1>, <582 4>,
|
||||||
|
<583 1>, <584 4>,
|
||||||
|
<585 1>, <586 4>,
|
||||||
|
<587 1>, <588 4>,
|
||||||
|
<589 1>, <590 4>,
|
||||||
|
<591 1>, <592 4>,
|
||||||
|
<593 1>, <594 4>,
|
||||||
|
<595 1>, <596 4>,
|
||||||
|
<597 1>, <598 4>,
|
||||||
|
<599 1>, <600 4>,
|
||||||
|
<601 1>, <602 4>,
|
||||||
|
<603 1>, <604 4>,
|
||||||
|
<605 1>, <606 4>,
|
||||||
|
<607 1>, <608 4>;
|
||||||
|
};
|
|
@ -1,8 +1,9 @@
|
||||||
Inside Secure SafeXcel cryptographic engine
|
Inside Secure SafeXcel cryptographic engine
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: Should be "inside-secure,safexcel-eip197" or
|
- compatible: Should be "inside-secure,safexcel-eip197b",
|
||||||
"inside-secure,safexcel-eip97".
|
"inside-secure,safexcel-eip197d" or
|
||||||
|
"inside-secure,safexcel-eip97ies".
|
||||||
- reg: Base physical address of the engine and length of memory mapped region.
|
- reg: Base physical address of the engine and length of memory mapped region.
|
||||||
- interrupts: Interrupt numbers for the rings and engine.
|
- interrupts: Interrupt numbers for the rings and engine.
|
||||||
- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".
|
- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".
|
||||||
|
@ -14,10 +15,18 @@ Optional properties:
|
||||||
name must be "core" for the first clock and "reg" for
|
name must be "core" for the first clock and "reg" for
|
||||||
the second one.
|
the second one.
|
||||||
|
|
||||||
|
Backward compatibility:
|
||||||
|
Two compatibles are kept for backward compatibility, but shouldn't be used for
|
||||||
|
new submissions:
|
||||||
|
- "inside-secure,safexcel-eip197" is equivalent to
|
||||||
|
"inside-secure,safexcel-eip197b".
|
||||||
|
- "inside-secure,safexcel-eip97" is equivalent to
|
||||||
|
"inside-secure,safexcel-eip97ies".
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
crypto: crypto@800000 {
|
crypto: crypto@800000 {
|
||||||
compatible = "inside-secure,safexcel-eip197";
|
compatible = "inside-secure,safexcel-eip197b";
|
||||||
reg = <0x800000 0x200000>;
|
reg = <0x800000 0x200000>;
|
||||||
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
|
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
<GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
|
<GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
|
||||||
|
|
|
@ -7,8 +7,6 @@ Required properties:
|
||||||
- compatible : "picochip,spacc-ipsec" for the IPSEC offload engine
|
- compatible : "picochip,spacc-ipsec" for the IPSEC offload engine
|
||||||
"picochip,spacc-l2" for the femtocell layer 2 ciphering engine.
|
"picochip,spacc-l2" for the femtocell layer 2 ciphering engine.
|
||||||
- reg : Offset and length of the register set for this device
|
- reg : Offset and length of the register set for this device
|
||||||
- interrupt-parent : The interrupt controller that controls the SPAcc
|
|
||||||
interrupt.
|
|
||||||
- interrupts : The interrupt line from the SPAcc.
|
- interrupts : The interrupt line from the SPAcc.
|
||||||
- ref-clock : The input clock that drives the SPAcc.
|
- ref-clock : The input clock that drives the SPAcc.
|
||||||
|
|
||||||
|
|
|
@ -2,7 +2,9 @@ Qualcomm MSM pseudo random number generator.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
|
||||||
- compatible : should be "qcom,prng"
|
- compatible : should be "qcom,prng" for 8916 etc
|
||||||
|
: should be "qcom,prng-ee" for 8996 and later using EE
|
||||||
|
(Execution Environment) slice of prng
|
||||||
- reg : specifies base physical address and size of the registers map
|
- reg : specifies base physical address and size of the registers map
|
||||||
- clocks : phandle to clock-controller plus clock-specifier pair
|
- clocks : phandle to clock-controller plus clock-specifier pair
|
||||||
- clock-names : "core" clocks all registers, FIFO and circuits in PRNG IP block
|
- clock-names : "core" clocks all registers, FIFO and circuits in PRNG IP block
|
|
@ -1,14 +1,10 @@
|
||||||
* Rockchip rk3399 DMC(Dynamic Memory Controller) device
|
* Rockchip rk3399 DMC (Dynamic Memory Controller) device
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: Must be "rockchip,rk3399-dmc".
|
- compatible: Must be "rockchip,rk3399-dmc".
|
||||||
- devfreq-events: Node to get DDR loading, Refer to
|
- devfreq-events: Node to get DDR loading, Refer to
|
||||||
Documentation/devicetree/bindings/devfreq/
|
Documentation/devicetree/bindings/devfreq/event/
|
||||||
rockchip-dfi.txt
|
rockchip-dfi.txt
|
||||||
- interrupts: The interrupt number to the CPU. The interrupt
|
|
||||||
specifier format depends on the interrupt controller.
|
|
||||||
It should be DCF interrupts, when DDR dvfs finish,
|
|
||||||
it will happen.
|
|
||||||
- clocks: Phandles for clock specified in "clock-names" property
|
- clocks: Phandles for clock specified in "clock-names" property
|
||||||
- clock-names : The name of clock used by the DFI, must be
|
- clock-names : The name of clock used by the DFI, must be
|
||||||
"pclk_ddr_mon";
|
"pclk_ddr_mon";
|
||||||
|
@ -17,139 +13,148 @@ Required properties:
|
||||||
- center-supply: DMC supply node.
|
- center-supply: DMC supply node.
|
||||||
- status: Marks the node enabled/disabled.
|
- status: Marks the node enabled/disabled.
|
||||||
|
|
||||||
Following properties are ddr timing:
|
Optional properties:
|
||||||
|
- interrupts: The CPU interrupt number. The interrupt specifier
|
||||||
|
format depends on the interrupt controller.
|
||||||
|
It should be a DCF interrupt. When DDR DVFS finishes
|
||||||
|
a DCF interrupt is triggered.
|
||||||
|
|
||||||
- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/ddr.h,
|
Following properties relate to DDR timing:
|
||||||
it select ddr3 cl-trp-trcd type, default value
|
|
||||||
"DDR3_DEFAULT".it must selected according to
|
|
||||||
"Speed Bin" in ddr3 datasheet, DO NOT use
|
|
||||||
smaller "Speed Bin" than ddr3 exactly is.
|
|
||||||
|
|
||||||
- rockchip,pd_idle : Config the PD_IDLE value, defined the power-down
|
- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/rk3399-ddr.h,
|
||||||
idle period, memories are places into power-down
|
it selects the DDR3 cl-trp-trcd type. It must be
|
||||||
mode if bus is idle for PD_IDLE DFI clocks.
|
set according to "Speed Bin" in DDR3 datasheet,
|
||||||
|
DO NOT use a smaller "Speed Bin" than specified
|
||||||
|
for the DDR3 being used.
|
||||||
|
|
||||||
- rockchip,sr_idle : Configure the SR_IDLE value, defined the
|
- rockchip,pd_idle : Configure the PD_IDLE value. Defines the
|
||||||
selfrefresh idle period, memories are places
|
power-down idle period in which memories are
|
||||||
into self-refresh mode if bus is idle for
|
placed into power-down mode if bus is idle
|
||||||
SR_IDLE*1024 DFI clocks (DFI clocks freq is
|
for PD_IDLE DFI clock cycles.
|
||||||
half of dram's clocks), defaule value is "0".
|
|
||||||
|
|
||||||
- rockchip,sr_mc_gate_idle : Defined the self-refresh with memory and
|
- rockchip,sr_idle : Configure the SR_IDLE value. Defines the
|
||||||
controller clock gating idle period, memories
|
self-refresh idle period in which memories are
|
||||||
are places into self-refresh mode and memory
|
placed into self-refresh mode if bus is idle
|
||||||
controller clock arg gating if bus is idle for
|
for SR_IDLE * 1024 DFI clock cycles (DFI
|
||||||
sr_mc_gate_idle*1024 DFI clocks.
|
clocks freq is half of DRAM clock), default
|
||||||
|
value is "0".
|
||||||
|
|
||||||
- rockchip,srpd_lite_idle : Defined the self-refresh power down idle
|
- rockchip,sr_mc_gate_idle : Defines the memory self-refresh and controller
|
||||||
period, memories are places into self-refresh
|
clock gating idle period. Memories are placed
|
||||||
power down mode if bus is idle for
|
into self-refresh mode and memory controller
|
||||||
srpd_lite_idle*1024 DFI clocks. This parameter
|
clock arg gating started if bus is idle for
|
||||||
is for LPDDR4 only.
|
sr_mc_gate_idle*1024 DFI clock cycles.
|
||||||
|
|
||||||
- rockchip,standby_idle : Defined the standby idle period, memories are
|
- rockchip,srpd_lite_idle : Defines the self-refresh power down idle
|
||||||
places into self-refresh than controller, pi,
|
period in which memories are placed into
|
||||||
phy and dram clock will gating if bus is idle
|
self-refresh power down mode if bus is idle
|
||||||
for standby_idle * DFI clocks.
|
for srpd_lite_idle * 1024 DFI clock cycles.
|
||||||
|
This parameter is for LPDDR4 only.
|
||||||
|
|
||||||
- rockchip,dram_dll_disb_freq : It's defined the DDR3 dll bypass frequency in
|
- rockchip,standby_idle : Defines the standby idle period in which
|
||||||
MHz, when ddr freq less than DRAM_DLL_DISB_FREQ,
|
memories are placed into self-refresh mode.
|
||||||
ddr3 dll will bypssed note: if dll was bypassed,
|
The controller, pi, PHY and DRAM clock will
|
||||||
the odt also stop working.
|
be gated if bus is idle for standby_idle * DFI
|
||||||
|
clock cycles.
|
||||||
|
|
||||||
- rockchip,phy_dll_disb_freq : Defined the PHY dll bypass frequency in
|
- rockchip,dram_dll_dis_freq : Defines the DDR3 DLL bypass frequency in MHz.
|
||||||
MHz (Mega Hz), when ddr freq less than
|
When DDR frequency is less than DRAM_DLL_DISB_FREQ,
|
||||||
DRAM_DLL_DISB_FREQ, phy dll will bypssed.
|
DDR3 DLL will be bypassed. Note: if DLL was bypassed,
|
||||||
note: phy dll and phy odt are independent.
|
the odt will also stop working.
|
||||||
|
|
||||||
- rockchip,ddr3_odt_disb_freq : When dram type is DDR3, this parameter defined
|
- rockchip,phy_dll_dis_freq : Defines the PHY dll bypass frequency in
|
||||||
the odt disable frequency in MHz (Mega Hz),
|
MHz (Mega Hz). When DDR frequency is less than
|
||||||
when ddr frequency less then ddr3_odt_disb_freq,
|
DRAM_DLL_DISB_FREQ, PHY DLL will be bypassed.
|
||||||
the odt on dram side and controller side are
|
Note: PHY DLL and PHY ODT are independent.
|
||||||
|
|
||||||
|
- rockchip,ddr3_odt_dis_freq : When the DRAM type is DDR3, this parameter defines
|
||||||
|
the ODT disable frequency in MHz (Mega Hz).
|
||||||
|
when the DDR frequency is less then ddr3_odt_dis_freq,
|
||||||
|
the ODT on the DRAM side and controller side are
|
||||||
both disabled.
|
both disabled.
|
||||||
|
|
||||||
- rockchip,ddr3_drv : When dram type is DDR3, this parameter define
|
- rockchip,ddr3_drv : When the DRAM type is DDR3, this parameter defines
|
||||||
the dram side driver stength in ohm, default
|
the DRAM side driver strength in ohms. Default
|
||||||
value is DDR3_DS_40ohm.
|
value is DDR3_DS_40ohm.
|
||||||
|
|
||||||
- rockchip,ddr3_odt : When dram type is DDR3, this parameter define
|
- rockchip,ddr3_odt : When the DRAM type is DDR3, this parameter defines
|
||||||
the dram side ODT stength in ohm, default value
|
the DRAM side ODT strength in ohms. Default value
|
||||||
is DDR3_ODT_120ohm.
|
is DDR3_ODT_120ohm.
|
||||||
|
|
||||||
- rockchip,phy_ddr3_ca_drv : When dram type is DDR3, this parameter define
|
- rockchip,phy_ddr3_ca_drv : When the DRAM type is DDR3, this parameter defines
|
||||||
the phy side CA line(incluing command line,
|
the phy side CA line (incluing command line,
|
||||||
address line and clock line) driver strength.
|
address line and clock line) driver strength.
|
||||||
Default value is PHY_DRV_ODT_40.
|
Default value is PHY_DRV_ODT_40.
|
||||||
|
|
||||||
- rockchip,phy_ddr3_dq_drv : When dram type is DDR3, this parameter define
|
- rockchip,phy_ddr3_dq_drv : When the DRAM type is DDR3, this parameter defines
|
||||||
the phy side DQ line(incluing DQS/DQ/DM line)
|
the PHY side DQ line (including DQS/DQ/DM line)
|
||||||
driver strength. default value is PHY_DRV_ODT_40.
|
driver strength. Default value is PHY_DRV_ODT_40.
|
||||||
|
|
||||||
- rockchip,phy_ddr3_odt : When dram type is DDR3, this parameter define the
|
- rockchip,phy_ddr3_odt : When the DRAM type is DDR3, this parameter defines
|
||||||
phy side odt strength, default value is
|
the PHY side ODT strength. Default value is
|
||||||
PHY_DRV_ODT_240.
|
PHY_DRV_ODT_240.
|
||||||
|
|
||||||
- rockchip,lpddr3_odt_disb_freq : When dram type is LPDDR3, this parameter defined
|
- rockchip,lpddr3_odt_dis_freq : When the DRAM type is LPDDR3, this parameter defines
|
||||||
then odt disable frequency in MHz (Mega Hz),
|
then ODT disable frequency in MHz (Mega Hz).
|
||||||
when ddr frequency less then ddr3_odt_disb_freq,
|
When DDR frequency is less then ddr3_odt_dis_freq,
|
||||||
the odt on dram side and controller side are
|
the ODT on the DRAM side and controller side are
|
||||||
both disabled.
|
both disabled.
|
||||||
|
|
||||||
- rockchip,lpddr3_drv : When dram type is LPDDR3, this parameter define
|
- rockchip,lpddr3_drv : When the DRAM type is LPDDR3, this parameter defines
|
||||||
the dram side driver stength in ohm, default
|
the DRAM side driver strength in ohms. Default
|
||||||
value is LP3_DS_34ohm.
|
value is LP3_DS_34ohm.
|
||||||
|
|
||||||
- rockchip,lpddr3_odt : When dram type is LPDDR3, this parameter define
|
- rockchip,lpddr3_odt : When the DRAM type is LPDDR3, this parameter defines
|
||||||
the dram side ODT stength in ohm, default value
|
the DRAM side ODT strength in ohms. Default value
|
||||||
is LP3_ODT_240ohm.
|
is LP3_ODT_240ohm.
|
||||||
|
|
||||||
- rockchip,phy_lpddr3_ca_drv : When dram type is LPDDR3, this parameter define
|
- rockchip,phy_lpddr3_ca_drv : When the DRAM type is LPDDR3, this parameter defines
|
||||||
the phy side CA line(incluing command line,
|
the PHY side CA line (including command line,
|
||||||
address line and clock line) driver strength.
|
address line and clock line) driver strength.
|
||||||
default value is PHY_DRV_ODT_40.
|
Default value is PHY_DRV_ODT_40.
|
||||||
|
|
||||||
- rockchip,phy_lpddr3_dq_drv : When dram type is LPDDR3, this parameter define
|
- rockchip,phy_lpddr3_dq_drv : When the DRAM type is LPDDR3, this parameter defines
|
||||||
the phy side DQ line(incluing DQS/DQ/DM line)
|
the PHY side DQ line (including DQS/DQ/DM line)
|
||||||
driver strength. default value is
|
driver strength. Default value is
|
||||||
PHY_DRV_ODT_40.
|
PHY_DRV_ODT_40.
|
||||||
|
|
||||||
- rockchip,phy_lpddr3_odt : When dram type is LPDDR3, this parameter define
|
- rockchip,phy_lpddr3_odt : When dram type is LPDDR3, this parameter define
|
||||||
the phy side odt strength, default value is
|
the phy side odt strength, default value is
|
||||||
PHY_DRV_ODT_240.
|
PHY_DRV_ODT_240.
|
||||||
|
|
||||||
- rockchip,lpddr4_odt_disb_freq : When dram type is LPDDR4, this parameter
|
- rockchip,lpddr4_odt_dis_freq : When the DRAM type is LPDDR4, this parameter
|
||||||
defined the odt disable frequency in
|
defines the ODT disable frequency in
|
||||||
MHz (Mega Hz), when ddr frequency less then
|
MHz (Mega Hz). When the DDR frequency is less then
|
||||||
ddr3_odt_disb_freq, the odt on dram side and
|
ddr3_odt_dis_freq, the ODT on the DRAM side and
|
||||||
controller side are both disabled.
|
controller side are both disabled.
|
||||||
|
|
||||||
- rockchip,lpddr4_drv : When dram type is LPDDR4, this parameter define
|
- rockchip,lpddr4_drv : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the dram side driver stength in ohm, default
|
the DRAM side driver strength in ohms. Default
|
||||||
value is LP4_PDDS_60ohm.
|
value is LP4_PDDS_60ohm.
|
||||||
|
|
||||||
- rockchip,lpddr4_dq_odt : When dram type is LPDDR4, this parameter define
|
- rockchip,lpddr4_dq_odt : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the dram side ODT on dqs/dq line stength in ohm,
|
the DRAM side ODT on DQS/DQ line strength in ohms.
|
||||||
default value is LP4_DQ_ODT_40ohm.
|
Default value is LP4_DQ_ODT_40ohm.
|
||||||
|
|
||||||
- rockchip,lpddr4_ca_odt : When dram type is LPDDR4, this parameter define
|
- rockchip,lpddr4_ca_odt : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the dram side ODT on ca line stength in ohm,
|
the DRAM side ODT on CA line strength in ohms.
|
||||||
default value is LP4_CA_ODT_40ohm.
|
Default value is LP4_CA_ODT_40ohm.
|
||||||
|
|
||||||
- rockchip,phy_lpddr4_ca_drv : When dram type is LPDDR4, this parameter define
|
- rockchip,phy_lpddr4_ca_drv : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the phy side CA line(incluing command address
|
the PHY side CA line (including command address
|
||||||
line) driver strength. default value is
|
line) driver strength. Default value is
|
||||||
PHY_DRV_ODT_40.
|
PHY_DRV_ODT_40.
|
||||||
|
|
||||||
- rockchip,phy_lpddr4_ck_cs_drv : When dram type is LPDDR4, this parameter define
|
- rockchip,phy_lpddr4_ck_cs_drv : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the phy side clock line and cs line driver
|
the PHY side clock line and CS line driver
|
||||||
strength. default value is PHY_DRV_ODT_80.
|
strength. Default value is PHY_DRV_ODT_80.
|
||||||
|
|
||||||
- rockchip,phy_lpddr4_dq_drv : When dram type is LPDDR4, this parameter define
|
- rockchip,phy_lpddr4_dq_drv : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the phy side DQ line(incluing DQS/DQ/DM line)
|
the PHY side DQ line (including DQS/DQ/DM line)
|
||||||
driver strength. default value is PHY_DRV_ODT_80.
|
driver strength. Default value is PHY_DRV_ODT_80.
|
||||||
|
|
||||||
- rockchip,phy_lpddr4_odt : When dram type is LPDDR4, this parameter define
|
- rockchip,phy_lpddr4_odt : When the DRAM type is LPDDR4, this parameter defines
|
||||||
the phy side odt strength, default value is
|
the PHY side ODT strength. Default value is
|
||||||
PHY_DRV_ODT_60.
|
PHY_DRV_ODT_60.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
|
@ -74,6 +74,12 @@ Required properties for DSI:
|
||||||
The 3 clocks output from the DSI analog PHY: dsi[01]_byte,
|
The 3 clocks output from the DSI analog PHY: dsi[01]_byte,
|
||||||
dsi[01]_ddr2, and dsi[01]_ddr
|
dsi[01]_ddr2, and dsi[01]_ddr
|
||||||
|
|
||||||
|
Required properties for the TXP (writeback) block:
|
||||||
|
- compatible: Should be "brcm,bcm2835-txp"
|
||||||
|
- reg: Physical base address and length of the TXP block's registers
|
||||||
|
- interrupts: The interrupt number
|
||||||
|
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
|
||||||
|
|
||||||
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
|
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
|
@ -15,8 +15,6 @@ Required properties for dp-controller:
|
||||||
from common clock binding: handle to dp clock.
|
from common clock binding: handle to dp clock.
|
||||||
-clock-names:
|
-clock-names:
|
||||||
from common clock binding: Shall be "dp".
|
from common clock binding: Shall be "dp".
|
||||||
-interrupt-parent:
|
|
||||||
phandle to Interrupt combiner node.
|
|
||||||
-phys:
|
-phys:
|
||||||
from general PHY binding: the phandle for the PHY device.
|
from general PHY binding: the phandle for the PHY device.
|
||||||
-phy-names:
|
-phy-names:
|
||||||
|
|
|
@ -8,8 +8,6 @@ Required properties:
|
||||||
|
|
||||||
- compatible : "analogix,anx7814"
|
- compatible : "analogix,anx7814"
|
||||||
- reg : I2C address of the device
|
- reg : I2C address of the device
|
||||||
- interrupt-parent : Should be the phandle of the interrupt controller
|
|
||||||
that services interrupts for this device
|
|
||||||
- interrupts : Should contain the INTP interrupt
|
- interrupts : Should contain the INTP interrupt
|
||||||
- hpd-gpios : Which GPIO to use for hpd
|
- hpd-gpios : Which GPIO to use for hpd
|
||||||
- pd-gpios : Which GPIO to use for power down
|
- pd-gpios : Which GPIO to use for power down
|
||||||
|
|
|
@ -19,8 +19,6 @@ hardware are EDID, HPD, and interrupts.
|
||||||
stdp4028-ge-b850v3-fw required properties:
|
stdp4028-ge-b850v3-fw required properties:
|
||||||
- compatible : "megachips,stdp4028-ge-b850v3-fw"
|
- compatible : "megachips,stdp4028-ge-b850v3-fw"
|
||||||
- reg : I2C bus address
|
- reg : I2C bus address
|
||||||
- interrupt-parent : phandle of the interrupt controller that services
|
|
||||||
interrupts to the device
|
|
||||||
- interrupts : one interrupt should be described here, as in
|
- interrupts : one interrupt should be described here, as in
|
||||||
<0 IRQ_TYPE_LEVEL_HIGH>
|
<0 IRQ_TYPE_LEVEL_HIGH>
|
||||||
- ports : One input port(reg = <0>) and one output port(reg = <1>)
|
- ports : One input port(reg = <0>) and one output port(reg = <1>)
|
||||||
|
|
|
@ -5,8 +5,8 @@ Required properties:
|
||||||
- reg: i2c address of the bridge
|
- reg: i2c address of the bridge
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- interrupts-extended or interrupt-parent + interrupts: describe
|
- interrupts: describe the interrupt line used to inform the host
|
||||||
the interrupt line used to inform the host about hotplug events.
|
about hotplug events.
|
||||||
- reset-gpios: OF device-tree gpio specification for RST_N pin.
|
- reset-gpios: OF device-tree gpio specification for RST_N pin.
|
||||||
|
|
||||||
Optional subnodes:
|
Optional subnodes:
|
||||||
|
|
|
@ -7,7 +7,7 @@ Required properties:
|
||||||
- iovcc18-supply : I/O Supply Voltage (1.8V)
|
- iovcc18-supply : I/O Supply Voltage (1.8V)
|
||||||
- avcc12-supply : TMDS Analog Supply Voltage (1.2V)
|
- avcc12-supply : TMDS Analog Supply Voltage (1.2V)
|
||||||
- cvcc12-supply : Digital Core Supply Voltage (1.2V)
|
- cvcc12-supply : Digital Core Supply Voltage (1.2V)
|
||||||
- interrupts, interrupt-parent: interrupt specifier of INT pin
|
- interrupts: interrupt specifier of INT pin
|
||||||
- reset-gpios: gpio specifier of RESET pin (active low)
|
- reset-gpios: gpio specifier of RESET pin (active low)
|
||||||
- video interfaces: Device node can contain two video interface port
|
- video interfaces: Device node can contain two video interface port
|
||||||
nodes for HDMI encoder and connector according to [1].
|
nodes for HDMI encoder and connector according to [1].
|
||||||
|
|
|
@ -5,7 +5,7 @@ Required properties:
|
||||||
- reg: i2c address of the bridge
|
- reg: i2c address of the bridge
|
||||||
- cvcc10-supply: Digital Core Supply Voltage (1.0V)
|
- cvcc10-supply: Digital Core Supply Voltage (1.0V)
|
||||||
- iovcc18-supply: I/O Supply Voltage (1.8V)
|
- iovcc18-supply: I/O Supply Voltage (1.8V)
|
||||||
- interrupts, interrupt-parent: interrupt specifier of INT pin
|
- interrupts: interrupt specifier of INT pin
|
||||||
- reset-gpios: gpio specifier of RESET pin
|
- reset-gpios: gpio specifier of RESET pin
|
||||||
- clocks, clock-names: specification and name of "xtal" clock
|
- clocks, clock-names: specification and name of "xtal" clock
|
||||||
- video interfaces: Device node can contain video interface port
|
- video interfaces: Device node can contain video interface port
|
||||||
|
|
|
@ -9,9 +9,6 @@ Required properties:
|
||||||
|
|
||||||
- reg: physical base address and length of the DECON registers set.
|
- reg: physical base address and length of the DECON registers set.
|
||||||
|
|
||||||
- interrupt-parent: should be the phandle of the decon controller's
|
|
||||||
parent interrupt controller.
|
|
||||||
|
|
||||||
- interrupts: should contain a list of all DECON IP block interrupts in the
|
- interrupts: should contain a list of all DECON IP block interrupts in the
|
||||||
order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
|
order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
|
||||||
format depends on the interrupt controller used.
|
format depends on the interrupt controller used.
|
||||||
|
|
|
@ -25,8 +25,6 @@ Required properties for dp-controller:
|
||||||
from common clock binding: handle to dp clock.
|
from common clock binding: handle to dp clock.
|
||||||
-clock-names:
|
-clock-names:
|
||||||
from common clock binding: Shall be "dp".
|
from common clock binding: Shall be "dp".
|
||||||
-interrupt-parent:
|
|
||||||
phandle to Interrupt combiner node.
|
|
||||||
-phys:
|
-phys:
|
||||||
from general PHY binding: the phandle for the PHY device.
|
from general PHY binding: the phandle for the PHY device.
|
||||||
-phy-names:
|
-phy-names:
|
||||||
|
|
|
@ -16,9 +16,6 @@ Required properties:
|
||||||
|
|
||||||
- reg: physical base address and length of the FIMD registers set.
|
- reg: physical base address and length of the FIMD registers set.
|
||||||
|
|
||||||
- interrupt-parent: should be the phandle of the fimd controller's
|
|
||||||
parent interrupt controller.
|
|
||||||
|
|
||||||
- interrupts: should contain a list of all FIMD IP block interrupts in the
|
- interrupts: should contain a list of all FIMD IP block interrupts in the
|
||||||
order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
|
order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
|
||||||
format depends on the interrupt controller used.
|
format depends on the interrupt controller used.
|
||||||
|
|
|
@ -4,8 +4,6 @@ Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: "holtek,ht16k33"
|
- compatible: "holtek,ht16k33"
|
||||||
- reg: I2C slave address of the chip.
|
- reg: I2C slave address of the chip.
|
||||||
- interrupt-parent: A phandle pointing to the interrupt controller
|
|
||||||
serving the interrupt for this chip.
|
|
||||||
- interrupts: Interrupt specification for the key pressed interrupt.
|
- interrupts: Interrupt specification for the key pressed interrupt.
|
||||||
- refresh-rate-hz: Display update interval in HZ.
|
- refresh-rate-hz: Display update interval in HZ.
|
||||||
- debounce-delay-ms: Debouncing interval time in milliseconds.
|
- debounce-delay-ms: Debouncing interval time in milliseconds.
|
||||||
|
|
27
Documentation/devicetree/bindings/display/ilitek,ili9341.txt
Normal file
|
@ -0,0 +1,27 @@
|
||||||
|
Ilitek ILI9341 display panels
|
||||||
|
|
||||||
|
This binding is for display panels using an Ilitek ILI9341 controller in SPI
|
||||||
|
mode.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "adafruit,yx240qv29", "ilitek,ili9341"
|
||||||
|
- dc-gpios: D/C pin
|
||||||
|
- reset-gpios: Reset pin
|
||||||
|
|
||||||
|
The node for this driver must be a child node of a SPI controller, hence
|
||||||
|
all mandatory properties described in ../spi/spi-bus.txt must be specified.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
|
||||||
|
- backlight: phandle of the backlight device attached to the panel
|
||||||
|
|
||||||
|
Example:
|
||||||
|
display@0{
|
||||||
|
compatible = "adafruit,yx240qv29", "ilitek,ili9341";
|
||||||
|
reg = <0>;
|
||||||
|
spi-max-frequency = <32000000>;
|
||||||
|
dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
|
||||||
|
reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
|
||||||
|
rotation = <270>;
|
||||||
|
backlight = <&backlight>;
|
||||||
|
};
|
|
@ -40,7 +40,7 @@ Required properties (all function blocks):
|
||||||
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
|
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
|
||||||
"mediatek,<chip>-disp-mutex" - display mutex
|
"mediatek,<chip>-disp-mutex" - display mutex
|
||||||
"mediatek,<chip>-disp-od" - overdrive
|
"mediatek,<chip>-disp-od" - overdrive
|
||||||
the supported chips are mt2701 and mt8173.
|
the supported chips are mt2701, mt2712 and mt8173.
|
||||||
- reg: Physical base address and length of the function block register space
|
- reg: Physical base address and length of the function block register space
|
||||||
- interrupts: The interrupt signal from the function block (required, except for
|
- interrupts: The interrupt signal from the function block (required, except for
|
||||||
merge and split function blocks).
|
merge and split function blocks).
|
||||||
|
|
131
Documentation/devicetree/bindings/display/msm/dpu.txt
Normal file
|
@ -0,0 +1,131 @@
|
||||||
|
Qualcomm Technologies, Inc. DPU KMS
|
||||||
|
|
||||||
|
Description:
|
||||||
|
|
||||||
|
Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates
|
||||||
|
sub-blocks like DPU display controller, DSI and DP interfaces etc.
|
||||||
|
The DPU display controller is found in SDM845 SoC.
|
||||||
|
|
||||||
|
MDSS:
|
||||||
|
Required properties:
|
||||||
|
- compatible: "qcom,sdm845-mdss"
|
||||||
|
- reg: physical base address and length of contoller's registers.
|
||||||
|
- reg-names: register region names. The following region is required:
|
||||||
|
* "mdss"
|
||||||
|
- power-domains: a power domain consumer specifier according to
|
||||||
|
Documentation/devicetree/bindings/power/power_domain.txt
|
||||||
|
- clocks: list of clock specifiers for clocks needed by the device.
|
||||||
|
- clock-names: device clock names, must be in same order as clocks property.
|
||||||
|
The following clocks are required:
|
||||||
|
* "iface"
|
||||||
|
* "bus"
|
||||||
|
* "core"
|
||||||
|
- interrupts: interrupt signal from MDSS.
|
||||||
|
- interrupt-controller: identifies the node as an interrupt controller.
|
||||||
|
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
|
||||||
|
source, should be 1.
|
||||||
|
- iommus: phandle of iommu device node.
|
||||||
|
- #address-cells: number of address cells for the MDSS children. Should be 1.
|
||||||
|
- #size-cells: Should be 1.
|
||||||
|
- ranges: parent bus address space is the same as the child bus address space.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- assigned-clocks: list of clock specifiers for clocks needing rate assignment
|
||||||
|
- assigned-clock-rates: list of clock frequencies sorted in the same order as
|
||||||
|
the assigned-clocks property.
|
||||||
|
|
||||||
|
MDP:
|
||||||
|
Required properties:
|
||||||
|
- compatible: "qcom,sdm845-dpu"
|
||||||
|
- reg: physical base address and length of controller's registers.
|
||||||
|
- reg-names : register region names. The following region is required:
|
||||||
|
* "mdp"
|
||||||
|
* "vbif"
|
||||||
|
- clocks: list of clock specifiers for clocks needed by the device.
|
||||||
|
- clock-names: device clock names, must be in same order as clocks property.
|
||||||
|
The following clocks are required.
|
||||||
|
* "bus"
|
||||||
|
* "iface"
|
||||||
|
* "core"
|
||||||
|
* "vsync"
|
||||||
|
- interrupts: interrupt line from DPU to MDSS.
|
||||||
|
- ports: contains the list of output ports from DPU device. These ports connect
|
||||||
|
to interfaces that are external to the DPU hardware, such as DSI, DP etc.
|
||||||
|
|
||||||
|
Each output port contains an endpoint that describes how it is connected to an
|
||||||
|
external interface. These are described by the standard properties documented
|
||||||
|
here:
|
||||||
|
Documentation/devicetree/bindings/graph.txt
|
||||||
|
Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||||
|
|
||||||
|
Port 0 -> DPU_INTF1 (DSI1)
|
||||||
|
Port 1 -> DPU_INTF2 (DSI2)
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- assigned-clocks: list of clock specifiers for clocks needing rate assignment
|
||||||
|
- assigned-clock-rates: list of clock frequencies sorted in the same order as
|
||||||
|
the assigned-clocks property.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
mdss: mdss@ae00000 {
|
||||||
|
compatible = "qcom,sdm845-mdss";
|
||||||
|
reg = <0xae00000 0x1000>;
|
||||||
|
reg-names = "mdss";
|
||||||
|
|
||||||
|
power-domains = <&clock_dispcc 0>;
|
||||||
|
|
||||||
|
clocks = <&gcc GCC_DISP_AHB_CLK>, <&gcc GCC_DISP_AXI_CLK>,
|
||||||
|
<&clock_dispcc DISP_CC_MDSS_MDP_CLK>;
|
||||||
|
clock-names = "iface", "bus", "core";
|
||||||
|
|
||||||
|
assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>;
|
||||||
|
assigned-clock-rates = <300000000>;
|
||||||
|
|
||||||
|
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
interrupt-controller;
|
||||||
|
#interrupt-cells = <1>;
|
||||||
|
|
||||||
|
iommus = <&apps_iommu 0>;
|
||||||
|
|
||||||
|
#address-cells = <2>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
ranges = <0 0 0xae00000 0xb2008>;
|
||||||
|
|
||||||
|
mdss_mdp: mdp@ae01000 {
|
||||||
|
compatible = "qcom,sdm845-dpu";
|
||||||
|
reg = <0 0x1000 0x8f000>, <0 0xb0000 0x2008>;
|
||||||
|
reg-names = "mdp", "vbif";
|
||||||
|
|
||||||
|
clocks = <&clock_dispcc DISP_CC_MDSS_AHB_CLK>,
|
||||||
|
<&clock_dispcc DISP_CC_MDSS_AXI_CLK>,
|
||||||
|
<&clock_dispcc DISP_CC_MDSS_MDP_CLK>,
|
||||||
|
<&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>;
|
||||||
|
clock-names = "iface", "bus", "core", "vsync";
|
||||||
|
|
||||||
|
assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>,
|
||||||
|
<&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>;
|
||||||
|
assigned-clock-rates = <0 0 300000000 19200000>;
|
||||||
|
|
||||||
|
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
|
||||||
|
|
||||||
|
ports {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
port@0 {
|
||||||
|
reg = <0>;
|
||||||
|
dpu_intf1_out: endpoint {
|
||||||
|
remote-endpoint = <&dsi0_in>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
port@1 {
|
||||||
|
reg = <1>;
|
||||||
|
dpu_intf2_out: endpoint {
|
||||||
|
remote-endpoint = <&dsi1_in>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
|
@ -43,8 +43,6 @@ Optional properties:
|
||||||
the master link of the 2-DSI panel.
|
the master link of the 2-DSI panel.
|
||||||
- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is
|
- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is
|
||||||
driving a 2-DSI panel whose 2 links need receive command simultaneously.
|
driving a 2-DSI panel whose 2 links need receive command simultaneously.
|
||||||
- interrupt-parent: phandle to the MDP block if the interrupt signal is routed
|
|
||||||
through MDP block
|
|
||||||
- pinctrl-names: the pin control state names; should contain "default"
|
- pinctrl-names: the pin control state names; should contain "default"
|
||||||
- pinctrl-0: the default pinctrl state (active)
|
- pinctrl-0: the default pinctrl state (active)
|
||||||
- pinctrl-n: the "sleep" pinctrl state
|
- pinctrl-n: the "sleep" pinctrl state
|
||||||
|
@ -121,6 +119,20 @@ Required properties:
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
|
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
|
||||||
regulator is wanted.
|
regulator is wanted.
|
||||||
|
- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode
|
||||||
|
panels in microseconds. Driver uses this number to adjust
|
||||||
|
the clock rate according to the expected transfer time.
|
||||||
|
Increasing this value would slow down the mdp processing
|
||||||
|
and can result in slower performance.
|
||||||
|
Decreasing this value can speed up the mdp processing,
|
||||||
|
but this can also impact power consumption.
|
||||||
|
As a rule this time should not be higher than the time
|
||||||
|
that would be expected with the processing at the
|
||||||
|
dsi link rate since anyways this would be the maximum
|
||||||
|
transfer time that could be achieved.
|
||||||
|
If ping pong split is enabled, this time should not be higher
|
||||||
|
than two times the dsi link rate time.
|
||||||
|
If the property is not specified, then the default value is 14000 us.
|
||||||
|
|
||||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
[2] Documentation/devicetree/bindings/graph.txt
|
[2] Documentation/devicetree/bindings/graph.txt
|
||||||
|
@ -171,6 +183,8 @@ Example:
|
||||||
qcom,master-dsi;
|
qcom,master-dsi;
|
||||||
qcom,sync-dual-dsi;
|
qcom,sync-dual-dsi;
|
||||||
|
|
||||||
|
qcom,mdss-mdp-transfer-time-us = <12000>;
|
||||||
|
|
||||||
pinctrl-names = "default", "sleep";
|
pinctrl-names = "default", "sleep";
|
||||||
pinctrl-0 = <&dsi_active>;
|
pinctrl-0 = <&dsi_active>;
|
||||||
pinctrl-1 = <&dsi_suspend>;
|
pinctrl-1 = <&dsi_suspend>;
|
||||||
|
|
|
@ -25,10 +25,6 @@ Required properties:
|
||||||
- panel-hpd-gpios: GPIO pin used for eDP hpd.
|
- panel-hpd-gpios: GPIO pin used for eDP hpd.
|
||||||
|
|
||||||
|
|
||||||
Optional properties:
|
|
||||||
- interrupt-parent: phandle to the MDP block if the interrupt signal is routed
|
|
||||||
through MDP block
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
mdss_edp: qcom,mdss_edp@fd923400 {
|
mdss_edp: qcom,mdss_edp@fd923400 {
|
||||||
compatible = "qcom,mdss-edp";
|
compatible = "qcom,mdss-edp";
|
||||||
|
|
|
@ -41,8 +41,6 @@ Required properties:
|
||||||
- reg-names: The names of register regions. The following regions are required:
|
- reg-names: The names of register regions. The following regions are required:
|
||||||
* "mdp_phys"
|
* "mdp_phys"
|
||||||
- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
|
- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
|
||||||
- interrupt-parent: phandle to the MDSS block
|
|
||||||
through MDP block
|
|
||||||
- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
|
- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
|
||||||
- clock-names: the following clocks are required.
|
- clock-names: the following clocks are required.
|
||||||
- * "bus"
|
- * "bus"
|
||||||
|
|
|
@ -0,0 +1,29 @@
|
||||||
|
AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "auo,g070vvn01"
|
||||||
|
- backlight: phandle of the backlight device attached to the panel
|
||||||
|
- power-supply: single regulator to provide the supply voltage
|
||||||
|
|
||||||
|
Required nodes:
|
||||||
|
- port: Parallel port mapping to connect this display
|
||||||
|
|
||||||
|
This panel needs single power supply voltage. Its backlight is conntrolled
|
||||||
|
via PWM signal.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
--------
|
||||||
|
|
||||||
|
Example device-tree definition when connected to iMX6Q based board
|
||||||
|
|
||||||
|
lcd_panel: lcd-panel {
|
||||||
|
compatible = "auo,g070vvn01";
|
||||||
|
backlight = <&backlight_lcd>;
|
||||||
|
power-supply = <®_display>;
|
||||||
|
|
||||||
|
port {
|
||||||
|
lcd_panel_in: endpoint {
|
||||||
|
remote-endpoint = <&lcd_display_out>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
|
@ -0,0 +1,28 @@
|
||||||
|
BOE HV070WSA-100 7.01" WSVGA TFT LCD panel
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "boe,hv070wsa-100"
|
||||||
|
- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
|
||||||
|
- enable-gpios: GPIO pin to enable and disable panel (active high)
|
||||||
|
|
||||||
|
This binding is compatible with the simple-panel binding, which is specified
|
||||||
|
in simple-panel.txt in this directory.
|
||||||
|
|
||||||
|
The device node can contain one 'port' child node with one child
|
||||||
|
'endpoint' node, according to the bindings defined in [1]. This
|
||||||
|
node should describe panel's video bus.
|
||||||
|
|
||||||
|
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
panel: panel {
|
||||||
|
compatible = "boe,hv070wsa-100";
|
||||||
|
power-supply = <&vcc_3v3_reg>;
|
||||||
|
enable-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
|
||||||
|
port {
|
||||||
|
panel_ep: endpoint {
|
||||||
|
remote-endpoint = <&bridge_out_ep>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
|
@ -0,0 +1,8 @@
|
||||||
|
DataImage, Inc. 7" WVGA (800x480) TFT LCD panel with 24-bit parallel interface.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "dataimage,scf0700c48ggu18"
|
||||||
|
- power-supply: as specified in the base binding
|
||||||
|
|
||||||
|
This binding is compatible with the simple-panel binding, which is specified
|
||||||
|
in simple-panel.txt in this directory.
|
|
@ -0,0 +1,13 @@
|
||||||
|
DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "dlc,dlc0700yzg-1"
|
||||||
|
- power-supply: See simple-panel.txt
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- reset-gpios: See panel-common.txt
|
||||||
|
- enable-gpios: See simple-panel.txt
|
||||||
|
- backlight: See simple-panel.txt
|
||||||
|
|
||||||
|
This binding is compatible with the simple-panel binding, which is specified
|
||||||
|
in simple-panel.txt in this directory.
|
|
@ -0,0 +1,39 @@
|
||||||
|
Emerging Display Technology Corp. Displays
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
|
||||||
|
Display bindings for EDT Display Technology Corp. Displays which are
|
||||||
|
compatible with the simple-panel binding, which is specified in
|
||||||
|
simple-panel.txt
|
||||||
|
|
||||||
|
|
||||||
|
5,7" WVGA TFT Panels
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
| Identifier | compatbile | description |
|
||||||
|
+=================+=====================+=====================================+
|
||||||
|
| ET057090DHU | edt,et057090dhu | 5.7" VGA TFT LCD panel |
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
|
||||||
|
|
||||||
|
7,0" WVGA TFT Panels
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
| Identifier | compatbile | description |
|
||||||
|
+=================+=====================+=====================================+
|
||||||
|
| ETM0700G0DH6 | edt,etm070080dh6 | WVGA TFT Display with capacitive |
|
||||||
|
| | | Touchscreen |
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
| ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with |
|
||||||
|
| | | inverted pixel clock. |
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
| ETM0700G0EDH6 | edt,etm070080edh6 | Same display as the ETM0700G0BDH6, |
|
||||||
|
| | | but with changed Hardware for the |
|
||||||
|
| | | backlight and the touch interface |
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
| ET070080DH6 | edt,etm070080dh6 | Same timings as the ETM0700G0DH6, |
|
||||||
|
| | | but with resistive touch. |
|
||||||
|
+-----------------+---------------------+-------------------------------------+
|
||||||
|
|
|
@ -1,10 +0,0 @@
|
||||||
Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel
|
|
||||||
|
|
||||||
Required properties:
|
|
||||||
- compatible: should be "edt,et070080dh6"
|
|
||||||
|
|
||||||
This panel is the same as ETM0700G0DH6 except for the touchscreen.
|
|
||||||
ET070080DH6 is the model with resistive touch.
|
|
||||||
|
|
||||||
This binding is compatible with the simple-panel binding, which is specified
|
|
||||||
in simple-panel.txt in this directory.
|
|
|
@ -1,10 +0,0 @@
|
||||||
Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel
|
|
||||||
|
|
||||||
Required properties:
|
|
||||||
- compatible: should be "edt,etm0700g0dh6"
|
|
||||||
|
|
||||||
This panel is the same as ET070080DH6 except for the touchscreen.
|
|
||||||
ETM0700G0DH6 is the model with capacitive multitouch.
|
|
||||||
|
|
||||||
This binding is compatible with the simple-panel binding, which is specified
|
|
||||||
in simple-panel.txt in this directory.
|
|
|
@ -0,0 +1,20 @@
|
||||||
|
Ilitek ILI9881c based MIPI-DSI panels
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: must be "ilitek,ili9881c" and one of:
|
||||||
|
* "bananapi,lhr050h41"
|
||||||
|
- reg: DSI virtual channel used by that screen
|
||||||
|
- power-supply: phandle to the power regulator
|
||||||
|
- reset-gpios: a GPIO phandle for the reset pin
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- backlight: phandle to the backlight used
|
||||||
|
|
||||||
|
Example:
|
||||||
|
panel@0 {
|
||||||
|
compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
|
||||||
|
reg = <0>;
|
||||||
|
power-supply = <®_display>;
|
||||||
|
reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
|
||||||
|
backlight = <&pwm_bl>;
|
||||||
|
};
|
|
@ -0,0 +1,12 @@
|
||||||
|
Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "innolux,g070y2-l01"
|
||||||
|
- power-supply: as specified in the base binding
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- backlight: as specified in the base binding
|
||||||
|
- enable-gpios: as specified in the base binding
|
||||||
|
|
||||||
|
This binding is compatible with the simple-panel binding, which is specified
|
||||||
|
in simple-panel.txt in this directory.
|
|
@ -0,0 +1,24 @@
|
||||||
|
Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be "innolux,p097pfg"
|
||||||
|
- reg: DSI virtual channel of the peripheral
|
||||||
|
- avdd-supply: phandle of the regulator that provides positive voltage
|
||||||
|
- avee-supply: phandle of the regulator that provides negative voltage
|
||||||
|
- enable-gpios: panel enable gpio
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- backlight: phandle of the backlight device attached to the panel
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
&mipi_dsi {
|
||||||
|
panel {
|
||||||
|
compatible = "innolux,p079zca";
|
||||||
|
reg = <0>;
|
||||||
|
avdd-supply = <...>;
|
||||||
|
avee-supply = <...>;
|
||||||
|
backlight = <&backlight>;
|
||||||
|
enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
|
||||||
|
};
|
||||||
|
};
|