mirror of
https://github.com/Dasharo/linux.git
synced 2026-03-06 15:25:10 -08:00
Merge remote-tracking branch 'torvalds/master' into perf/core
To pick up fixes. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
Arnaldo Carvalho de Melo
24
CREDITS
24
CREDITS
@@ -710,6 +710,10 @@ S: Las Cuevas 2385 - Bo Guemes
|
||||
S: Las Heras, Mendoza CP 5539
|
||||
S: Argentina
|
||||
|
||||
N: Jay Cliburn
|
||||
E: jcliburn@gmail.com
|
||||
D: ATLX Ethernet drivers
|
||||
|
||||
N: Steven P. Cole
|
||||
E: scole@lanl.gov
|
||||
E: elenstev@mesatop.com
|
||||
@@ -1284,6 +1288,10 @@ D: Major kbuild rework during the 2.5 cycle
|
||||
D: ISDN Maintainer
|
||||
S: USA
|
||||
|
||||
N: Gerrit Renker
|
||||
E: gerrit@erg.abdn.ac.uk
|
||||
D: DCCP protocol support.
|
||||
|
||||
N: Philip Gladstone
|
||||
E: philip@gladstonefamily.net
|
||||
D: Kernel / timekeeping stuff
|
||||
@@ -2138,6 +2146,10 @@ E: seasons@falcon.sch.bme.hu
|
||||
E: seasons@makosteszta.sote.hu
|
||||
D: Original author of software suspend
|
||||
|
||||
N: Alexey Kuznetsov
|
||||
E: kuznet@ms2.inr.ac.ru
|
||||
D: Author and maintainer of large parts of the networking stack
|
||||
|
||||
N: Jaroslav Kysela
|
||||
E: perex@perex.cz
|
||||
W: https://www.perex.cz
|
||||
@@ -2696,6 +2708,10 @@ N: Wolfgang Muees
|
||||
E: wolfgang@iksw-muees.de
|
||||
D: Auerswald USB driver
|
||||
|
||||
N: Shrijeet Mukherjee
|
||||
E: shrijeet@gmail.com
|
||||
D: Network routing domains (VRF).
|
||||
|
||||
N: Paul Mundt
|
||||
E: paul.mundt@gmail.com
|
||||
D: SuperH maintainer
|
||||
@@ -4110,6 +4126,10 @@ S: B-1206 Jingmao Guojigongyu
|
||||
S: 16 Baliqiao Nanjie, Beijing 101100
|
||||
S: People's Repulic of China
|
||||
|
||||
N: Aviad Yehezkel
|
||||
E: aviadye@nvidia.com
|
||||
D: Kernel TLS implementation and offload support.
|
||||
|
||||
N: Victor Yodaiken
|
||||
E: yodaiken@fsmlabs.com
|
||||
D: RTLinux (RealTime Linux)
|
||||
@@ -4167,6 +4187,10 @@ S: 1507 145th Place SE #B5
|
||||
S: Bellevue, Washington 98007
|
||||
S: USA
|
||||
|
||||
N: Wensong Zhang
|
||||
E: wensong@linux-vs.org
|
||||
D: IP virtual server (IPVS).
|
||||
|
||||
N: Haojian Zhuang
|
||||
E: haojian.zhuang@gmail.com
|
||||
D: MMP support
|
||||
|
||||
@@ -473,7 +473,7 @@ read-side critical sections that follow the idle period (the oval near
|
||||
the bottom of the diagram above).
|
||||
|
||||
Plumbing this into the full grace-period execution is described
|
||||
`below <#Forcing%20Quiescent%20States>`__.
|
||||
`below <Forcing Quiescent States_>`__.
|
||||
|
||||
CPU-Hotplug Interface
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -494,7 +494,7 @@ mask to detect CPUs having gone offline since the beginning of this
|
||||
grace period.
|
||||
|
||||
Plumbing this into the full grace-period execution is described
|
||||
`below <#Forcing%20Quiescent%20States>`__.
|
||||
`below <Forcing Quiescent States_>`__.
|
||||
|
||||
Forcing Quiescent States
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -532,7 +532,7 @@ from other CPUs.
|
||||
| RCU. But this diagram is complex enough as it is, so simplicity |
|
||||
| overrode accuracy. You can think of it as poetic license, or you can |
|
||||
| think of it as misdirection that is resolved in the |
|
||||
| `stitched-together diagram <#Putting%20It%20All%20Together>`__. |
|
||||
| `stitched-together diagram <Putting It All Together_>`__. |
|
||||
+-----------------------------------------------------------------------+
|
||||
|
||||
Grace-Period Cleanup
|
||||
@@ -596,7 +596,7 @@ maintain ordering. For example, if the callback function wakes up a task
|
||||
that runs on some other CPU, proper ordering must in place in both the
|
||||
callback function and the task being awakened. To see why this is
|
||||
important, consider the top half of the `grace-period
|
||||
cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be
|
||||
cleanup`_ diagram. The callback might be
|
||||
running on a CPU corresponding to the leftmost leaf ``rcu_node``
|
||||
structure, and awaken a task that is to run on a CPU corresponding to
|
||||
the rightmost leaf ``rcu_node`` structure, and the grace-period kernel
|
||||
|
||||
@@ -45,7 +45,7 @@ requirements:
|
||||
#. `Other RCU Flavors`_
|
||||
#. `Possible Future Changes`_
|
||||
|
||||
This is followed by a `summary <#Summary>`__, however, the answers to
|
||||
This is followed by a summary_, however, the answers to
|
||||
each quick quiz immediately follows the quiz. Select the big white space
|
||||
with your mouse to see the answer.
|
||||
|
||||
@@ -1096,7 +1096,7 @@ memory barriers.
|
||||
| case, voluntary context switch) within an RCU read-side critical |
|
||||
| section. However, sleeping locks may be used within userspace RCU |
|
||||
| read-side critical sections, and also within Linux-kernel sleepable |
|
||||
| RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In |
|
||||
| RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In |
|
||||
| addition, the -rt patchset turns spinlocks into a sleeping locks so |
|
||||
| that the corresponding critical sections can be preempted, which also |
|
||||
| means that these sleeplockified spinlocks (but not other sleeping |
|
||||
@@ -1186,7 +1186,7 @@ non-preemptible (``CONFIG_PREEMPT=n``) kernels, and thus `tiny
|
||||
RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__
|
||||
was born. Josh Triplett has since taken over the small-memory banner
|
||||
with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__
|
||||
project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional
|
||||
project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional
|
||||
for those kernels not needing it.
|
||||
|
||||
The remaining performance requirements are, for the most part,
|
||||
@@ -1457,8 +1457,8 @@ will vary as the value of ``HZ`` varies, and can also be changed using
|
||||
the relevant Kconfig options and kernel boot parameters. RCU currently
|
||||
does not do much sanity checking of these parameters, so please use
|
||||
caution when changing them. Note that these forward-progress measures
|
||||
are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
|
||||
RCU <#Tasks%20RCU>`__.
|
||||
are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
|
||||
RCU`_.
|
||||
|
||||
RCU takes the following steps in ``call_rcu()`` to encourage timely
|
||||
invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has
|
||||
@@ -1477,8 +1477,8 @@ encouragement was provided:
|
||||
|
||||
Again, these are default values when running at ``HZ=1000``, and can be
|
||||
overridden. Again, these forward-progress measures are provided only for
|
||||
RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
|
||||
RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward
|
||||
RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
|
||||
RCU`_. Even for RCU, callback-invocation forward
|
||||
progress for ``rcu_nocbs`` CPUs is much less well-developed, in part
|
||||
because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke
|
||||
``call_rcu()`` relatively infrequently. If workloads emerge that need
|
||||
@@ -1920,7 +1920,7 @@ Hotplug CPU
|
||||
|
||||
The Linux kernel supports CPU hotplug, which means that CPUs can come
|
||||
and go. It is of course illegal to use any RCU API member from an
|
||||
offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side
|
||||
offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side
|
||||
critical sections. This requirement was present from day one in
|
||||
DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug
|
||||
implementation is “interesting.”
|
||||
@@ -2177,7 +2177,7 @@ handles these states differently:
|
||||
However, RCU must be reliably informed as to whether any given CPU is
|
||||
currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that
|
||||
CPU is executing in usermode, as discussed
|
||||
`earlier <#Energy%20Efficiency>`__. It also requires that the
|
||||
`earlier <Energy Efficiency_>`__. It also requires that the
|
||||
scheduling-clock interrupt be enabled when RCU needs it to be:
|
||||
|
||||
#. If a CPU is either idle or executing in usermode, and RCU believes it
|
||||
@@ -2294,7 +2294,7 @@ Performance, Scalability, Response Time, and Reliability
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Expanding on the `earlier
|
||||
discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by
|
||||
discussion <Performance and Scalability_>`__, RCU is used heavily by
|
||||
hot code paths in performance-critical portions of the Linux kernel's
|
||||
networking, security, virtualization, and scheduling code paths. RCU
|
||||
must therefore use efficient implementations, especially in its
|
||||
|
||||
@@ -23,7 +23,7 @@ Here is what the fields mean:
|
||||
|
||||
- ``name``
|
||||
is an identifier string. A new /proc file will be created with this
|
||||
``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
|
||||
name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
|
||||
obvious reasons.
|
||||
- ``type``
|
||||
is the type of recognition. Give ``M`` for magic and ``E`` for extension.
|
||||
@@ -83,7 +83,7 @@ Here is what the fields mean:
|
||||
``F`` - fix binary
|
||||
The usual behaviour of binfmt_misc is to spawn the
|
||||
binary lazily when the misc format file is invoked. However,
|
||||
this doesn``t work very well in the face of mount namespaces and
|
||||
this doesn't work very well in the face of mount namespaces and
|
||||
changeroots, so the ``F`` mode opens the binary as soon as the
|
||||
emulation is installed and uses the opened image to spawn the
|
||||
emulator, meaning it is always available once installed,
|
||||
|
||||
@@ -154,7 +154,7 @@ get the boot configuration data.
|
||||
Because of this "piggyback" method, there is no need to change or
|
||||
update the boot loader and the kernel image itself as long as the boot
|
||||
loader passes the correct initrd file size. If by any chance, the boot
|
||||
loader passes a longer size, the kernel feils to find the bootconfig data.
|
||||
loader passes a longer size, the kernel fails to find the bootconfig data.
|
||||
|
||||
To do this operation, Linux kernel provides "bootconfig" command under
|
||||
tools/bootconfig, which allows admin to apply or delete the config file
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
The kernel's command-line parameters
|
||||
====================================
|
||||
|
||||
The following is a consolidated list of the kernel parameters as
|
||||
implemented by the __setup(), core_param() and module_param() macros
|
||||
The following is a consolidated list of the kernel parameters as implemented
|
||||
by the __setup(), early_param(), core_param() and module_param() macros
|
||||
and sorted into English Dictionary order (defined as ignoring all
|
||||
punctuation and sorting digits before letters in a case insensitive
|
||||
manner), and with descriptions where known.
|
||||
|
||||
@@ -1385,7 +1385,7 @@
|
||||
|
||||
ftrace_filter=[function-list]
|
||||
[FTRACE] Limit the functions traced by the function
|
||||
tracer at boot up. function-list is a comma separated
|
||||
tracer at boot up. function-list is a comma-separated
|
||||
list of functions. This list can be changed at run
|
||||
time by the set_ftrace_filter file in the debugfs
|
||||
tracing directory.
|
||||
@@ -1399,13 +1399,13 @@
|
||||
ftrace_graph_filter=[function-list]
|
||||
[FTRACE] Limit the top level callers functions traced
|
||||
by the function graph tracer at boot up.
|
||||
function-list is a comma separated list of functions
|
||||
function-list is a comma-separated list of functions
|
||||
that can be changed at run time by the
|
||||
set_graph_function file in the debugfs tracing directory.
|
||||
|
||||
ftrace_graph_notrace=[function-list]
|
||||
[FTRACE] Do not trace from the functions specified in
|
||||
function-list. This list is a comma separated list of
|
||||
function-list. This list is a comma-separated list of
|
||||
functions that can be changed at run time by the
|
||||
set_graph_notrace file in the debugfs tracing directory.
|
||||
|
||||
@@ -2421,7 +2421,7 @@
|
||||
when set.
|
||||
Format: <int>
|
||||
|
||||
libata.force= [LIBATA] Force configurations. The format is comma
|
||||
libata.force= [LIBATA] Force configurations. The format is comma-
|
||||
separated list of "[ID:]VAL" where ID is
|
||||
PORT[.DEVICE]. PORT and DEVICE are decimal numbers
|
||||
matching port, link or device. Basically, it matches
|
||||
@@ -5145,7 +5145,7 @@
|
||||
|
||||
stacktrace_filter=[function-list]
|
||||
[FTRACE] Limit the functions that the stack tracer
|
||||
will trace at boot up. function-list is a comma separated
|
||||
will trace at boot up. function-list is a comma-separated
|
||||
list of functions. This list can be changed at run
|
||||
time by the stack_trace_filter file in the debugfs
|
||||
tracing directory. Note, this enables stack tracing
|
||||
@@ -5348,7 +5348,7 @@
|
||||
trace_event=[event-list]
|
||||
[FTRACE] Set and start specified trace events in order
|
||||
to facilitate early boot debugging. The event-list is a
|
||||
comma separated list of trace events to enable. See
|
||||
comma-separated list of trace events to enable. See
|
||||
also Documentation/trace/events.rst
|
||||
|
||||
trace_options=[option-list]
|
||||
@@ -5972,6 +5972,10 @@
|
||||
This option is obsoleted by the "nopv" option, which
|
||||
has equivalent effect for XEN platform.
|
||||
|
||||
xen_no_vector_callback
|
||||
[KNL,X86,XEN] Disable the vector callback for Xen
|
||||
event channel interrupts.
|
||||
|
||||
xen_scrub_pages= [XEN]
|
||||
Boolean option to control scrubbing pages before giving them back
|
||||
to Xen, for use by other domains. Can be also changed at runtime
|
||||
|
||||
@@ -184,7 +184,7 @@ pages either asynchronously or synchronously, depending on the state
|
||||
of the system. When the system is not loaded, most of the memory is free
|
||||
and allocation requests will be satisfied immediately from the free
|
||||
pages supply. As the load increases, the amount of the free pages goes
|
||||
down and when it reaches a certain threshold (high watermark), an
|
||||
down and when it reaches a certain threshold (low watermark), an
|
||||
allocation request will awaken the ``kswapd`` daemon. It will
|
||||
asynchronously scan memory pages and either just free them if the data
|
||||
they contain is available elsewhere, or evict to the backing storage
|
||||
|
||||
@@ -53,7 +53,6 @@ How Linux keeps everything from happening at the same time. See
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
atomic_ops
|
||||
refcount-vs-atomic
|
||||
irq/index
|
||||
local_ops
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2020 Texas Instruments Incorporated
|
||||
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
|
||||
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2020 Texas Instruments Incorporated
|
||||
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
|
||||
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The Packet DMA (PKTDMA) is intended to perform similar functions as the packet
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2019 Texas Instruments Incorporated
|
||||
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml#
|
||||
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Texas Instruments K3 NAVSS Unified DMA Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The UDMA-P is intended to perform similar (but significantly upgraded)
|
||||
|
||||
@@ -163,6 +163,7 @@ allOf:
|
||||
enum:
|
||||
- renesas,etheravb-r8a774a1
|
||||
- renesas,etheravb-r8a774b1
|
||||
- renesas,etheravb-r8a774e1
|
||||
- renesas,etheravb-r8a7795
|
||||
- renesas,etheravb-r8a7796
|
||||
- renesas,etheravb-r8a77961
|
||||
|
||||
@@ -161,7 +161,8 @@ properties:
|
||||
* snps,route-dcbcp, DCB Control Packets
|
||||
* snps,route-up, Untagged Packets
|
||||
* snps,route-multi-broad, Multicast & Broadcast Packets
|
||||
* snps,priority, RX queue priority (Range 0x0 to 0xF)
|
||||
* snps,priority, bitmask of the tagged frames priorities assigned to
|
||||
the queue
|
||||
|
||||
snps,mtl-tx-config:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
@@ -188,7 +189,10 @@ properties:
|
||||
* snps,idle_slope, unlock on WoL
|
||||
* snps,high_credit, max write outstanding req. limit
|
||||
* snps,low_credit, max read outstanding req. limit
|
||||
* snps,priority, TX queue priority (Range 0x0 to 0xF)
|
||||
* snps,priority, bitmask of the priorities assigned to the queue.
|
||||
When a PFC frame is received with priorities matching the bitmask,
|
||||
the queue is blocked from transmitting for the pause time specified
|
||||
in the PFC frame.
|
||||
|
||||
snps,reset-gpio:
|
||||
deprecated: true
|
||||
|
||||
@@ -19,7 +19,9 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- nxp,pf8x00
|
||||
- nxp,pf8100
|
||||
- nxp,pf8121a
|
||||
- nxp,pf8200
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@@ -118,7 +120,7 @@ examples:
|
||||
#size-cells = <0>;
|
||||
|
||||
pmic@8 {
|
||||
compatible = "nxp,pf8x00";
|
||||
compatible = "nxp,pf8100";
|
||||
reg = <0x08>;
|
||||
|
||||
regulators {
|
||||
|
||||
@@ -44,6 +44,7 @@ First Level Nodes - PMIC
|
||||
Definition: Must be one of below:
|
||||
"qcom,pm8005-rpmh-regulators"
|
||||
"qcom,pm8009-rpmh-regulators"
|
||||
"qcom,pm8009-1-rpmh-regulators"
|
||||
"qcom,pm8150-rpmh-regulators"
|
||||
"qcom,pm8150l-rpmh-regulators"
|
||||
"qcom,pm8350-rpmh-regulators"
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2020 Texas Instruments Incorporated
|
||||
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-audio.yaml#
|
||||
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Texas Instruments J721e Common Processor Board Audio Support
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The audio support on the board is using pcm3168a codec connected to McASP10
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2020 Texas Instruments Incorporated
|
||||
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-ivi-audio.yaml#
|
||||
@@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Texas Instruments J721e Common Processor Board Audio Support
|
||||
|
||||
maintainers:
|
||||
- Peter Ujfalusi <peter.ujfalusi@ti.com>
|
||||
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
|
||||
description: |
|
||||
The Infotainment board plugs into the Common Processor Board, the support of the
|
||||
|
||||
@@ -11,8 +11,12 @@ maintainers:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
oneOf:
|
||||
- const: ti,j721e-usb
|
||||
- const: ti,am64-usb
|
||||
- items:
|
||||
- const: ti,j721e-usb
|
||||
- const: ti,am64-usb
|
||||
|
||||
reg:
|
||||
description: module registers
|
||||
|
||||
@@ -48,12 +48,12 @@ or ``virtualenv``, depending on how your distribution packaged Python 3.
|
||||
those versions, you should run ``pip install 'docutils==0.12'``.
|
||||
|
||||
#) It is recommended to use the RTD theme for html output. Depending
|
||||
on the Sphinx version, it should be installed in separate,
|
||||
on the Sphinx version, it should be installed separately,
|
||||
with ``pip install sphinx_rtd_theme``.
|
||||
|
||||
#) Some ReST pages contain math expressions. Due to the way Sphinx work,
|
||||
#) Some ReST pages contain math expressions. Due to the way Sphinx works,
|
||||
those expressions are written using LaTeX notation. It needs texlive
|
||||
installed with amdfonts and amsmath in order to evaluate them.
|
||||
installed with amsfonts and amsmath in order to evaluate them.
|
||||
|
||||
In summary, if you want to install Sphinx version 1.7.9, you should do::
|
||||
|
||||
@@ -128,7 +128,7 @@ Sphinx Build
|
||||
============
|
||||
|
||||
The usual way to generate the documentation is to run ``make htmldocs`` or
|
||||
``make pdfdocs``. There are also other formats available, see the documentation
|
||||
``make pdfdocs``. There are also other formats available: see the documentation
|
||||
section of ``make help``. The generated documentation is placed in
|
||||
format-specific subdirectories under ``Documentation/output``.
|
||||
|
||||
@@ -303,17 +303,17 @@ and *targets* (e.g. a ref to ``:ref:`last row <last row>``` / :ref:`last row
|
||||
- head col 3
|
||||
- head col 4
|
||||
|
||||
* - column 1
|
||||
* - row 1
|
||||
- field 1.1
|
||||
- field 1.2 with autospan
|
||||
|
||||
* - column 2
|
||||
* - row 2
|
||||
- field 2.1
|
||||
- :rspan:`1` :cspan:`1` field 2.2 - 3.3
|
||||
|
||||
* .. _`last row`:
|
||||
|
||||
- column 3
|
||||
- row 3
|
||||
|
||||
Rendered as:
|
||||
|
||||
@@ -325,17 +325,17 @@ Rendered as:
|
||||
- head col 3
|
||||
- head col 4
|
||||
|
||||
* - column 1
|
||||
* - row 1
|
||||
- field 1.1
|
||||
- field 1.2 with autospan
|
||||
|
||||
* - column 2
|
||||
* - row 2
|
||||
- field 2.1
|
||||
- :rspan:`1` :cspan:`1` field 2.2 - 3.3
|
||||
|
||||
* .. _`last row`:
|
||||
|
||||
- column 3
|
||||
- row 3
|
||||
|
||||
Cross-referencing
|
||||
-----------------
|
||||
@@ -361,7 +361,7 @@ Figures & Images
|
||||
|
||||
If you want to add an image, you should use the ``kernel-figure`` and
|
||||
``kernel-image`` directives. E.g. to insert a figure with a scalable
|
||||
image format use SVG (:ref:`svg_image_example`)::
|
||||
image format, use SVG (:ref:`svg_image_example`)::
|
||||
|
||||
.. kernel-figure:: svg_image.svg
|
||||
:alt: simple SVG image
|
||||
@@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`)::
|
||||
|
||||
SVG image example
|
||||
|
||||
The kernel figure (and image) directive support **DOT** formatted files, see
|
||||
The kernel figure (and image) directive supports **DOT** formatted files, see
|
||||
|
||||
* DOT: http://graphviz.org/pdf/dotguide.pdf
|
||||
* Graphviz: http://www.graphviz.org/content/dot-language
|
||||
@@ -394,7 +394,7 @@ A simple example (:ref:`hello_dot_file`)::
|
||||
|
||||
DOT's hello world example
|
||||
|
||||
Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the
|
||||
Embedded *render* markups (or languages) like Graphviz's **DOT** are provided by the
|
||||
``kernel-render`` directives.::
|
||||
|
||||
.. kernel-render:: DOT
|
||||
@@ -406,7 +406,7 @@ Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the
|
||||
}
|
||||
|
||||
How this will be rendered depends on the installed tools. If Graphviz is
|
||||
installed, you will see an vector image. If not the raw markup is inserted as
|
||||
installed, you will see a vector image. If not, the raw markup is inserted as
|
||||
*literal-block* (:ref:`hello_dot_render`).
|
||||
|
||||
.. _hello_dot_render:
|
||||
@@ -421,8 +421,8 @@ installed, you will see an vector image. If not the raw markup is inserted as
|
||||
|
||||
The *render* directive has all the options known from the *figure* directive,
|
||||
plus option ``caption``. If ``caption`` has a value, a *figure* node is
|
||||
inserted. If not, a *image* node is inserted. A ``caption`` is also needed, if
|
||||
you want to refer it (:ref:`hello_svg_render`).
|
||||
inserted. If not, an *image* node is inserted. A ``caption`` is also needed, if
|
||||
you want to refer to it (:ref:`hello_svg_render`).
|
||||
|
||||
Embedded **SVG**::
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user