Qortal/Brooklyn
3
0
Fork 1
mirror of https://github.com/Qortal/Brooklyn.git synced 2025-01-30 14:52:17 +00:00
Code Issues Projects Releases Wiki Activity

Second batch of augmented kernel

Browse Source 
Github is super gay like T3Q.
This commit is contained in:
Raziel K. Crowe 2022-03-15 21:06:03 +05:00
parent 7c1eb8ceac
commit b48c9cc972
2127 changed files with 38439 additions and 62156 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Documentation/Makefile
View File

@ -19,8 +19,6 @@ endif
SPHINXBUILD = sphinx-build
SPHINXOPTS =
SPHINXDIRS = .
DOCS_THEME =
DOCS_CSS =
_SPHINXDIRS = $(sort $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst)))
SPHINX_CONF = conf.py
PAPER =
@ -86,10 +84,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
-D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \
$(ALLSPHINXOPTS) \
$(abspath $(srctree)/$(src)/$5) \
$(abspath $(BUILDDIR)/$3/$4) && \
if [ "x$(DOCS_CSS)" != "x" ]; then \
cp $(if $(patsubst /%,,$(DOCS_CSS)),$(abspath $(srctree)/$(DOCS_CSS)),$(DOCS_CSS)) $(BUILDDIR)/$3/_static/; \
fi
$(abspath $(BUILDDIR)/$3/$4)
htmldocs:
@$(srctree)/scripts/sphinx-pre-install --version-check
@ -159,8 +154,4 @@ dochelp:
@echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build'
@echo ' configuration. This is e.g. useful to build with nit-picking config.'
@echo
@echo ' make DOCS_THEME={sphinx-theme} selects a different Sphinx theme.'
@echo
@echo ' make DOCS_CSS={a .css file} adds a DOCS_CSS override file for html/epub output.'
@echo
@echo ' Default location for the generated documents is Documentation/output'

2
Documentation/admin-guide/acpi/cppc_sysfs.rst
View File

@ -4,8 +4,6 @@
Collaborative Processor Performance Control (CPPC)
==================================================
.. _cppc_sysfs:
CPPC
====

8
Documentation/admin-guide/blockdev/zram.rst
View File

@ -328,14 +328,6 @@ as idle::
From now on, any pages on zram are idle pages. The idle mark
will be removed until someone requests access of the block.
IOW, unless there is access request, those pages are still idle pages.
Additionally, when CONFIG_ZRAM_MEMORY_TRACKING is enabled pages can be
marked as idle based on how long (in seconds) it's been since they were
last accessed::
echo 86400 > /sys/block/zramX/idle
In this example all pages which haven't been accessed in more than 86400
seconds (one day) will be marked idle.
Admin can request writeback of those idle pages at right timing via::

4
Documentation/admin-guide/cgroup-v1/hugetlb.rst
View File

@ -29,14 +29,12 @@ Brief summary of control files::
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB usage limit
hugetlb.<hugepagesize>.numa_stat # show the numa information of the hugetlb memory charged to this cgroup
For a system supporting three hugepage sizes (64k, 32M and 1G), the control
files include::
hugetlb.1GB.limit_in_bytes
hugetlb.1GB.max_usage_in_bytes
hugetlb.1GB.numa_stat
hugetlb.1GB.usage_in_bytes
hugetlb.1GB.failcnt
hugetlb.1GB.rsvd.limit_in_bytes
@ -45,7 +43,6 @@ files include::
hugetlb.1GB.rsvd.failcnt
hugetlb.64KB.limit_in_bytes
hugetlb.64KB.max_usage_in_bytes
hugetlb.64KB.numa_stat
hugetlb.64KB.usage_in_bytes
hugetlb.64KB.failcnt
hugetlb.64KB.rsvd.limit_in_bytes
@ -54,7 +51,6 @@ files include::
hugetlb.64KB.rsvd.failcnt
hugetlb.32MB.limit_in_bytes
hugetlb.32MB.max_usage_in_bytes
hugetlb.32MB.numa_stat
hugetlb.32MB.usage_in_bytes
hugetlb.32MB.failcnt
hugetlb.32MB.rsvd.limit_in_bytes

11
Documentation/admin-guide/cgroup-v1/memory.rst
View File

@ -87,8 +87,10 @@ Brief summary of control files.
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
memory.kmem.limit_in_bytes This knob is deprecated and writing to
it will return -ENOTSUPP.
memory.kmem.limit_in_bytes set/show hard limit for kernel memory
This knob is deprecated and shouldn't be
used. It is planned that this be removed in
the foreseeable future.
memory.kmem.usage_in_bytes show current kernel memory allocation
memory.kmem.failcnt show the number of kernel memory usage
hits limits
@ -516,6 +518,11 @@ will be charged as a new owner of it.
charged file caches. Some out-of-use page caches may keep charged until
memory pressure happens. If you want to avoid that, force_empty will be useful.
Also, note that when memory.kmem.limit_in_bytes is set the charges due to
kernel pages will still be seen. This is not considered a failure and the
write will still return success. In this case, it is expected that
memory.kmem.usage_in_bytes == memory.usage_in_bytes.
5.2 stat file
-------------

29
Documentation/admin-guide/cgroup-v2.rst
View File

@ -1016,8 +1016,6 @@ All time durations are in microseconds.
- nr_periods
- nr_throttled
- throttled_usec
- nr_bursts
- burst_usec
cpu.weight
A read-write single value file which exists on non-root
@ -1049,12 +1047,6 @@ All time durations are in microseconds.
$PERIOD duration. "max" for $MAX indicates no limit. If only
one number is written, $MAX is updated.
cpu.max.burst
A read-write single value file which exists on non-root
cgroups. The default is "0".
The burst in the range [0, $MAX].
cpu.pressure
A read-write nested-keyed file.
@ -1268,9 +1260,6 @@ PAGE_SIZE multiple when read back.
The number of processes belonging to this cgroup
killed by any kind of OOM killer.
oom_group_kill
The number of times a group OOM has occurred.
memory.events.local
Similar to memory.events but the fields in the file are local
to the cgroup i.e. not hierarchical. The file modified event
@ -1314,9 +1303,6 @@ PAGE_SIZE multiple when read back.
sock (npn)
Amount of memory used in network transmission buffers
vmalloc (npn)
Amount of memory used for vmap backed memory.
shmem
Amount of cached filesystem data that is swap-backed,
such as tmpfs, shm segments, shared anonymous mmap()s
@ -2266,11 +2252,6 @@ HugeTLB Interface Files
are local to the cgroup i.e. not hierarchical. The file modified event
generated on this file reflects only the local events.
hugetlb.<hugepagesize>.numa_stat
Similar to memory.numa_stat, it shows the numa information of the
hugetlb pages of <hugepagesize> in this cgroup. Only active in
use hugetlb pages are included. The per-node values are in bytes.
Misc
----
@ -2329,16 +2310,6 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_
Limits can be set higher than the capacity value in the misc.capacity
file.
misc.events
A read-only flat-keyed file which exists on non-root cgroups. The
following entries are defined. Unless specified otherwise, a value
change in this file generates a file modified event. All fields in
this file are hierarchical.
max
The number of times the cgroup's resource usage was
about to go over the max boundary.
Migration and Ownership
~~~~~~~~~~~~~~~~~~~~~~~

29
Documentation/admin-guide/cputopology.rst
View File

@ -8,22 +8,22 @@ to /proc/cpuinfo output of some architectures. They reside in
Documentation/ABI/stable/sysfs-devices-system-cpu.
Architecture-neutral, drivers/base/topology.c, exports these attributes.
However the die, cluster, book, and drawer hierarchy related sysfs files will
only be created if an architecture provides the related macros as described
below.
However, the book and drawer related sysfs files will only be created if
CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are selected, respectively.
CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are currently only used on s390,
where they reflect the cpu and cache hierarchy.
For an architecture to support this feature, it must define some of
these macros in include/asm-XXX/topology.h::
#define topology_physical_package_id(cpu)
#define topology_die_id(cpu)
#define topology_cluster_id(cpu)
#define topology_core_id(cpu)
#define topology_book_id(cpu)
#define topology_drawer_id(cpu)
#define topology_sibling_cpumask(cpu)
#define topology_core_cpumask(cpu)
#define topology_cluster_cpumask(cpu)
#define topology_die_cpumask(cpu)
#define topology_book_cpumask(cpu)
#define topology_drawer_cpumask(cpu)
@ -39,16 +39,15 @@ not defined by include/asm-XXX/topology.h:
1) topology_physical_package_id: -1
2) topology_die_id: -1
3) topology_cluster_id: -1
4) topology_core_id: 0
5) topology_book_id: -1
6) topology_drawer_id: -1
7) topology_sibling_cpumask: just the given CPU
8) topology_core_cpumask: just the given CPU
9) topology_cluster_cpumask: just the given CPU
10) topology_die_cpumask: just the given CPU
11) topology_book_cpumask: just the given CPU
12) topology_drawer_cpumask: just the given CPU
3) topology_core_id: 0
4) topology_sibling_cpumask: just the given CPU
5) topology_core_cpumask: just the given CPU
6) topology_die_cpumask: just the given CPU
For architectures that don't support books (CONFIG_SCHED_BOOK) there are no
default definitions for topology_book_id() and topology_book_cpumask().
For architectures that don't support drawers (CONFIG_SCHED_DRAWER) there are
no default definitions for topology_drawer_id() and topology_drawer_cpumask().
Additionally, CPU topology information is provided under
/sys/devices/system/cpu and includes these files. The internal

15
Documentation/admin-guide/dynamic-debug-howto.rst
View File

@ -249,7 +249,8 @@ Debug messages during Boot Process
To activate debug messages for core code and built-in modules during
the boot process, even before userspace and debugfs exists, use
``dyndbg="QUERY"`` or ``module.dyndbg="QUERY"``. QUERY follows
``dyndbg="QUERY"``, ``module.dyndbg="QUERY"``, or ``ddebug_query="QUERY"``
(``ddebug_query`` is obsoleted by ``dyndbg``, and deprecated). QUERY follows
the syntax described above, but must not exceed 1023 characters. Your
bootloader may impose lower limits.
@ -269,7 +270,8 @@ this boot parameter for debugging purposes.
If ``foo`` module is not built-in, ``foo.dyndbg`` will still be processed at
boot time, without effect, but will be reprocessed when module is
loaded later. Bare ``dyndbg=`` is only processed at boot.
loaded later. ``ddebug_query=`` and bare ``dyndbg=`` are only processed at
boot.
Debug Messages at Module Initialization Time
@ -356,11 +358,8 @@ Examples
// boot-args example, with newlines and comments for readability
Kernel command line: ...
// see whats going on in dyndbg=value processing
dynamic_debug.verbose=3
// enable pr_debugs in the btrfs module (can be builtin or loadable)
btrfs.dyndbg="+p"
// enable pr_debugs in all files under init/
// and the function parse_one, #cmt is stripped
dyndbg="file init/* +p #cmt ; func parse_one +p"
dynamic_debug.verbose=1
// enable pr_debugs in 2 builtins, #cmt is stripped
dyndbg="module params +p #cmt ; module sys +p"
// enable pr_debugs in 2 functions in a module loaded later
pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p"

1
Documentation/admin-guide/gpio/index.rst
View File

@ -10,7 +10,6 @@ gpio
gpio-aggregator
sysfs
gpio-mockup
gpio-sim
.. only:: subproject and html

5
Documentation/admin-guide/hw-vuln/core-scheduling.rst
View File

@ -61,9 +61,8 @@ arg3:
``pid`` of the task for which the operation applies.
arg4:
``pid_type`` for which the operation applies. It is one of
``PR_SCHED_CORE_SCOPE_``-prefixed macro constants. For example, if arg4
is ``PR_SCHED_CORE_SCOPE_THREAD_GROUP``, then the operation of this command
``pid_type`` for which the operation applies. It is of type ``enum pid_type``.
For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command
will be performed for all tasks in the task group of ``pid``.
arg5:

109
Documentation/admin-guide/hw-vuln/spectre.rst
View File

@ -60,8 +60,8 @@ privileged data touched during the speculative execution.
Spectre variant 1 attacks take advantage of speculative execution of
conditional branches, while Spectre variant 2 attacks use speculative
execution of indirect branches to leak privileged memory.
See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[6] <spec_ref6>`
:ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
Spectre variant 1 (Bounds Check Bypass)
---------------------------------------
@ -131,6 +131,19 @@ steer its indirect branch speculations to gadget code, and measure the
speculative execution's side effects left in level 1 cache to infer the
victim's data.
Yet another variant 2 attack vector is for the attacker to poison the
Branch History Buffer (BHB) to speculatively steer an indirect branch
to a specific Branch Target Buffer (BTB) entry, even if the entry isn't
associated with the source address of the indirect branch. Specifically,
the BHB might be shared across privilege levels even in the presence of
Enhanced IBRS.
Currently the only known real-world BHB attack vector is via
unprivileged eBPF. Therefore, it's highly recommended to not enable
unprivileged eBPF, especially when eIBRS is used (without retpolines).
For a full mitigation against BHB attacks, it's recommended to use
retpolines (or eIBRS combined with retpolines).
Attack scenarios
----------------
@ -364,13 +377,15 @@ The possible values in this file are:
- Kernel status:
==================================== =================================
'Not affected' The processor is not vulnerable
'Vulnerable' Vulnerable, no mitigation
'Mitigation: Full generic retpoline' Software-focused mitigation
'Mitigation: Full AMD retpoline' AMD-specific software mitigation
'Mitigation: Enhanced IBRS' Hardware-focused mitigation
==================================== =================================
======================================== =================================
'Not affected' The processor is not vulnerable
'Mitigation: None' Vulnerable, no mitigation
'Mitigation: Retpolines' Use Retpoline thunks
'Mitigation: LFENCE' Use LFENCE instructions
'Mitigation: Enhanced IBRS' Hardware-focused mitigation
'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines
'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE
======================================== =================================
- Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
@ -490,8 +505,9 @@ Spectre variant 2
Restricting indirect branch speculation on a user program will
also prevent the program from launching a variant 2 attack
on x86. Administrators can change that behavior via the kernel
command line and sysfs control files.
on x86. All sand-boxed SECCOMP programs have indirect branch
speculation restricted by default. Administrators can change
that behavior via the kernel command line and sysfs control files.
See :ref:`spectre_mitigation_control_command_line`.
Programs that disable their indirect branch speculation will have
@ -583,24 +599,72 @@ kernel command line.
Specific mitigations can also be selected manually:
retpoline
replace indirect branches
retpoline,generic
google's original retpoline
retpoline,amd
AMD-specific minimal thunk
retpoline auto pick between generic,lfence
retpoline,generic Retpolines
retpoline,lfence LFENCE; indirect branch
retpoline,amd alias for retpoline,lfence
eibrs enhanced IBRS
eibrs,retpoline enhanced IBRS + Retpolines
eibrs,lfence enhanced IBRS + LFENCE
Not specifying this option is equivalent to
spectre_v2=auto.
For user space mitigation:
spectre_v2_user=
[X86] Control mitigation of Spectre variant 2
(indirect branch speculation) vulnerability between
user space tasks
on
Unconditionally enable mitigations. Is
enforced by spectre_v2=on
off
Unconditionally disable mitigations. Is
enforced by spectre_v2=off
prctl
Indirect branch speculation is enabled,
but mitigation can be enabled via prctl
per thread. The mitigation control state
is inherited on fork.
prctl,ibpb
Like "prctl" above, but only STIBP is
controlled per thread. IBPB is issued
always when switching between different user
space processes.
seccomp
Same as "prctl" above, but all seccomp
threads will enable the mitigation unless
they explicitly opt out.
seccomp,ibpb
Like "seccomp" above, but only STIBP is
controlled per thread. IBPB is issued
always when switching between different
user space processes.
auto
Kernel selects the mitigation depending on
the available CPU features and vulnerability.
Default mitigation:
If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
Not specifying this option is equivalent to
spectre_v2_user=auto.
In general the kernel by default selects
reasonable mitigations for the current CPU. To
disable Spectre variant 2 mitigations, boot with
spectre_v2=off. Spectre variant 1 mitigations
cannot be disabled.
For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`.
Mitigation selection guide
--------------------------
@ -626,8 +690,9 @@ Mitigation selection guide
off by disabling their indirect branch speculation when they are run
(See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
This prevents untrusted programs from polluting the branch target
buffer. This behavior can be changed via the kernel command line
and sysfs control files. See
buffer. All programs running in SECCOMP sandboxes have indirect
branch speculation restricted by default. This behavior can be
changed via the kernel command line and sysfs control files. See
:ref:`spectre_mitigation_control_command_line`.
3. High security mode
@ -681,7 +746,7 @@ AMD white papers:
.. _spec_ref6:
[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.
[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.
ARM white papers:

1
Documentation/admin-guide/index.rst
View File

@ -82,7 +82,6 @@ configure specific aspects of kernel behavior to your liking.
edid
efi-stub
ext4
filesystem-monitoring
nfs/index
gpio/index
highuid

194
Documentation/admin-guide/kernel-parameters.txt
View File

@ -225,23 +225,14 @@
For broken nForce2 BIOS resulting in XT-PIC timer.
acpi_sleep= [HW,ACPI] Sleep options
Format: { s3_bios, s3_mode, s3_beep, s4_hwsig,
s4_nohwsig, old_ordering, nonvs,
sci_force_enable, nobl }
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
old_ordering, nonvs, sci_force_enable, nobl }
See Documentation/power/video.rst for information on
s3_bios and s3_mode.
s3_beep is for debugging; it makes the PC's speaker beep
as soon as the kernel's real-mode entry point is called.
s4_hwsig causes the kernel to check the ACPI hardware
signature during resume from hibernation, and gracefully
refuse to resume if it has changed. This complies with
the ACPI specification but not with reality, since
Windows does not do this and many laptops do change it
on docking. So the default behaviour is to allow resume
and simply warn when the signature changes, unless the
s4_hwsig option is enabled.
s4_nohwsig prevents ACPI hardware signature from being
used (or even warned about) during resume.
used during resume from hibernation.
old_ordering causes the ACPI 1.0 ordering of the _PTS
control method, with respect to putting devices into
low power states, to be enforced (the ACPI 2.0 ordering
@ -612,8 +603,8 @@
clocksource.max_cswd_read_retries= [KNL]
Number of clocksource_watchdog() retries due to
external delays before the clock will be marked
unstable. Defaults to two retries, that is,
three attempts to read the clock under test.
unstable. Defaults to three retries, that is,
four attempts to read the clock under test.
clocksource.verify_n_cpus= [KNL]
Limit the number of CPUs checked for clocksources
@ -850,6 +841,11 @@
Format: <port#>,<type>
See also Documentation/input/devices/joystick-parport.rst
ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See
Documentation/admin-guide/dynamic-debug-howto.rst for
details. Deprecated, see dyndbg.
debug [KNL] Enable kernel debugging (events log level).
debug_boot_weak_hash
@ -1591,10 +1587,8 @@
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
of gigantic hugepages. Or using node format, the size
of a CMA area per node can be specified.
Format: nn[KMGTPE] or (node format)
<node>:nn[KMGTPE][,<node>:nn[KMGTPE]]
of gigantic hugepages.
Format: nn[KMGTPE]
Reserve a CMA area of given size and allocate gigantic
hugepages using the CMA allocator. If enabled, the
@ -1605,11 +1599,9 @@
the number of pages of hugepagesz to be allocated.
If this is the first HugeTLB parameter on the command
line, it specifies the number of pages to allocate for
the default huge page size. If using node format, the
number of pages to allocate per-node can be specified.
See also Documentation/admin-guide/mm/hugetlbpage.rst.
Format: <integer> or (node format)
<node>:<integer>[,<node>:<integer>]
the default huge page size. See also
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: <integer>
hugepagesz=
[HW] The size of the HugeTLB pages. This is used in
@ -2363,14 +2355,7 @@
[KVM] Controls how many 4KiB pages are periodically zapped
back to huge pages. 0 disables the recovery, otherwise if
the value is N KVM will zap 1/Nth of the 4KiB pages every
period (see below). The default is 60.
kvm.nx_huge_pages_recovery_period_ms=
[KVM] Controls the time period at which KVM zaps 4KiB pages
back to huge pages. If the value is a non-zero N, KVM will
zap a portion (see ratio above) of the pages every N msecs.
If the value is 0 (the default), KVM will pick a period based
on the ratio, such that a page is zapped after 1 hour on average.
minute. The default is 60.
kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM.
Default is 1 (enabled)
@ -2382,8 +2367,6 @@
kvm-arm.mode=
[KVM,ARM] Select one of KVM/arm64's modes of operation.
none: Forcefully disable KVM.
nvhe: Standard nVHE-based mode, without support for
protected guests.
@ -2391,9 +2374,7 @@
state is kept private from the host.
Not valid if the kernel is running in EL2.
Defaults to VHE/nVHE based on hardware support. Setting
mode to "protected" will disable kexec and hibernation
for the host.
Defaults to VHE/nVHE based on hardware support.
kvm-arm.vgic_v3_group0_trap=
[KVM,ARM] Trap guest accesses to GICv3 group-0
@ -2949,7 +2930,7 @@
both parameters are enabled, hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.
memtest= [KNL,X86,ARM,M68K,PPC,RISCV] Enable memtest
memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest
Format: <integer>
default : 0 <disable>
Specifies the number of memtest passes to be
@ -3268,19 +3249,6 @@
driver. A non-zero value sets the minimum interval
in seconds between layoutstats transmissions.
nfsd.inter_copy_offload_enable =
[NFSv4.2] When set to 1, the server will support
server-to-server copies for which this server is
the destination of the copy.
nfsd.nfsd4_ssc_umount_timeout =
[NFSv4.2] When used as the destination of a
server-to-server copy, knfsd temporarily mounts
the source server. It caches the mount in case
it will be needed again, and discards it if not
used for the number of milliseconds specified by
this parameter.
nfsd.nfs4_disable_idmapping=
[NFSv4] When set to the default of '1', the NFSv4
server will return only numeric uids and gids to
@ -3288,7 +3256,6 @@
and gids from such clients. This is intended to ease
migration from NFSv2/v3.
nmi_backtrace.backtrace_idle [KNL]
Dump stacks even of idle CPUs in response to an
NMI stack-backtrace request.
@ -3393,7 +3360,7 @@
Disable SMAP (Supervisor Mode Access Prevention)
even if it is supported by processor.
nosmep [X86,PPC64s]
nosmep [X86,PPC]
Disable SMEP (Supervisor Mode Execution Prevention)
even if it is supported by processor.
@ -3560,13 +3527,6 @@
shutdown the other cpus. Instead use the REBOOT_VECTOR
irq.
nomodeset Disable kernel modesetting. DRM drivers will not perform
display-mode changes or accelerated rendering. Only the
system framebuffer will be available for use if this was
set-up by the firmware or boot loader.
Useful as fallback, or for testing and debugging.
nomodule Disable module load
nopat [X86] Disable PAT (page attribute table extension of
@ -4166,14 +4126,6 @@
Override pmtimer IOPort with a hex value.
e.g. pmtmr=0x508
pmu_override= [PPC] Override the PMU.
This option takes over the PMU facility, so it is no
longer usable by perf. Setting this option starts the
PMU counters by setting MMCR0 to 0 (the FC bit is
cleared). If a number is given, then MMCR1 is set to
that number, otherwise (e.g., 'pmu_override=on'), MMCR1
remains 0.
pm_debug_messages [SUSPEND,KNL]
Enable suspend/resume debug messages during boot up.
@ -4373,30 +4325,19 @@
Disable the Correctable Errors Collector,
see CONFIG_RAS_CEC help text.
rcu_nocbs[=cpu-list]
[KNL] The optional argument is a cpu list,
as described above.
rcu_nocbs= [KNL]
The argument is a cpu list, as described above.
In kernels built with CONFIG_RCU_NOCB_CPU=y,
enable the no-callback CPU mode, which prevents
such CPUs' callbacks from being invoked in
softirq context. Invocation of such CPUs' RCU
callbacks will instead be offloaded to "rcuox/N"
kthreads created for that purpose, where "x" is
"p" for RCU-preempt, "s" for RCU-sched, and "g"
for the kthreads that mediate grace periods; and
"N" is the CPU number. This reduces OS jitter on
the offloaded CPUs, which can be useful for HPC
and real-time workloads. It can also improve
energy efficiency for asymmetric multiprocessors.
If a cpulist is passed as an argument, the specified
list of CPUs is set to no-callback mode from boot.
Otherwise, if the '=' sign and the cpulist
arguments are omitted, no CPU will be set to
no-callback mode from boot but the mode may be
toggled at runtime via cpusets.
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
Invocation of these CPUs' RCU callbacks will be
offloaded to "rcuox/N" kthreads created for that
purpose, where "x" is "p" for RCU-preempt, and
"s" for RCU-sched, and "N" is the CPU number.
This reduces OS jitter on the offloaded CPUs,
which can be useful for HPC and real-time
workloads. It can also improve energy efficiency
for asymmetric multiprocessors.
rcu_nocb_poll [KNL]
Rather than requiring that offloaded CPUs
@ -4530,6 +4471,10 @@
on rcutree.qhimark at boot time and to zero to
disable more aggressive help enlistment.
rcutree.rcu_idle_gp_delay= [KNL]
Set wakeup interval for idle CPUs that have
RCU callbacks (RCU_FAST_NO_HZ=y).
rcutree.rcu_kick_kthreads= [KNL]
Cause the grace-period kthread to get an extra
wake_up() if it sleeps three times longer than
@ -4640,12 +4585,8 @@
in seconds.
rcutorture.fwd_progress= [KNL]
Specifies the number of kthreads to be used
for RCU grace-period forward-progress testing
Enable RCU grace-period forward-progress testing
for the types of RCU supporting this notion.
Defaults to 1 kthread, values less than zero or
greater than the number of CPUs cause the number
of CPUs to be used.
rcutorture.fwd_progress_div= [KNL]
Specify the fraction of a CPU-stall-warning
@ -4846,29 +4787,6 @@
period to instead use normal non-expedited
grace-period processing.
rcupdate.rcu_task_collapse_lim= [KNL]
Set the maximum number of callbacks present
at the beginning of a grace period that allows
the RCU Tasks flavors to collapse back to using
a single callback queue. This switching only
occurs when rcupdate.rcu_task_enqueue_lim is
set to the default value of -1.
rcupdate.rcu_task_contend_lim= [KNL]
Set the minimum number of callback-queuing-time
lock-contention events per jiffy required to
cause the RCU Tasks flavors to switch to per-CPU
callback queuing. This switching only occurs
when rcupdate.rcu_task_enqueue_lim is set to
the default value of -1.
rcupdate.rcu_task_enqueue_lim= [KNL]
Set the number of callback queues to use for the
RCU Tasks family of RCU flavors. The default
of -1 allows this to be automatically (and
dynamically) adjusted. This parameter is intended
for use in testing.
rcupdate.rcu_task_ipi_delay= [KNL]
Set time in jiffies during which RCU tasks will
avoid sending IPIs, starting with the beginning
@ -5070,18 +4988,6 @@
an IOTLB flush. Default is lazy flushing before reuse,
which is faster.
s390_iommu_aperture= [KNL,S390]
Specifies the size of the per device DMA address space
accessible through the DMA and IOMMU APIs as a decimal
factor of the size of main memory.
The default is 1 meaning that one can concurrently use
as many DMA addresses as physical memory is installed,
if supported by hardware, and thus map all of memory
once. With a value of 2 one can map all of memory twice
and so on. As a special case a factor of 0 imposes no
restrictions other than those given by hardware at the
cost of significant additional memory use for tables.
sa1100ir [NET]
See drivers/net/irda/sa1100_ir.c.
@ -5361,8 +5267,12 @@
Specific mitigations can also be selected manually:
retpoline - replace indirect branches
retpoline,generic - google's original retpoline
retpoline,amd - AMD-specific minimal thunk
retpoline,generic - Retpolines
retpoline,lfence - LFENCE; indirect branch
retpoline,amd - alias for retpoline,lfence
eibrs - enhanced IBRS
eibrs,retpoline - enhanced IBRS + Retpolines
eibrs,lfence - enhanced IBRS + LFENCE
Not specifying this option is equivalent to
spectre_v2=auto.
@ -5403,7 +5313,8 @@
auto - Kernel selects the mitigation depending on
the available CPU features and vulnerability.
Default mitigation: "prctl"
Default mitigation:
If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
Not specifying this option is equivalent to
spectre_v2_user=auto.
@ -5447,7 +5358,7 @@
will disable SSB unless they explicitly opt out.
Default mitigations:
X86: "prctl"
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
On powerpc the options are:
@ -5596,15 +5507,6 @@
stifb= [HW]
Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]]
strict_sas_size=
[X86]
Format: <bool>
Enable or disable strict sigaltstack size checks
against the required signal frame size which
depends on the supported FPU features. This can
be used to filter out binaries which have
not yet been made aware of AT_MINSIGSTKSZ.
sunrpc.min_resvport=
sunrpc.max_resvport=
[NFS,SUNRPC]
@ -6502,12 +6404,6 @@
controller on both pseries and powernv
platforms. Only useful on POWER9 and above.
xive.store-eoi=off [PPC]
By default on POWER10 and above, the kernel will use
stores for EOI handling when the XIVE interrupt mode
is active. This option allows the XIVE driver to use
loads instead, as on POWER9.
xhci-hcd.quirks [USB,KNL]
A hex value specifying bitmask with supplemental xhci
host controller quirks. Meaning of each bit can be

2
Documentation/admin-guide/kernel-per-CPU-kthreads.rst
View File

@ -208,7 +208,7 @@ Do at least one of the following:
2. Enable RCU to do its processing remotely via dyntick-idle by
doing all of the following:
a. Build with CONFIG_NO_HZ=y.
a. Build with CONFIG_NO_HZ=y and CONFIG_RCU_FAST_NO_HZ=y.
b. Ensure that the CPU goes idle frequently, allowing other
CPUs to detect that it has passed through an RCU quiescent
state. If the kernel is built with CONFIG_NO_HZ_FULL=y,

12
Documentation/admin-guide/laptops/thinkpad-acpi.rst
View File

@ -1520,15 +1520,15 @@ This sysfs attribute controls the keyboard "face" that will be shown on the
Lenovo X1 Carbon 2nd gen (2014)'s adaptive keyboard. The value can be read
and set.
- 0 = Home mode
- 1 = Web-browser mode
- 2 = Web-conference mode
- 3 = Function mode
- 4 = Layflat mode
- 1 = Home mode
- 2 = Web-browser mode
- 3 = Web-conference mode
- 4 = Function mode
- 5 = Layflat mode
For more details about which buttons will appear depending on the mode, please
review the laptop's user guide:
https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/x1carbon_2_ug_en.pdf
http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf
Battery charge control
----------------------

8
Documentation/admin-guide/media/i2c-cardlist.rst
View File

@ -58,20 +58,15 @@ Camera sensor devices
============ ==========================================================
Driver Name
============ ==========================================================
ccs MIPI CCS compliant camera sensors (also SMIA++ and SMIA)
et8ek8 ET8EK8 camera sensor
hi556 Hynix Hi-556 sensor
hi846 Hynix Hi-846 sensor
imx208 Sony IMX208 sensor
imx214 Sony IMX214 sensor
imx219 Sony IMX219 sensor
imx258 Sony IMX258 sensor
imx274 Sony IMX274 sensor
imx290 Sony IMX290 sensor
imx319 Sony IMX319 sensor
imx334 Sony IMX334 sensor
imx355 Sony IMX355 sensor
imx412 Sony IMX412 sensor
m5mols Fujitsu M-5MOLS 8MP sensor
mt9m001 mt9m001
mt9m032 MT9M032 camera sensor
@ -84,7 +79,6 @@ mt9v032 Micron MT9V032 sensor
mt9v111 Aptina MT9V111 sensor
noon010pc30 Siliconfile NOON010PC30 sensor
ov13858 OmniVision OV13858 sensor
ov13b10 OmniVision OV13B10 sensor
ov2640 OmniVision OV2640 sensor
ov2659 OmniVision OV2659 sensor
ov2680 OmniVision OV2680 sensor
@ -110,6 +104,7 @@ s5k4ecgx Samsung S5K4ECGX sensor
s5k5baf Samsung S5K5BAF sensor
s5k6a3 Samsung S5K6A3 sensor
s5k6aa Samsung S5K6AAFX sensor
smiapp SMIA++/SMIA sensor
sr030pc30 Siliconfile SR030PC30 sensor
vs6624 ST VS6624 sensor
============ ==========================================================
@ -143,7 +138,6 @@ Driver Name
ad5820 AD5820 lens voice coil
ak7375 AK7375 lens voice coil
dw9714 DW9714 lens voice coil
dw9768 DW9768 lens voice coil
dw9807-vcm DW9807 lens voice coil
============ ==========================================================

60
Documentation/admin-guide/media/imx7.rst
View File

@ -155,66 +155,6 @@ the resolutions supported by the sensor.
[fmt:SBGGR10_1X10/800x600@1/30 field:none colorspace:srgb]
-> "imx7-mipi-csis.0":0 [ENABLED]
i.MX6ULL-EVK with OV5640
------------------------
On this platform a parallel OV5640 sensor is connected to the CSI port.
The following example configures a video capture pipeline with an output
of 640x480 and UYVY8_2X8 format:
.. code-block:: none
# Setup links
media-ctl -l "'ov5640 1-003c':0 -> 'csi':0[1]"
media-ctl -l "'csi':1 -> 'csi capture':0[1]"
# Configure pads for pipeline
media-ctl -v -V "'ov5640 1-003c':0 [fmt:UYVY8_2X8/640x480 field:none]"
After this streaming can start:
.. code-block:: none
gst-launch-1.0 -v v4l2src device=/dev/video1 ! video/x-raw,format=UYVY,width=640,height=480 ! v4l2convert ! fbdevsink
.. code-block:: none
# media-ctl -p
Media controller API version 5.14.0
Media device information
------------------------
driver imx7-csi
model imx-media
serial
bus info
hw revision 0x0
driver version 5.14.0
Device topology
- entity 1: csi (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
<- "ov5640 1-003c":0 [ENABLED,IMMUTABLE]
pad1: Source
[fmt:UYVY8_2X8/640x480 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
-> "csi capture":0 [ENABLED,IMMUTABLE]
- entity 4: csi capture (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
<- "csi":1 [ENABLED,IMMUTABLE]
- entity 10: ov5640 1-003c (1 pad, 1 link)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev1
pad0: Source
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range]
-> "csi":0 [ENABLED,IMMUTABLE]
References
----------

14
Documentation/admin-guide/media/ipu3.rst
View File

@ -51,11 +51,10 @@ to userspace as a V4L2 sub-device node and has two pads:
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|
.. flat-table::
:header-rows: 1
* - Pad
- Direction
- Purpose
* - pad
- direction
- purpose
* - 0
- sink
@ -149,11 +148,10 @@ Each pipe has two sink pads and three source pads for the following purpose:
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|
.. flat-table::
:header-rows: 1
* - Pad
- Direction
- Purpose
* - pad
- direction
- purpose
* - 0
- sink

2
Documentation/admin-guide/media/ivtv.rst
View File

@ -159,7 +159,7 @@ whatever). Otherwise the device numbers can get confusing. The ivtv
Read-only
The raw YUV video output from the current video input. The YUV format
is a 16x16 linear tiled NV12 format (V4L2_PIX_FMT_NV12_16L16)
is non-standard (V4L2_PIX_FMT_HM12).
Note that the YUV and PCM streams are not synchronized, so they are of
limited use.

1
Documentation/admin-guide/media/platform-cardlist.rst
View File

@ -60,7 +60,6 @@ s5p-mfc Samsung S5P MFC Video Codec
sh_veu SuperH VEU mem2mem video processing
sh_vou SuperH VOU video output
stm32-dcmi STM32 Digital Camera Memory Interface (DCMI)
stm32-dma2d STM32 Chrom-Art Accelerator Unit
sun4i-csi Allwinner A10 CMOS Sensor Interface Support
sun6i-csi Allwinner V3s Camera Sensor Interface
sun8i-di Allwinner Deinterlace

20
Documentation/admin-guide/media/vimc.rst
View File

@ -61,10 +61,9 @@ vimc-debayer:
* 1 Pad source
vimc-scaler:
Re-size the image to meet the source pad resolution. E.g.: if the sync
pad is configured to 360x480 and the source to 1280x720, the image will
be stretched to fit the source resolution. Works for any resolution
within the vimc limitations (even shrinking the image if necessary).
Scale up the image by a factor of 3. E.g.: a 640x480 image becomes a
1920x1440 image. (this value can be configured, see at
`Module options`_).
Exposes:
* 1 Pad sink
@ -76,3 +75,16 @@ vimc-capture:
* 1 Pad sink
* 1 Pad source
Module options
--------------
Vimc has a module parameter to configure the driver.
* ``sca_mult=<unsigned int>``
Image size multiplier factor to be used to multiply both width and
height, so the image size will be ``sca_mult^2`` bigger than the
original one. Currently, only supports scaling up (the default value
is 3).

1
Documentation/admin-guide/mm/damon/index.rst
View File

@ -13,4 +13,3 @@ optimize those.
start
usage
reclaim

120
Documentation/admin-guide/mm/damon/start.rst
View File

@ -6,9 +6,39 @@ Getting Started
This document briefly describes how you can use DAMON by demonstrating its
default user space tool. Please note that this document describes only a part
of its features for brevity. Please refer to the usage `doc
<https://github.com/awslabs/damo/blob/next/USAGE.md>`_ of the tool for more
details.
of its features for brevity. Please refer to :doc:`usage` for more details.
TL; DR
======
Follow the commands below to monitor and visualize the memory access pattern of
your workload. ::
# # build the kernel with CONFIG_DAMON_*=y, install it, and reboot
# mount -t debugfs none /sys/kernel/debug/
# git clone https://github.com/awslabs/damo
# ./damo/damo record $(pidof <your workload>)
# ./damo/damo report heat --plot_ascii
The final command draws the access heatmap of ``<your workload>``. The heatmap
shows which memory region (x-axis) is accessed when (y-axis) and how frequently
(number; the higher the more accesses have been observed). ::
111111111111111111111111111111111111111111111111111111110000
111121111111111111111111111111211111111111111111111111110000
000000000000000000000000000000000000000000000000001555552000
000000000000000000000000000000000000000000000222223555552000
000000000000000000000000000000000000000011111677775000000000
000000000000000000000000000000000000000488888000000000000000
000000000000000000000000000000000177888400000000000000000000
000000000000000000000000000046666522222100000000000000000000
000000000000000000000014444344444300000000000000000000000000
000000000000000002222245555510000000000000000000000000000000
# access_frequency: 0 1 2 3 4 5 6 7 8 9
# x-axis: space (140286319947776-140286426374096: 101.496 MiB)
# y-axis: time (605442256436361-605479951866441: 37.695430s)
# resolution: 60x10 (1.692 MiB and 3.770s for each character)
Prerequisites
@ -61,74 +91,24 @@ pattern in the ``damon.data`` file.
Visualizing Recorded Patterns
=============================
You can visualize the pattern in a heatmap, showing which memory region
(x-axis) got accessed when (y-axis) and how frequently (number).::
The following three commands visualize the recorded access patterns and save
the results as separate image files. ::
$ sudo damo report heats --heatmap stdout
22222222222222222222222222222222222222211111111111111111111111111111111111111100
44444444444444444444444444444444444444434444444444444444444444444444444444443200
44444444444444444444444444444444444444433444444444444444444444444444444444444200
33333333333333333333333333333333333333344555555555555555555555555555555555555200
33333333333333333333333333333333333344444444444444444444444444444444444444444200
22222222222222222222222222222222222223355555555555555555555555555555555555555200
00000000000000000000000000000000000000288888888888888888888888888888888888888400
00000000000000000000000000000000000000288888888888888888888888888888888888888400
33333333333333333333333333333333333333355555555555555555555555555555555555555200
88888888888888888888888888888888888888600000000000000000000000000000000000000000
88888888888888888888888888888888888888600000000000000000000000000000000000000000
33333333333333333333333333333333333333444444444444444444444444444444444444443200
00000000000000000000000000000000000000288888888888888888888888888888888888888400
[...]
# access_frequency: 0 1 2 3 4 5 6 7 8 9
# x-axis: space (139728247021568-139728453431248: 196.848 MiB)
# y-axis: time (15256597248362-15326899978162: 1 m 10.303 s)
# resolution: 80x40 (2.461 MiB and 1.758 s for each character)
$ damo report heats --heatmap access_pattern_heatmap.png
$ damo report wss --range 0 101 1 --plot wss_dist.png
$ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png
You can also visualize the distribution of the working set size, sorted by the
size.::
- ``access_pattern_heatmap.png`` will visualize the data access pattern in a
heatmap, showing which memory region (y-axis) got accessed when (x-axis)
and how frequently (color).
- ``wss_dist.png`` will show the distribution of the working set size.
- ``wss_chron_change.png`` will show how the working set size has
chronologically changed.
$ sudo damo report wss --range 0 101 10
# <percentile> <wss>
# target_id 18446632103789443072
# avr: 107.708 MiB
0 0 B | |
10 95.328 MiB |**************************** |
20 95.332 MiB |**************************** |
30 95.340 MiB |**************************** |
40 95.387 MiB |**************************** |
50 95.387 MiB |**************************** |
60 95.398 MiB |**************************** |
70 95.398 MiB |**************************** |
80 95.504 MiB |**************************** |
90 190.703 MiB |********************************************************* |
100 196.875 MiB |***********************************************************|
You can view the visualizations of this example workload at [1]_.
Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_.
Using ``--sortby`` option with the above command, you can show how the working
set size has chronologically changed.::
$ sudo damo report wss --range 0 101 10 --sortby time
# <percentile> <wss>
# target_id 18446632103789443072
# avr: 107.708 MiB
0 3.051 MiB | |
10 190.703 MiB |***********************************************************|
20 95.336 MiB |***************************** |
30 95.328 MiB |***************************** |
40 95.387 MiB |***************************** |
50 95.332 MiB |***************************** |
60 95.320 MiB |***************************** |
70 95.398 MiB |***************************** |
80 95.398 MiB |***************************** |
90 95.340 MiB |***************************** |
100 95.398 MiB |***************************** |
Data Access Pattern Aware Memory Management
===========================================
Below three commands make every memory region of size >=4K that doesn't
accessed for >=60 seconds in your workload to be swapped out. ::
$ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme
$ echo "4K max 0 0 60s max pageout" >> test_scheme
$ damo schemes -c test_scheme <pid of your workload>
.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns
.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html
.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html
.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html

270
Documentation/admin-guide/mm/damon/usage.rst
View File

@ -7,40 +7,35 @@ Detailed Usages
DAMON provides below three interfaces for different users.
- *DAMON user space tool.*
`This <https://github.com/awslabs/damo>`_ is for privileged people such as
system administrators who want a just-working human-friendly interface.
Using this, users can use the DAMON’s major features in a human-friendly way.
It may not be highly tuned for special cases, though. It supports both
virtual and physical address spaces monitoring. For more detail, please
refer to its `usage document
<https://github.com/awslabs/damo/blob/next/USAGE.md>`_.
This is for privileged people such as system administrators who want a
just-working human-friendly interface. Using this, users can use the DAMON’s
major features in a human-friendly way. It may not be highly tuned for
special cases, though. It supports only virtual address spaces monitoring.
- *debugfs interface.*
:ref:`This <debugfs_interface>` is for privileged user space programmers who
want more optimized use of DAMON. Using this, users can use DAMON’s major
features by reading from and writing to special debugfs files. Therefore,
you can write and use your personalized DAMON debugfs wrapper programs that
reads/writes the debugfs files instead of you. The `DAMON user space tool
<https://github.com/awslabs/damo>`_ is one example of such programs. It
supports both virtual and physical address spaces monitoring. Note that this
interface provides only simple :ref:`statistics <damos_stats>` for the
monitoring results. For detailed monitoring results, DAMON provides a
:ref:`tracepoint <tracepoint>`.
This is for privileged user space programmers who want more optimized use of
DAMON. Using this, users can use DAMON’s major features by reading
from and writing to special debugfs files. Therefore, you can write and use
your personalized DAMON debugfs wrapper programs that reads/writes the
debugfs files instead of you. The DAMON user space tool is also a reference
implementation of such programs. It supports only virtual address spaces
monitoring.
- *Kernel Space Programming Interface.*
:doc:`This </vm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </vm/damon/api>`.
This is for kernel space programmers. Using this, users can utilize every
feature of DAMON most flexibly and efficiently by writing kernel space
DAMON application programs for you. You can even extend DAMON for various
address spaces.
.. _debugfs_interface:
Nevertheless, you could write your own user space tool using the debugfs
interface. A reference implementation is available at
https://github.com/awslabs/damo. If you are a kernel programmer, you could
refer to :doc:`/vm/damon/api` for the kernel space programming interface. For
the reason, this document describes only the debugfs interface
debugfs Interface
=================
DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under
its debugfs directory, ``<debugfs>/damon/``.
Attributes
@ -76,182 +71,9 @@ check it again::
# cat target_ids
42 4242
Users can also monitor the physical memory address space of the system by
writing a special keyword, "``paddr\n``" to the file. Because physical address
space monitoring doesn't support multiple targets, reading the file will show a
fake value, ``42``, as below::
# cd <debugfs>/damon
# echo paddr > target_ids
# cat target_ids
42
Note that setting the target ids doesn't start the monitoring.
Initial Monitoring Target Regions
---------------------------------
In case of the virtual address space monitoring, DAMON automatically sets and
updates the monitoring target regions so that entire memory mappings of target
processes can be covered. However, users can want to limit the monitoring
region to specific address ranges, such as the heap, the stack, or specific
file-mapped area. Or, some users can know the initial access pattern of their
workloads and therefore want to set optimal initial regions for the 'adaptive
regions adjustment'.
In contrast, DAMON do not automatically sets and updates the monitoring target
regions in case of physical memory monitoring. Therefore, users should set the
monitoring target regions by themselves.
In such cases, users can explicitly set the initial monitoring target regions
as they want, by writing proper values to the ``init_regions`` file. Each line
of the input should represent one region in below form.::
<target id> <start address> <end address>
The ``target id`` should already in ``target_ids`` file, and the regions should
be passed in address order. For example, below commands will set a couple of
address ranges, ``1-100`` and ``100-200`` as the initial monitoring target
region of process 42, and another couple of address ranges, ``20-40`` and
``50-100`` as that of process 4242.::
# cd <debugfs>/damon
# echo "42 1 100
42 100 200
4242 20 40
4242 50 100" > init_regions
Note that this sets the initial monitoring target regions only. In case of
virtual memory monitoring, DAMON will automatically updates the boundary of the
regions after one ``regions update interval``. Therefore, users should set the
``regions update interval`` large enough in this case, if they don't want the
update.
Schemes
-------
For usual DAMON-based data access aware memory management optimizations, users
would simply want the system to apply a memory management action to a memory
region of a specific access pattern. DAMON receives such formalized operation
schemes from the user and applies those to the target processes.
Users can get and set the schemes by reading from and writing to ``schemes``
debugfs file. Reading the file also shows the statistics of each scheme. To
the file, each of the schemes should be represented in each line in below
form::
<target access pattern> <action> <quota> <watermarks>
You can disable schemes by simply writing an empty string to the file.
Target Access Pattern
~~~~~~~~~~~~~~~~~~~~~
The ``<target access pattern>`` is constructed with three ranges in below
form::
min-size max-size min-acc max-acc min-age max-age
Specifically, bytes for the size of regions (``min-size`` and ``max-size``),
number of monitored accesses per aggregate interval for access frequency
(``min-acc`` and ``max-acc``), number of aggregate intervals for the age of
regions (``min-age`` and ``max-age``) are specified. Note that the ranges are
closed interval.
Action
~~~~~~
The ``<action>`` is a predefined integer for memory management actions, which
DAMON will apply to the regions having the target access pattern. The
supported numbers and their meanings are as below.
- 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``
- 1: Call ``madvise()`` for the region with ``MADV_COLD``
- 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
- 5: Do nothing but count the statistics
Quota
~~~~~
Optimal ``target access pattern`` for each ``action`` is workload dependent, so
not easy to find. Worse yet, setting a scheme of some action too aggressive
can cause severe overhead. To avoid such overhead, users can limit time and
size quota for the scheme via the ``<quota>`` in below form::
<ms> <sz> <reset interval> <priority weights>
This makes DAMON to try to use only up to ``<ms>`` milliseconds for applying
the action to memory regions of the ``target access pattern`` within the
``<reset interval>`` milliseconds, and to apply the action to only up to
``<sz>`` bytes of memory regions within the ``<reset interval>``. Setting both
``<ms>`` and ``<sz>`` zero disables the quota limits.
When the quota limit is expected to be exceeded, DAMON prioritizes found memory
regions of the ``target access pattern`` based on their size, access frequency,
and age. For personalized prioritization, users can set the weights for the
three properties in ``<priority weights>`` in below form::
<size weight> <access frequency weight> <age weight>
Watermarks
~~~~~~~~~~
Some schemes would need to run based on current value of the system's specific
metrics like free memory ratio. For such cases, users can specify watermarks
for the condition.::
<metric> <check interval> <high mark> <middle mark> <low mark>
``<metric>`` is a predefined integer for the metric to be checked. The
supported numbers and their meanings are as below.
- 0: Ignore the watermarks
- 1: System's free memory rate (per thousand)
The value of the metric is checked every ``<check interval>`` microseconds.
If the value is higher than ``<high mark>`` or lower than ``<low mark>``, the
scheme is deactivated. If the value is lower than ``<mid mark>``, the scheme
is activated.
.. _damos_stats:
Statistics
~~~~~~~~~~
It also counts the total number and bytes of regions that each scheme is tried
to be applied, the two numbers for the regions that each scheme is successfully
applied, and the total number of the quota limit exceeds. This statistics can
be used for online analysis or tuning of the schemes.
The statistics can be shown by reading the ``schemes`` file. Reading the file
will show each scheme you entered in each line, and the five numbers for the
statistics will be added at the end of each line.
Example
~~~~~~~
Below commands applies a scheme saying "If a memory region of size in [4KiB,
8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate
interval in [10, 20], page out the region. For the paging out, use only up to
10ms per second, and also don't page out more than 1GiB per second. Under the
limitation, page out memory regions having longer age first. Also, check the
free memory rate of the system every 5 seconds, start the monitoring and paging
out when the free memory rate becomes lower than 50%, but stop it if the free
memory rate becomes larger than 60%, or lower than 30%".::
# cd <debugfs>/damon
# scheme="4096 8192 0 5 10 20 2" # target access pattern and action
# scheme+=" 10 $((1024*1024*1024)) 1000" # quotas
# scheme+=" 0 0 100" # prioritization weights
# scheme+=" 1 5000000 600 500 300" # watermarks
# echo "$scheme" > schemes
Turning On/Off
--------------
@ -274,54 +96,6 @@ the monitoring is turned on. If you write to the files while DAMON is running,
an error code such as ``-EBUSY`` will be returned.
Monitoring Thread PID
---------------------
DAMON does requested monitoring with a kernel thread called ``kdamond``. You
can get the pid of the thread by reading the ``kdamond_pid`` file. When the
monitoring is turned off, reading the file returns ``none``. ::
# cd <debugfs>/damon
# cat monitor_on
off
# cat kdamond_pid
none
# echo on > monitor_on
# cat kdamond_pid
18594
Using Multiple Monitoring Threads
---------------------------------
One ``kdamond`` thread is created for each monitoring context. You can create
and remove monitoring contexts for multiple ``kdamond`` required use case using
the ``mk_contexts`` and ``rm_contexts`` files.
Writing the name of the new context to the ``mk_contexts`` file creates a
directory of the name on the DAMON debugfs directory. The directory will have
DAMON debugfs files for the context. ::
# cd <debugfs>/damon
# ls foo
# ls: cannot access 'foo': No such file or directory
# echo foo > mk_contexts
# ls foo
# attrs init_regions kdamond_pid schemes target_ids
If the context is not needed anymore, you can remove it and the corresponding
directory by putting the name of the context to the ``rm_contexts`` file. ::
# echo foo > rm_contexts
# ls foo
# ls: cannot access 'foo': No such file or directory
Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on`` files are in the
root directory only.
.. _tracepoint:
Tracepoint for Monitoring Results
=================================

42
Documentation/admin-guide/mm/hugetlbpage.rst
View File

@ -128,9 +128,7 @@ hugepages
implicitly specifies the number of huge pages of default size to
allocate. If the number of huge pages of default size is implicitly
specified, it can not be overwritten by a hugepagesz,hugepages
parameter pair for the default size. This parameter also has a
node format. The node format specifies the number of huge pages
to allocate on specific nodes.
parameter pair for the default size.
For example, on an architecture with 2M default huge page size::
@ -140,14 +138,6 @@ hugepages
indicating that the hugepages=512 parameter is ignored. If a hugepages
parameter is preceded by an invalid hugepagesz parameter, it will
be ignored.
Node format example::
hugepagesz=2M hugepages=0:1,1:2
It will allocate 1 2M hugepage on node0 and 2 2M hugepages on node1.
If the node number is invalid, the parameter will be ignored.
default_hugepagesz
Specify the default huge page size. This parameter can
only be specified once on the command line. default_hugepagesz can
@ -244,12 +234,8 @@ will exist, of the form::
hugepages-${size}kB
Inside each of these directories, the set of files contained in ``/proc``
will exist. In addition, two additional interfaces for demoting huge
pages may exist::
Inside each of these directories, the same set of files will exist::
demote
demote_size
nr_hugepages
nr_hugepages_mempolicy
nr_overcommit_hugepages
@ -257,29 +243,7 @@ pages may exist::
resv_hugepages
surplus_hugepages
The demote interfaces provide the ability to split a huge page into
smaller huge pages. For example, the x86 architecture supports both
1GB and 2MB huge pages sizes. A 1GB huge page can be split into 512
2MB huge pages. Demote interfaces are not available for the smallest
huge page size. The demote interfaces are:
demote_size
is the size of demoted pages. When a page is demoted a corresponding
number of huge pages of demote_size will be created. By default,
demote_size is set to the next smaller huge page size. If there are
multiple smaller huge page sizes, demote_size can be set to any of
these smaller sizes. Only huge page sizes less than the current huge
pages size are allowed.
demote
is used to demote a number of huge pages. A user with root privileges
can write to this file. It may not be possible to demote the
requested number of huge pages. To determine how many pages were
actually demoted, compare the value of nr_hugepages before and after
writing to the demote interface. demote is a write only interface.
The interfaces which are the same as in ``/proc`` (all except demote and
demote_size) function as described above for the default huge page-sized case.
which function as described above for the default huge page-sized case.
.. _mem_policy_and_hp_alloc:

2
Documentation/admin-guide/mm/index.rst
View File

@ -37,7 +37,5 @@ the Linux memory management.
numaperf
pagemap
soft-dirty
swap_numa
transhuge
userfaultfd
zswap

141
Documentation/admin-guide/mm/memory-hotplug.rst
View File

@ -165,8 +165,9 @@ Or alternatively::
% echo 1 > /sys/devices/system/memory/memoryXXX/online
The kernel will select the target zone automatically, depending on the
configured ``online_policy``.
The kernel will select the target zone automatically, usually defaulting to
``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel
command line or if the memory block would intersect the ZONE_MOVABLE already.
One can explicitly request to associate an offline memory block with
ZONE_MOVABLE by::
@ -197,9 +198,6 @@ Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or
% echo online > /sys/devices/system/memory/auto_online_blocks
Similarly to manual onlining, with ``online`` the kernel will select the
target zone automatically, depending on the configured ``online_policy``.
Modifying the auto-online behavior will only affect all subsequently added
memory blocks only.
@ -395,16 +393,11 @@ command line parameters are relevant:
======================== =======================================================
``memhp_default_state`` configure auto-onlining by essentially setting
``/sys/devices/system/memory/auto_online_blocks``.
``movable_node`` configure automatic zone selection in the kernel when
using the ``contig-zones`` online policy. When
set, the kernel will default to ZONE_MOVABLE when
onlining a memory block, unless other zones can be kept
contiguous.
``movablecore`` configure automatic zone selection of the kernel. When
set, the kernel will default to ZONE_MOVABLE, unless
other zones can be kept contiguous.
======================== =======================================================
See Documentation/admin-guide/kernel-parameters.txt for a more generic
description of these command line parameters.
Module Parameters
------------------
@ -417,118 +410,24 @@ them with ``memory_hotplug.`` such as::
and they can be observed (and some even modified at runtime) via::
/sys/module/memory_hotplug/parameters/
/sys/modules/memory_hotplug/parameters/
The following module parameters are currently defined:
================================ ===============================================
``memmap_on_memory`` read-write: Allocate memory for the memmap from
the added memory block itself. Even if enabled,
actual support depends on various other system
properties and should only be regarded as a
hint whether the behavior would be desired.
======================== =======================================================
``memmap_on_memory`` read-write: Allocate memory for the memmap from the
added memory block itself. Even if enabled, actual
support depends on various other system properties and
should only be regarded as a hint whether the behavior
would be desired.
While allocating the memmap from the memory
block itself makes memory hotplug less likely
to fail and keeps the memmap on the same NUMA
node in any case, it can fragment physical
memory in a way that huge pages in bigger
granularity cannot be formed on hotplugged
memory.
``online_policy`` read-write: Set the basic policy used for
automatic zone selection when onlining memory
blocks without specifying a target zone.
``contig-zones`` has been the kernel default
before this parameter was added. After an
online policy was configured and memory was
online, the policy should not be changed
anymore.
When set to ``contig-zones``, the kernel will
try keeping zones contiguous. If a memory block
intersects multiple zones or no zone, the
behavior depends on the ``movable_node`` kernel
command line parameter: default to ZONE_MOVABLE
if set, default to the applicable kernel zone
(usually ZONE_NORMAL) if not set.
When set to ``auto-movable``, the kernel will
try onlining memory blocks to ZONE_MOVABLE if
possible according to the configuration and
memory device details. With this policy, one
can avoid zone imbalances when eventually
hotplugging a lot of memory later and still
wanting to be able to hotunplug as much as
possible reliably, very desirable in
virtualized environments. This policy ignores
the ``movable_node`` kernel command line
parameter and isn't really applicable in
environments that require it (e.g., bare metal
with hotunpluggable nodes) where hotplugged
memory might be exposed via the
firmware-provided memory map early during boot
to the system instead of getting detected,
added and onlined later during boot (such as
done by virtio-mem or by some hypervisors
implementing emulated DIMMs). As one example, a
hotplugged DIMM will be onlined either
completely to ZONE_MOVABLE or completely to
ZONE_NORMAL, not a mixture.
As another example, as many memory blocks
belonging to a virtio-mem device will be
onlined to ZONE_MOVABLE as possible,
special-casing units of memory blocks that can
only get hotunplugged together. *This policy
does not protect from setups that are
problematic with ZONE_MOVABLE and does not
change the zone of memory blocks dynamically
after they were onlined.*
``auto_movable_ratio`` read-write: Set the maximum MOVABLE:KERNEL
memory ratio in % for the ``auto-movable``
online policy. Whether the ratio applies only
for the system across all NUMA nodes or also
per NUMA nodes depends on the
``auto_movable_numa_aware`` configuration.
All accounting is based on present memory pages
in the zones combined with accounting per
memory device. Memory dedicated to the CMA
allocator is accounted as MOVABLE, although
residing on one of the kernel zones. The
possible ratio depends on the actual workload.
The kernel default is "301" %, for example,
allowing for hotplugging 24 GiB to a 8 GiB VM
and automatically onlining all hotplugged
memory to ZONE_MOVABLE in many setups. The
additional 1% deals with some pages being not
present, for example, because of some firmware
allocations.
Note that ZONE_NORMAL memory provided by one
memory device does not allow for more
ZONE_MOVABLE memory for a different memory
device. As one example, onlining memory of a
hotplugged DIMM to ZONE_NORMAL will not allow
for another hotplugged DIMM to get onlined to
ZONE_MOVABLE automatically. In contrast, memory
hotplugged by a virtio-mem device that got
onlined to ZONE_NORMAL will allow for more
ZONE_MOVABLE memory within *the same*
virtio-mem device.
``auto_movable_numa_aware`` read-write: Configure whether the
``auto_movable_ratio`` in the ``auto-movable``
online policy also applies per NUMA
node in addition to the whole system across all
NUMA nodes. The kernel default is "Y".
Disabling NUMA awareness can be helpful when
dealing with NUMA nodes that should be
completely hotunpluggable, onlining the memory
completely to ZONE_MOVABLE automatically if
possible.
Parameter availability depends on CONFIG_NUMA.
================================ ===============================================
While allocating the memmap from the memory block
itself makes memory hotplug less likely to fail and
keeps the memmap on the same NUMA node in any case, it
can fragment physical memory in a way that huge pages
in bigger granularity cannot be formed on hotplugged
memory.
======================== =======================================================
ZONE_MOVABLE
============

16
Documentation/admin-guide/mm/numa_memory_policy.rst
View File

@ -408,7 +408,7 @@ follows:
Memory Policy APIs
==================
Linux supports 4 system calls for controlling memory policy. These APIS
Linux supports 3 system calls for controlling memory policy. These APIS
always affect only the calling task, the calling task's address space, or
some shared object mapped into the calling task's address space.
@ -460,20 +460,6 @@ requested via the 'flags' argument.
See the mbind(2) man page for more details.
Set home node for a Range of Task's Address Spacec::
long sys_set_mempolicy_home_node(unsigned long start, unsigned long len,
unsigned long home_node,
unsigned long flags);
sys_set_mempolicy_home_node set the home node for a VMA policy present in the
task's address range. The system call updates the home node only for the existing
mempolicy range. Other address ranges are ignored. A home node is the NUMA node
closest to which page allocation will come from. Specifying the home node override
the default allocation policy to allocate memory close to the local node for an
executing CPU.
Memory Policy Command Line Interface
====================================

77
Documentation/admin-guide/mm/pagemap.rst
View File

@ -23,7 +23,7 @@ There are four components to pagemap:
* Bit 56 page exclusively mapped (since 4.2)
* Bit 57 pte is uffd-wp write-protected (since 5.13) (see
:ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`)
* Bits 57-60 zero
* Bits 58-60 zero
* Bit 61 page is file-page or shared-anon (since 3.5)
* Bit 62 page swapped
* Bit 63 page present
@ -90,14 +90,13 @@ Short descriptions to the page flags
====================================
0 - LOCKED
The page is being locked for exclusive access, e.g. by undergoing read/write
IO.
page is being locked for exclusive access, e.g. by undergoing read/write IO
7 - SLAB
The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator.
page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator
When compound page is used, SLUB/SLQB will only set this flag on the head
page; SLOB will not flag it at all.
10 - BUDDY
A free memory block managed by the buddy system allocator.
a free memory block managed by the buddy system allocator
The buddy system organizes free memory in blocks of various orders.
An order N block has 2^N physically contiguous pages, with the BUDDY flag
set for and _only_ for the first page.
@ -113,65 +112,65 @@ Short descriptions to the page flags
16 - COMPOUND_TAIL
A compound page tail (see description above).
17 - HUGE
This is an integral part of a HugeTLB page.
this is an integral part of a HugeTLB page
19 - HWPOISON
Hardware detected memory corruption on this page: don't touch the data!
hardware detected memory corruption on this page: don't touch the data!
20 - NOPAGE
No page frame exists at the requested address.
no page frame exists at the requested address
21 - KSM
Identical memory pages dynamically shared between one or more processes.
identical memory pages dynamically shared between one or more processes
22 - THP
Contiguous pages which construct transparent hugepages.
contiguous pages which construct transparent hugepages
23 - OFFLINE
The page is logically offline.
page is logically offline
24 - ZERO_PAGE
Zero page for pfn_zero or huge_zero page.
zero page for pfn_zero or huge_zero page
25 - IDLE
The page has not been accessed since it was marked idle (see
page has not been accessed since it was marked idle (see
:ref:`Documentation/admin-guide/mm/idle_page_tracking.rst <idle_page_tracking>`).
Note that this flag may be stale in case the page was accessed via
a PTE. To make sure the flag is up-to-date one has to read
``/sys/kernel/mm/page_idle/bitmap`` first.
26 - PGTABLE
The page is in use as a page table.
page is in use as a page table
IO related page flags
---------------------
1 - ERROR
IO error occurred.
IO error occurred
3 - UPTODATE
The page has up-to-date data.
page has up-to-date data
ie. for file backed page: (in-memory data revision >= on-disk one)
4 - DIRTY
The page has been written to, hence contains new data.
page has been written to, hence contains new data
i.e. for file backed page: (in-memory data revision > on-disk one)
8 - WRITEBACK
The page is being synced to disk.
page is being synced to disk
LRU related page flags
----------------------
5 - LRU
The page is in one of the LRU lists.
page is in one of the LRU lists
6 - ACTIVE
The page is in the active LRU list.
page is in the active LRU list
18 - UNEVICTABLE
The page is in the unevictable (non-)LRU list It is somehow pinned and
page is in the unevictable (non-)LRU list It is somehow pinned and
not a candidate for LRU page reclaims, e.g. ramfs pages,
shmctl(SHM_LOCK) and mlock() memory segments.
shmctl(SHM_LOCK) and mlock() memory segments
2 - REFERENCED
The page has been referenced since last LRU list enqueue/requeue.
page has been referenced since last LRU list enqueue/requeue
9 - RECLAIM
The page will be reclaimed soon after its pageout IO completed.
page will be reclaimed soon after its pageout IO completed
11 - MMAP
A memory mapped page.
a memory mapped page
12 - ANON
A memory mapped page that is not part of a file.
a memory mapped page that is not part of a file
13 - SWAPCACHE
The page is mapped to swap space, i.e. has an associated swap entry.
page is mapped to swap space, i.e. has an associated swap entry
14 - SWAPBACKED
The page is backed by swap/RAM.
page is backed by swap/RAM
The page-types tool in the tools/vm directory can be used to query the
above flags.
@ -197,28 +196,6 @@ you can go through every map in the process, find the PFNs, look those up
in kpagecount, and tally up the number of pages that are only referenced
once.
Exceptions for Shared Memory
============================
Page table entries for shared pages are cleared when the pages are zapped or
swapped out. This makes swapped out pages indistinguishable from never-allocated
ones.
In kernel space, the swap location can still be retrieved from the page cache.
However, values stored only on the normal PTE get lost irretrievably when the
page is swapped out (i.e. SOFT_DIRTY).
In user space, whether the page is present, swapped or none can be deduced with
the help of lseek and/or mincore system calls.
lseek() can differentiate between accessed pages (present or swapped out) and
holes (none/non-allocated) by specifying the SEEK_DATA flag on the file where
the pages are backed. For anonymous shared pages, the file can be found in
``/proc/pid/map_files/``.
mincore() can differentiate between pages in memory (present, including swap
cache) and out of memory (swapped out or none/non-allocated).
Other notes
===========

1
Documentation/admin-guide/pm/working-state.rst
View File

@ -11,7 +11,6 @@ Working-State Power Management
intel_idle
cpufreq
intel_pstate
amd-pstate
cpufreq_drivers
intel_epb
intel-speed-select

2
Documentation/admin-guide/ramoops.rst
View File

@ -69,7 +69,7 @@ Setting the ramoops parameters can be done in several different manners:
mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1
B. Use Device Tree bindings, as described in
``Documentation/devicetree/bindings/reserved-memory/ramoops.yaml``.
``Documentation/devicetree/bindings/reserved-memory/ramoops.txt``.
For example::
reserved-memory {

2
Documentation/admin-guide/spkguide.txt
View File

@ -543,7 +543,7 @@ As mentioned earlier, Speakup can either be completely compiled into the
kernel, with the exception of the help module, or it can be compiled as
a series of modules. When compiled as modules, Speakup will only be
able to speak some of the bootup messages if your system administrator
has configured the system to load the modules at boot time. The modules
has configured the system to load the modules at boo time. The modules
can be loaded after the file systems have been checked and mounted, or
from an initrd. There is a third possibility. Speakup can be compiled
with some components built into the kernel, and others as modules. As

11
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -905,17 +905,6 @@ enabled, otherwise writing to this file will return ``-EBUSY``.
The default value is 8.
perf_user_access (arm64 only)
=================================
Controls user space access for reading perf event counters. When set to 1,
user space can read performance monitor counter registers directly.
The default value is 0 (access disabled).
See Documentation/arm64/perf.rst for more information.
pid_max
=======

1
Documentation/arch.rst
View File

@ -9,7 +9,6 @@ implementation.
.. toctree::
:maxdepth: 2
arc/index
arm/index
arm64/index
ia64/index

100
Documentation/conf.py
View File

@ -208,86 +208,16 @@ highlight_language = 'none'
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
# Default theme
html_theme = 'sphinx_rtd_theme'
html_css_files = []
if "DOCS_THEME" in os.environ:
html_theme = os.environ["DOCS_THEME"]
if html_theme == 'sphinx_rtd_theme' or html_theme == 'sphinx_rtd_dark_mode':
# Read the Docs theme
try:
import sphinx_rtd_theme
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_css_files = [
'theme_overrides.css',
]
# Read the Docs dark mode override theme
if html_theme == 'sphinx_rtd_dark_mode':
try:
import sphinx_rtd_dark_mode
extensions.append('sphinx_rtd_dark_mode')
except ImportError:
html_theme == 'sphinx_rtd_theme'
if html_theme == 'sphinx_rtd_theme':
# Add color-specific RTD normal mode
html_css_files.append('theme_rtd_colors.css')
except ImportError:
html_theme = 'classic'
if "DOCS_CSS" in os.environ:
css = os.environ["DOCS_CSS"].split(" ")
for l in css:
html_css_files.append(l)
if major <= 1 and minor < 8:
html_context = {
'css_files': [],
}
for l in html_css_files:
html_context['css_files'].append('_static/' + l)
if html_theme == 'classic':
html_theme_options = {
'rightsidebar': False,
'stickysidebar': True,
'collapsiblesidebar': True,
'externalrefs': False,
'footerbgcolor': "white",
'footertextcolor': "white",
'sidebarbgcolor': "white",
'sidebarbtncolor': "black",
'sidebartextcolor': "black",
'sidebarlinkcolor': "#686bff",
'relbarbgcolor': "#133f52",
'relbartextcolor': "white",
'relbarlinkcolor': "white",
'bgcolor': "white",
'textcolor': "black",
'headbgcolor': "#f2f2f2",
'headtextcolor': "#20435c",
'headlinkcolor': "#c60f0f",
'linkcolor': "#355f7c",
'visitedlinkcolor': "#355f7c",
'codebgcolor': "#3f3f3f",
'codetextcolor': "white",
'bodyfont': "serif",
'headfont': "sans-serif",
}
sys.stderr.write("Using %s theme\n" % html_theme)
# The Read the Docs theme is available from
# - https://github.com/snide/sphinx_rtd_theme
# - https://pypi.python.org/pypi/sphinx_rtd_theme
# - python-sphinx-rtd-theme package (on Debian)
try:
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
except ImportError:
sys.stderr.write('Warning: The Sphinx \'sphinx_rtd_theme\' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme.\n')
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
@ -316,8 +246,15 @@ sys.stderr.write("Using %s theme\n" % html_theme)
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['sphinx-static']
html_context = {
'css_files': [
'_static/theme_overrides.css',
],
}
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
@ -416,9 +353,6 @@ latex_elements = {
\\setsansfont{DejaVu Sans}
\\setromanfont{DejaVu Serif}
\\setmonofont{DejaVu Sans Mono}
% Adjust \\headheight for fancyhdr
\\addtolength{\\headheight}{1.6pt}
\\addtolength{\\topmargin}{-1.6pt}
''',
}

6
Documentation/cpu-freq/core.rst
View File

@ -73,12 +73,12 @@ CPUFREQ_POSTCHANGE.
The third argument is a struct cpufreq_freqs with the following
values:
====== ======================================
policy a pointer to the struct cpufreq_policy
===== ===========================
cpu number of the affected CPU
old old frequency
new new frequency
flags flags of the cpufreq driver
====== ======================================
===== ===========================
3. CPUFreq Table Generation with Operating Performance Point (OPP)
==================================================================

3
Documentation/cpu-freq/cpu-drivers.rst
View File

@ -75,9 +75,6 @@ And optionally
.resume - A pointer to a per-policy resume function which is called
with interrupts disabled and _before_ the governor is started again.
.ready - A pointer to a per-policy ready function which is called after
the policy is fully initialized.
.attr - A pointer to a NULL-terminated list of "struct freq_attr" which
allow to export values to sysfs.

44
Documentation/doc-guide/sphinx.rst
View File

@ -27,7 +27,7 @@ Sphinx Install
==============
The ReST markups currently used by the Documentation/ files are meant to be
built with ``Sphinx`` version 1.7 or higher.
built with ``Sphinx`` version 1.3 or higher.
There's a script that checks for the Sphinx requirements. Please see
:ref:`sphinx-pre-install` for further details.
@ -43,6 +43,10 @@ or ``virtualenv``, depending on how your distribution packaged Python 3.
.. note::
#) Sphinx versions below 1.5 don't work properly with Python's
docutils version 0.13.1 or higher. So, if you're willing to use
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 separately,
with ``pip install sphinx_rtd_theme``.
@ -51,13 +55,13 @@ or ``virtualenv``, depending on how your distribution packaged Python 3.
those expressions are written using LaTeX notation. It needs texlive
installed with amsfonts and amsmath in order to evaluate them.
In summary, if you want to install Sphinx version 2.4.4, you should do::
In summary, if you want to install Sphinx version 1.7.9, you should do::
$ virtualenv sphinx_2.4.4
$ . sphinx_2.4.4/bin/activate
(sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt
$ virtualenv sphinx_1.7.9
$ . sphinx_1.7.9/bin/activate
(sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt
After running ``. sphinx_2.4.4/bin/activate``, the prompt will change,
After running ``. sphinx_1.7.9/bin/activate``, the prompt will change,
in order to indicate that you're using the new environment. If you
open a new shell, you need to rerun this command to enter again at
the virtual environment before building the documentation.
@ -77,7 +81,7 @@ output.
PDF and LaTeX builds
--------------------
Such builds are currently supported only with Sphinx versions 2.4 and higher.
Such builds are currently supported only with Sphinx versions 1.4 and higher.
For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265.
@ -100,8 +104,8 @@ command line options for your distro::
You should run:
sudo dnf install -y texlive-luatex85
/usr/bin/virtualenv sphinx_2.4.4
. sphinx_2.4.4/bin/activate
/usr/bin/virtualenv sphinx_1.7.9
. sphinx_1.7.9/bin/activate
pip install -r Documentation/sphinx/requirements.txt
Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468.
@ -138,17 +142,6 @@ To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more verbose
output.
It is also possible to pass an extra DOCS_CSS overlay file, in order to customize
the html layout, by using the ``DOCS_CSS`` make variable.
By default, the build will try to use the Read the Docs sphinx theme:
https://github.com/readthedocs/sphinx_rtd_theme
If the theme is not available, it will fall-back to the classic one.
The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable.
To remove the generated documentation, run ``make cleandocs``.
Writing Documentation
@ -261,11 +254,12 @@ please feel free to remove it.
list tables
-----------
The list-table formats can be useful for tables that are not easily laid
out in the usual Sphinx ASCII-art formats. These formats are nearly
impossible for readers of the plain-text documents to understand, though,
and should be avoided in the absence of a strong justification for their
use.
We recommend the use of *list table* formats. The *list table* formats are
double-stage lists. Compared to the ASCII-art they might not be as
comfortable for
readers of the text files. Their advantage is that they are easy to
create or modify and that the diff of a modification is much more meaningful,
because it is limited to the modified content.
The ``flat-table`` is a double-stage list similar to the ``list-table`` with
some additional features:

224
Documentation/driver-api/auxiliary_bus.rst
View File

@ -6,45 +6,231 @@
Auxiliary Bus
=============
.. kernel-doc:: drivers/base/auxiliary.c
:doc: PURPOSE
In some subsystems, the functionality of the core device (PCI/ACPI/other) is
too complex for a single device to be managed by a monolithic driver
(e.g. Sound Open Firmware), multiple devices might implement a common
intersection of functionality (e.g. NICs + RDMA), or a driver may want to
export an interface for another subsystem to drive (e.g. SIOV Physical Function
export Virtual Function management). A split of the functionality into child-
devices representing sub-domains of functionality makes it possible to
compartmentalize, layer, and distribute domain-specific concerns via a Linux
device-driver model.
An example for this kind of requirement is the audio subsystem where a single
IP is handling multiple entities such as HDMI, Soundwire, local devices such as
mics/speakers etc. The split for the core's functionality can be arbitrary or
be defined by the DSP firmware topology and include hooks for test/debug. This
allows for the audio core device to be minimal and focused on hardware-specific
control and communication.
Each auxiliary_device represents a part of its parent functionality. The
generic behavior can be extended and specialized as needed by encapsulating an
auxiliary_device within other domain-specific structures and the use of .ops
callbacks. Devices on the auxiliary bus do not share any structures and the use
of a communication channel with the parent is domain-specific.
Note that ops are intended as a way to augment instance behavior within a class
of auxiliary devices, it is not the mechanism for exporting common
infrastructure from the parent. Consider EXPORT_SYMBOL_NS() to convey
infrastructure from the parent module to the auxiliary module(s).
When Should the Auxiliary Bus Be Used
=====================================
.. kernel-doc:: drivers/base/auxiliary.c
:doc: USAGE
The auxiliary bus is to be used when a driver and one or more kernel modules,
who share a common header file with the driver, need a mechanism to connect and
provide access to a shared object allocated by the auxiliary_device's
registering driver. The registering driver for the auxiliary_device(s) and the
kernel module(s) registering auxiliary_drivers can be from the same subsystem,
or from multiple subsystems.
The emphasis here is on a common generic interface that keeps subsystem
customization out of the bus infrastructure.
Auxiliary Device Creation
=========================
One example is a PCI network device that is RDMA-capable and exports a child
device to be driven by an auxiliary_driver in the RDMA subsystem. The PCI
driver allocates and registers an auxiliary_device for each physical
function on the NIC. The RDMA driver registers an auxiliary_driver that claims
each of these auxiliary_devices. This conveys data/ops published by the parent
PCI device/driver to the RDMA auxiliary_driver.
.. kernel-doc:: include/linux/auxiliary_bus.h
:identifiers: auxiliary_device
Another use case is for the PCI device to be split out into multiple sub
functions. For each sub function an auxiliary_device is created. A PCI sub
function driver binds to such devices that creates its own one or more class
devices. A PCI sub function auxiliary device is likely to be contained in a
struct with additional attributes such as user defined sub function number and
optional attributes such as resources and a link to the parent device. These
attributes could be used by systemd/udev; and hence should be initialized
before a driver binds to an auxiliary_device.
.. kernel-doc:: drivers/base/auxiliary.c
:identifiers: auxiliary_device_init __auxiliary_device_add
auxiliary_find_device
A key requirement for utilizing the auxiliary bus is that there is no
dependency on a physical bus, device, register accesses or regmap support.
These individual devices split from the core cannot live on the platform bus as
they are not physical devices that are controlled by DT/ACPI. The same
argument applies for not using MFD in this scenario as MFD relies on individual
function devices being physical devices.
Auxiliary Device
================
An auxiliary_device represents a part of its parent device's functionality. It
is given a name that, combined with the registering drivers KBUILD_MODNAME,
creates a match_name that is used for driver binding, and an id that combined
with the match_name provide a unique name to register with the bus subsystem.
Registering an auxiliary_device is a two-step process. First call
auxiliary_device_init(), which checks several aspects of the auxiliary_device
struct and performs a device_initialize(). After this step completes, any
error state must have a call to auxiliary_device_uninit() in its resolution path.
The second step in registering an auxiliary_device is to perform a call to
auxiliary_device_add(), which sets the name of the device and add the device to
the bus.
Unregistering an auxiliary_device is also a two-step process to mirror the
register process. First call auxiliary_device_delete(), then call
auxiliary_device_uninit().
.. code-block:: c
struct auxiliary_device {
struct device dev;
const char *name;
u32 id;
};
If two auxiliary_devices both with a match_name "mod.foo" are registered onto
the bus, they must have unique id values (e.g. "x" and "y") so that the
registered devices names are "mod.foo.x" and "mod.foo.y". If match_name + id
are not unique, then the device_add fails and generates an error message.
The auxiliary_device.dev.type.release or auxiliary_device.dev.release must be
populated with a non-NULL pointer to successfully register the auxiliary_device.
The auxiliary_device.dev.parent must also be populated.
Auxiliary Device Memory Model and Lifespan
------------------------------------------
.. kernel-doc:: include/linux/auxiliary_bus.h
:doc: DEVICE_LIFESPAN
The registering driver is the entity that allocates memory for the
auxiliary_device and register it on the auxiliary bus. It is important to note
that, as opposed to the platform bus, the registering driver is wholly
responsible for the management for the memory used for the driver object.
A parent object, defined in the shared header file, contains the
auxiliary_device. It also contains a pointer to the shared object(s), which
also is defined in the shared header. Both the parent object and the shared
object(s) are allocated by the registering driver. This layout allows the
auxiliary_driver's registering module to perform a container_of() call to go
from the pointer to the auxiliary_device, that is passed during the call to the
auxiliary_driver's probe function, up to the parent object, and then have
access to the shared object(s).
The memory for the auxiliary_device is freed only in its release() callback
flow as defined by its registering driver.
The memory for the shared object(s) must have a lifespan equal to, or greater
than, the lifespan of the memory for the auxiliary_device. The auxiliary_driver
should only consider that this shared object is valid as long as the
auxiliary_device is still registered on the auxiliary bus. It is up to the
registering driver to manage (e.g. free or keep available) the memory for the
shared object beyond the life of the auxiliary_device.
The registering driver must unregister all auxiliary devices before its own
driver.remove() is completed.
Auxiliary Drivers
=================
.. kernel-doc:: include/linux/auxiliary_bus.h
:identifiers: auxiliary_driver module_auxiliary_driver
Auxiliary drivers follow the standard driver model convention, where
discovery/enumeration is handled by the core, and drivers
provide probe() and remove() methods. They support power management
and shutdown notifications using the standard conventions.
.. kernel-doc:: drivers/base/auxiliary.c
:identifiers: __auxiliary_driver_register auxiliary_driver_unregister
.. code-block:: c
struct auxiliary_driver {
int (*probe)(struct auxiliary_device *,
const struct auxiliary_device_id *id);
void (*remove)(struct auxiliary_device *);
void (*shutdown)(struct auxiliary_device *);
int (*suspend)(struct auxiliary_device *, pm_message_t);
int (*resume)(struct auxiliary_device *);
struct device_driver driver;
const struct auxiliary_device_id *id_table;
};
Auxiliary drivers register themselves with the bus by calling
auxiliary_driver_register(). The id_table contains the match_names of auxiliary
devices that a driver can bind with.
Example Usage
=============
.. kernel-doc:: drivers/base/auxiliary.c
:doc: EXAMPLE
Auxiliary devices are created and registered by a subsystem-level core device
that needs to break up its functionality into smaller fragments. One way to
extend the scope of an auxiliary_device is to encapsulate it within a domain-
pecific structure defined by the parent device. This structure contains the
auxiliary_device and any associated shared data/callbacks needed to establish
the connection with the parent.
An example is:
.. code-block:: c
struct foo {
struct auxiliary_device auxdev;
void (*connect)(struct auxiliary_device *auxdev);
void (*disconnect)(struct auxiliary_device *auxdev);
void *data;
};
The parent device then registers the auxiliary_device by calling
auxiliary_device_init(), and then auxiliary_device_add(), with the pointer to
the auxdev member of the above structure. The parent provides a name for the
auxiliary_device that, combined with the parent's KBUILD_MODNAME, creates a
match_name that is be used for matching and binding with a driver.
Whenever an auxiliary_driver is registered, based on the match_name, the
auxiliary_driver's probe() is invoked for the matching devices. The
auxiliary_driver can also be encapsulated inside custom drivers that make the
core device's functionality extensible by adding additional domain-specific ops
as follows:
.. code-block:: c
struct my_ops {
void (*send)(struct auxiliary_device *auxdev);
void (*receive)(struct auxiliary_device *auxdev);
};
struct my_driver {
struct auxiliary_driver auxiliary_drv;
const struct my_ops ops;
};
An example of this type of usage is:
.. code-block:: c
const struct auxiliary_device_id my_auxiliary_id_table[] = {
{ .name = "foo_mod.foo_dev" },
{ },
};
const struct my_ops my_custom_ops = {
.send = my_tx,
.receive = my_rx,
};
const struct my_driver my_drv = {
.auxiliary_drv = {
.name = "myauxiliarydrv",
.id_table = my_auxiliary_id_table,
.probe = my_probe,
.remove = my_remove,
.shutdown = my_shutdown,
},
.ops = my_custom_ops,
};

6
Documentation/driver-api/dma-buf.rst
View File

@ -176,6 +176,12 @@ DMA Fences Functions Reference
.. kernel-doc:: include/linux/dma-fence.h
:internal:
Seqno Hardware Fences
~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: include/linux/seqno-fence.h
:internal:
DMA Fence Array
~~~~~~~~~~~~~~~

351
Documentation/driver-api/generic-counter.rst
View File

@ -223,6 +223,19 @@ whether an input line is differential or single-ended) and instead focus
on the core idea of what the data and process represent (e.g. position
as interpreted from quadrature encoding data).
Userspace Interface
===================
Several sysfs attributes are generated by the Generic Counter interface,
and reside under the /sys/bus/counter/devices/counterX directory, where
counterX refers to the respective counter device. Please see
Documentation/ABI/testing/sysfs-bus-counter for detailed
information on each Generic Counter interface sysfs attribute.
Through these sysfs attributes, programs and scripts may interact with
the Generic Counter paradigm Counts, Signals, and Synapses of respective
counter devices.
Driver API
==========
@ -234,14 +247,11 @@ for defining a counter device.
.. kernel-doc:: include/linux/counter.h
:internal:
.. kernel-doc:: drivers/counter/counter-core.c
.. kernel-doc:: drivers/counter/counter.c
:export:
.. kernel-doc:: drivers/counter/counter-chrdev.c
:export:
Driver Implementation
=====================
Implementation
==============
To support a counter device, a driver must first allocate the available
Counter Signals via counter_signal structures. These Signals should
@ -257,61 +267,25 @@ respective counter_count structure. These counter_count structures are
set to the counts array member of an allocated counter_device structure
before the Counter is registered to the system.
Driver callbacks must be provided to the counter_device structure in
order to communicate with the device: to read and write various Signals
and Counts, and to set and get the "action mode" and "function mode" for
various Synapses and Counts respectively.
Driver callbacks should be provided to the counter_device structure via
a constant counter_ops structure in order to communicate with the
device: to read and write various Signals and Counts, and to set and get
the "action mode" and "function mode" for various Synapses and Counts
respectively.
A counter_device structure is allocated using counter_alloc() and then
registered to the system by passing it to the counter_add() function, and
unregistered by passing it to the counter_unregister function. There are
device managed variants of these functions: devm_counter_alloc() and
devm_counter_add().
A defined counter_device structure may be registered to the system by
passing it to the counter_register function, and unregistered by passing
it to the counter_unregister function. Similarly, the
devm_counter_register and devm_counter_unregister functions may be used
if device memory-managed registration is desired.
The struct counter_comp structure is used to define counter extensions
for Signals, Synapses, and Counts.
The "type" member specifies the type of high-level data (e.g. BOOL,
COUNT_DIRECTION, etc.) handled by this extension. The "``*_read``" and
"``*_write``" members can then be set by the counter device driver with
callbacks to handle that data using native C data types (i.e. u8, u64,
etc.).
Convenience macros such as ``COUNTER_COMP_COUNT_U64`` are provided for
use by driver authors. In particular, driver authors are expected to use
the provided macros for standard Counter subsystem attributes in order
to maintain a consistent interface for userspace. For example, a counter
device driver may define several standard attributes like so::
struct counter_comp count_ext[] = {
COUNTER_COMP_DIRECTION(count_direction_read),
COUNTER_COMP_ENABLE(count_enable_read, count_enable_write),
COUNTER_COMP_CEILING(count_ceiling_read, count_ceiling_write),
};
This makes it simple to see, add, and modify the attributes that are
supported by this driver ("direction", "enable", and "ceiling") and to
maintain this code without getting lost in a web of struct braces.
Callbacks must match the function type expected for the respective
component or extension. These function types are defined in the struct
counter_comp structure as the "``*_read``" and "``*_write``" union
members.
The corresponding callback prototypes for the extensions mentioned in
the previous example above would be::
int count_direction_read(struct counter_device *counter,
struct counter_count *count,
enum counter_count_direction *direction);
int count_enable_read(struct counter_device *counter,
struct counter_count *count, u8 *enable);
int count_enable_write(struct counter_device *counter,
struct counter_count *count, u8 enable);
int count_ceiling_read(struct counter_device *counter,
struct counter_count *count, u64 *ceiling);
int count_ceiling_write(struct counter_device *counter,
struct counter_count *count, u64 ceiling);
Extension sysfs attributes can be created for auxiliary functionality
and data by passing in defined counter_device_ext, counter_count_ext,
and counter_signal_ext structures. In these cases, the
counter_device_ext structure is used for global/miscellaneous exposure
and configuration of the respective Counter device, while the
counter_count_ext and counter_signal_ext structures allow for auxiliary
exposure and configuration of a specific Count or Signal respectively.
Determining the type of extension to create is a matter of scope.
@ -339,235 +313,52 @@ Determining the type of extension to create is a matter of scope.
chip overheated via a device extension called "error_overtemp":
/sys/bus/counter/devices/counterX/error_overtemp
Subsystem Architecture
======================
Architecture
============
Counter drivers pass and take data natively (i.e. ``u8``, ``u64``, etc.)
and the shared counter module handles the translation between the sysfs
interface. This guarantees a standard userspace interface for all
counter drivers, and enables a Generic Counter chrdev interface via a
generalized device driver ABI.
When the Generic Counter interface counter module is loaded, the
counter_init function is called which registers a bus_type named
"counter" to the system. Subsequently, when the module is unloaded, the
counter_exit function is called which unregisters the bus_type named
"counter" from the system.
A high-level view of how a count value is passed down from a counter
driver is exemplified by the following. The driver callbacks are first
registered to the Counter core component for use by the Counter
userspace interface components::
Counter devices are registered to the system via the counter_register
function, and later removed via the counter_unregister function. The
counter_register function establishes a unique ID for the Counter
device and creates a respective sysfs directory, where X is the
mentioned unique ID:
Driver callbacks registration:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------+
| Counter device driver |
+----------------------------+
| Processes data from device |
+----------------------------+
|
-------------------
/ driver callbacks /
-------------------
|
V
+----------------------+
| Counter core |
+----------------------+
| Routes device driver |
| callbacks to the |
| userspace interfaces |
+----------------------+
|
-------------------
/ driver callbacks /
-------------------
|
+---------------+---------------+
| |
V V
+--------------------+ +---------------------+
| Counter sysfs | | Counter chrdev |
+--------------------+ +---------------------+
| Translates to the | | Translates to the |
| standard Counter | | standard Counter |
| sysfs output | | character device |
+--------------------+ +---------------------+
/sys/bus/counter/devices/counterX
Thereafter, data can be transferred directly between the Counter device
driver and Counter userspace interface::
Sysfs attributes are created within the counterX directory to expose
functionality, configurations, and data relating to the Counts, Signals,
and Synapses of the Counter device, as well as options and information
for the Counter device itself.
Count data request:
~~~~~~~~~~~~~~~~~~~
----------------------
/ Counter device \
+----------------------+
| Count register: 0x28 |
+----------------------+
|
-----------------
/ raw count data /
-----------------
|
V
+----------------------------+
| Counter device driver |
+----------------------------+
| Processes data from device |
|----------------------------|
| Type: u64 |
| Value: 42 |
+----------------------------+
|
----------
/ u64 /
----------
|
+---------------+---------------+
| |
V V
+--------------------+ +---------------------+
| Counter sysfs | | Counter chrdev |
+--------------------+ +---------------------+
| Translates to the | | Translates to the |
| standard Counter | | standard Counter |
| sysfs output | | character device |
|--------------------| |---------------------|
| Type: const char * | | Type: u64 |
| Value: "42" | | Value: 42 |
+--------------------+ +---------------------+
| |
--------------- -----------------------
/ const char * / / struct counter_event /
--------------- -----------------------
| |
| V
| +-----------+
| | read |
| +-----------+
| \ Count: 42 /
| -----------
|
V
+--------------------------------------------------+
| `/sys/bus/counter/devices/counterX/countY/count` |
+--------------------------------------------------+
\ Count: "42" /
--------------------------------------------------
Each Signal has a directory created to house its relevant sysfs
attributes, where Y is the unique ID of the respective Signal:
There are four primary components involved:
/sys/bus/counter/devices/counterX/signalY
Counter device driver
---------------------
Communicates with the hardware device to read/write data; e.g. counter
drivers for quadrature encoders, timers, etc.
Similarly, each Count has a directory created to house its relevant
sysfs attributes, where Y is the unique ID of the respective Count:
Counter core
------------
Registers the counter device driver to the system so that the respective
callbacks are called during userspace interaction.
/sys/bus/counter/devices/counterX/countY
Counter sysfs
-------------
Translates counter data to the standard Counter sysfs interface format
and vice versa.
For a more detailed breakdown of the available Generic Counter interface
sysfs attributes, please refer to the
Documentation/ABI/testing/sysfs-bus-counter file.
Please refer to the ``Documentation/ABI/testing/sysfs-bus-counter`` file
for a detailed breakdown of the available Generic Counter interface
sysfs attributes.
The Signals and Counts associated with the Counter device are registered
to the system as well by the counter_register function. The
signal_read/signal_write driver callbacks are associated with their
respective Signal attributes, while the count_read/count_write and
function_get/function_set driver callbacks are associated with their
respective Count attributes; similarly, the same is true for the
action_get/action_set driver callbacks and their respective Synapse
attributes. If a driver callback is left undefined, then the respective
read/write permission is left disabled for the relevant attributes.
Counter chrdev
--------------
Translates Counter events to the standard Counter character device; data
is transferred via standard character device read calls, while Counter
events are configured via ioctl calls.
Sysfs Interface
===============
Several sysfs attributes are generated by the Generic Counter interface,
and reside under the ``/sys/bus/counter/devices/counterX`` directory,
where ``X`` is to the respective counter device id. Please see
``Documentation/ABI/testing/sysfs-bus-counter`` for detailed information
on each Generic Counter interface sysfs attribute.
Through these sysfs attributes, programs and scripts may interact with
the Generic Counter paradigm Counts, Signals, and Synapses of respective
counter devices.
Counter Character Device
========================
Counter character device nodes are created under the ``/dev`` directory
as ``counterX``, where ``X`` is the respective counter device id.
Defines for the standard Counter data types are exposed via the
userspace ``include/uapi/linux/counter.h`` file.
Counter events
--------------
Counter device drivers can support Counter events by utilizing the
``counter_push_event`` function::
void counter_push_event(struct counter_device *const counter, const u8 event,
const u8 channel);
The event id is specified by the ``event`` parameter; the event channel
id is specified by the ``channel`` parameter. When this function is
called, the Counter data associated with the respective event is
gathered, and a ``struct counter_event`` is generated for each datum and
pushed to userspace.
Counter events can be configured by users to report various Counter
data of interest. This can be conceptualized as a list of Counter
component read calls to perform. For example:
+------------------------+------------------------+
| COUNTER_EVENT_OVERFLOW | COUNTER_EVENT_INDEX |
+========================+========================+
| Channel 0 | Channel 0 |
+------------------------+------------------------+
| * Count 0 | * Signal 0 |
| * Count 1 | * Signal 0 Extension 0 |
| * Signal 3 | * Extension 4 |
| * Count 4 Extension 2 +------------------------+
| * Signal 5 Extension 0 | Channel 1 |
| +------------------------+
| | * Signal 4 |
| | * Signal 4 Extension 0 |
| | * Count 7 |
+------------------------+------------------------+
When ``counter_push_event(counter, COUNTER_EVENT_INDEX, 1)`` is called
for example, it will go down the list for the ``COUNTER_EVENT_INDEX``
event channel 1 and execute the read callbacks for Signal 4, Signal 4
Extension 0, and Count 7 -- the data returned for each is pushed to a
kfifo as a ``struct counter_event``, which userspace can retrieve via a
standard read operation on the respective character device node.
Userspace
---------
Userspace applications can configure Counter events via ioctl operations
on the Counter character device node. There following ioctl codes are
supported and provided by the ``linux/counter.h`` userspace header file:
* :c:macro:`COUNTER_ADD_WATCH_IOCTL`
* :c:macro:`COUNTER_ENABLE_EVENTS_IOCTL`
* :c:macro:`COUNTER_DISABLE_EVENTS_IOCTL`
To configure events to gather Counter data, users first populate a
``struct counter_watch`` with the relevant event id, event channel id,
and the information for the desired Counter component from which to
read, and then pass it via the ``COUNTER_ADD_WATCH_IOCTL`` ioctl
command.
Note that an event can be watched without gathering Counter data by
setting the ``component.type`` member equal to
``COUNTER_COMPONENT_NONE``. With this configuration the Counter
character device will simply populate the event timestamps for those
respective ``struct counter_event`` elements and ignore the component
value.
The ``COUNTER_ADD_WATCH_IOCTL`` command will buffer these Counter
watches. When ready, the ``COUNTER_ENABLE_EVENTS_IOCTL`` ioctl command
may be used to activate these Counter watches.
Userspace applications can then execute a ``read`` operation (optionally
calling ``poll`` first) on the Counter character device node to retrieve
``struct counter_event`` elements with the desired data.
Similarly, extension sysfs attributes are created for the defined
counter_device_ext, counter_count_ext, and counter_signal_ext
structures that are passed in.

64
Documentation/driver-api/ipmi.rst
View File

@ -166,8 +166,8 @@ and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking
straight to the BMC on the current card. The channel must be
IPMI_BMC_CHANNEL.
Messages that are destined to go out on the IPMB bus going through the
BMC use the IPMI_IPMB_ADDR_TYPE address type. The format is::
Messages that are destined to go out on the IPMB bus use the
IPMI_IPMB_ADDR_TYPE address type. The format is::
struct ipmi_ipmb_addr
{
@ -181,23 +181,6 @@ The "channel" here is generally zero, but some devices support more
than one channel, it corresponds to the channel as defined in the IPMI
spec.
There is also an IPMB direct address for a situation where the sender
is directly on an IPMB bus and doesn't have to go through the BMC.
You can send messages to a specific management controller (MC) on the
IPMB using the IPMI_IPMB_DIRECT_ADDR_TYPE with the following format::
struct ipmi_ipmb_direct_addr
{
int addr_type;
short channel;
unsigned char slave_addr;
unsigned char rq_lun;
unsigned char rs_lun;
};
The channel is always zero. You can also receive commands from other
MCs that you have registered to handle and respond to them, so you can
use this to implement a management controller on a bus..
Messages
--------
@ -365,10 +348,6 @@ user may be registered for each netfn/cmd/channel, but different users
may register for different commands, or the same command if the
channel bitmasks do not overlap.
To respond to a received command, set the response bit in the returned
netfn, use the address from the received message, and use the same
msgid that you got in the receive message.
From userland, equivalent IOCTLs are provided to do these functions.
@ -591,45 +570,6 @@ web page.
The driver supports a hot add and remove of interfaces through the I2C
sysfs interface.
The IPMI IPMB Driver
--------------------
This driver is for supporting a system that sits on an IPMB bus; it
allows the interface to look like a normal IPMI interface. Sending
system interface addressed messages to it will cause the message to go
to the registered BMC on the system (default at IPMI address 0x20).
It also allows you to directly address other MCs on the bus using the
ipmb direct addressing. You can receive commands from other MCs on
the bus and they will be handled through the normal received command
mechanism described above.
Parameters are::
ipmi_ipmb.bmcaddr=<address to use for system interface addresses messages>
ipmi_ipmb.retry_time_ms=<Time between retries on IPMB>
ipmi_ipmb.max_retries=<Number of times to retry a message>
Loading the module will not result in the driver automatcially
starting unless there is device tree information setting it up. If
you want to instantiate one of these by hand, do::
echo ipmi-ipmb <addr> > /sys/class/i2c-dev/i2c-<n>/device/new_device
Note that the address you give here is the I2C address, not the IPMI
address. So if you want your MC address to be 0x60, you put 0x30
here. See the I2C driver info for more details.
Command bridging to other IPMB busses through this interface does not
work. The receive message queue is not implemented, by design. There
is only one receive message queue on a BMC, and that is meant for the
host drivers, not something on the IPMB bus.
A BMC may have multiple IPMB busses, which bus your device sits on
depends on how the system is wired. You can fetch the channels with
"ipmitool channel info <n>" where <n> is the channel, with the
channels being 0-7 and try the IPMB channels.
Other Pieces
------------

19
Documentation/firmware-guide/acpi/apei/einj.rst
View File

@ -181,24 +181,5 @@ You should see something like this in dmesg::
[22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0
[22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0)
Special notes for injection into SGX enclaves:
There may be a separate BIOS setup option to enable SGX injection.
The injection process consists of setting some special memory controller
trigger that will inject the error on the next write to the target
address. But the h/w prevents any software outside of an SGX enclave
from accessing enclave pages (even BIOS SMM mode).
The following sequence can be used:
1) Determine physical address of enclave page
2) Use "notrigger=1" mode to inject (this will setup
the injection address, but will not actually inject)
3) Enter the enclave
4) Store data to the virtual address matching physical address from step 1
5) Execute CLFLUSH for that virtual address
6) Spin delay for 250ms
7) Read from the virtual address. This will trigger the error
For more information about EINJ, please refer to ACPI specification
version 4.0, section 17.5 and ACPI 5.0, section 18.6.

18
Documentation/firmware-guide/acpi/dsd/data-node-references.rst
View File

@ -13,9 +13,9 @@ 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 [dsd-guide] 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
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,
@ -33,7 +33,7 @@ extension key.
Example
=======
In the ASL snippet below, the "reference" _DSD property contains a
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
@ -91,6 +91,10 @@ Documentation/firmware-guide/acpi/dsd/graph.rst.
References
==========
[dsd-guide] DSD Guide.
https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced
2021-11-30.
[1] Hierarchical Data Extension UUID For _DSD.
<https://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.
<https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
referenced 2016-10-04.

40
Documentation/firmware-guide/acpi/dsd/graph.rst
View File

@ -7,11 +7,11 @@ Graphs
_DSD
====
_DSD (Device Specific Data) [dsd-guide] is a predefined ACPI device
_DSD (Device Specific Data) [7] is a predefined ACPI device
configuration object that can be used to convey information on
hardware features which are not specifically covered by the ACPI
specification [acpi]. There are two _DSD extensions that are relevant
for graphs: property [dsd-guide] and hierarchical data extensions. The
specification [1][6]. There are two _DSD extensions that are relevant
for graphs: property [4] and hierarchical data extensions [5]. The
property extension provides generic key-value pairs whereas the
hierarchical data extension supports nodes with references to other
nodes, forming a tree. The nodes in the tree may contain properties as
@ -36,9 +36,8 @@ Ports and endpoints
===================
The port and endpoint concepts are very similar to those in Devicetree
[devicetree, graph-bindings]. A port represents an interface in a device, and
an endpoint represents a connection to that interface. Also see [data-node-ref]
for generic data node references.
[3]. A port represents an interface in a device, and an endpoint
represents a connection to that interface.
All port nodes are located under the device's "_DSD" node in the hierarchical
data extension tree. The data extension related to each port node must begin
@ -154,20 +153,25 @@ the "ISP" device and vice versa.
References
==========
[acpi] Advanced Configuration and Power Interface Specification.
https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30.
[1] _DSD (Device Specific Data) Implementation Guide.
https://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm,
referenced 2016-10-03.
[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
[devicetree] Devicetree. https://www.devicetree.org, referenced 2016-10-03.
[3] Documentation/devicetree/bindings/graph.txt
[dsd-guide] DSD Guide.
https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced
2021-11-30.
[4] Device Properties UUID For _DSD.
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
referenced 2016-10-04.
[dsd-rules] _DSD Device Properties Usage Rules.
[5] Hierarchical Data Extension UUID For _DSD.
https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf,
referenced 2016-10-04.
[6] Advanced Configuration and Power Interface Specification.
https://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf,
referenced 2016-10-04.
[7] _DSD Device Properties Usage Rules.
Documentation/firmware-guide/acpi/DSD-properties-rules.rst
[graph-bindings] Common bindings for device graphs (Devicetree).
https://github.com/devicetree-org/dt-schema/blob/main/schemas/graph.yaml,
referenced 2021-11-30.

40
Documentation/firmware-guide/acpi/dsd/leds.rst
View File

@ -5,20 +5,19 @@
Describing and referring to LEDs in ACPI
========================================
Individual LEDs are described by hierarchical data extension [5] nodes under the
Individual LEDs are described by hierarchical data extension [6] nodes under the
device node, the LED driver chip. The "reg" property in the LED specific nodes
tells the numerical ID of each individual LED output to which the LEDs are
connected. [leds] The hierarchical data nodes are named "led@X", where X is the
connected. [3] The hierarchical data nodes are named "led@X", where X is the
number of the LED output.
Referring to LEDs in Device tree is documented in [video-interfaces], in
"flash-leds" property documentation. In short, LEDs are directly referred to by
using phandles.
Referring to LEDs in Device tree is documented in [4], in "flash-leds" property
documentation. In short, LEDs are directly referred to by using phandles.
While Device tree allows referring to any node in the tree [devicetree], in
ACPI references are limited to device nodes only [acpi]. For this reason using
the same mechanism on ACPI is not possible. A mechanism to refer to non-device
ACPI nodes is documented in [data-node-ref].
While Device tree allows referring to any node in the tree[1], in ACPI
references are limited to device nodes only [2]. For this reason using the same
mechanism on ACPI is not possible. A mechanism to refer to non-device ACPI nodes
is documented in [7].
ACPI allows (as does DT) using integer arguments after the reference. A
combination of the LED driver device reference and an integer argument,
@ -91,17 +90,22 @@ where
References
==========
[acpi] Advanced Configuration and Power Interface Specification.
https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30.
[1] Device tree. https://www.devicetree.org, referenced 2019-02-21.
[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
[2] Advanced Configuration and Power Interface Specification.
https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf,
referenced 2019-02-21.
[devicetree] Devicetree. https://www.devicetree.org, referenced 2019-02-21.
[3] Documentation/devicetree/bindings/leds/common.txt
[dsd-guide] DSD Guide.
https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced
2021-11-30.
[4] Documentation/devicetree/bindings/media/video-interfaces.txt
[leds] Documentation/devicetree/bindings/leds/common.yaml
[5] Device Properties UUID For _DSD.
https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf,
referenced 2019-02-21.
[video-interfaces] Documentation/devicetree/bindings/media/video-interfaces.yaml
[6] Hierarchical Data Extension UUID For _DSD.
https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf,
referenced 2019-02-21.
[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst

28
Documentation/firmware-guide/acpi/dsd/phy.rst
View File

@ -4,17 +4,17 @@
MDIO bus and PHYs in ACPI
=========================
The PHYs on an MDIO bus [phy] are probed and registered using
The PHYs on an MDIO bus [1] are probed and registered using
fwnode_mdiobus_register_phy().
Later, for connecting these PHYs to their respective MACs, the PHYs registered
on the MDIO bus have to be referenced.
This document introduces two _DSD properties that are to be used
for connecting PHYs on the MDIO bus [dsd-properties-rules] to the MAC layer.
for connecting PHYs on the MDIO bus [3] to the MAC layer.
These properties are defined in accordance with the "Device
Properties UUID For _DSD" [dsd-guide] document and the
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them.
@ -48,22 +48,22 @@ as device object references (e.g. \_SB.MDI0.PHY1).
phy-mode
--------
The "phy-mode" _DSD property is used to describe the connection to
the PHY. The valid values for "phy-mode" are defined in [ethernet-controller].
the PHY. The valid values for "phy-mode" are defined in [4].
managed
-------
Optional property, which specifies the PHY management type.
The valid values for "managed" are defined in [ethernet-controller].
The valid values for "managed" are defined in [4].
fixed-link
----------
The "fixed-link" is described by a data-only subnode of the
MAC port, which is linked in the _DSD package via
hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
in accordance with [dsd-guide] "_DSD Implementation Guide" document).
in accordance with [5] "_DSD Implementation Guide" document).
The subnode should comprise a required property ("speed") and
possibly the optional ones - complete list of parameters and
their values are specified in [ethernet-controller].
their values are specified in [4].
The following ASL example illustrates the usage of these properties.
@ -188,14 +188,12 @@ MAC node example with a "fixed-link" subnode.
References
==========
[phy] Documentation/networking/phy.rst
[1] Documentation/networking/phy.rst
[dsd-properties-rules]
Documentation/firmware-guide/acpi/DSD-properties-rules.rst
[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
[ethernet-controller]
Documentation/devicetree/bindings/net/ethernet-controller.yaml
[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
[dsd-guide] DSD Guide.
https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced
2021-11-30.
[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
[5] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf

1
Documentation/firmware-guide/acpi/index.rst
View File

@ -26,6 +26,5 @@ ACPI Support
acpi-lid
lpit
video_extension
non-d0-probe
extcon-intel-int3496
intel-pmc-mux

2
Documentation/firmware-guide/acpi/osi.rst
View File

@ -74,7 +74,7 @@ The ACPI BIOS flow would include an evaluation of _OS, and the AML
interpreter in the kernel would return to it a string identifying the OS:
Windows 98, SE: "Microsoft Windows"
Windows ME: "Microsoft WindowsME:Millennium Edition"
Windows ME: "Microsoft WindowsME:Millenium Edition"
Windows NT: "Microsoft Windows NT"
The idea was on a platform tasked with running multiple OS's,

3
Documentation/gpu/drivers.rst
View File

@ -4,7 +4,8 @@ GPU Driver Documentation
.. toctree::
amdgpu/index
amdgpu
amdgpu-dc
i915
mcde
meson

27
Documentation/gpu/drm-kms-helpers.rst
View File

@ -151,18 +151,6 @@ Overview
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:doc: overview
Display Driver Integration
--------------------------
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:doc: display driver integration
Special Care with MIPI-DSI bridges
----------------------------------
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:doc: special care dsi
Bridge Operations
-----------------
@ -435,18 +423,3 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
Privacy-screen class
====================
.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
:doc: overview
.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
:internal:
.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
:internal:
.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
:export:

2
Documentation/gpu/drm-kms.rst
View File

@ -506,8 +506,6 @@ Property Types and Blob Property Support
.. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
.. _standard_connector_properties:
Standard Connector Properties
-----------------------------

80
Documentation/gpu/drm-mm.rst
View File

@ -28,53 +28,56 @@ UMA devices.
The Translation Table Manager (TTM)
===================================
.. kernel-doc:: drivers/gpu/drm/ttm/ttm_module.c
:doc: TTM
TTM design background and information belongs here.
.. kernel-doc:: include/drm/ttm/ttm_caching.h
:internal:
TTM initialization
------------------
TTM device object reference
---------------------------
**Warning**
This section is outdated.
.. kernel-doc:: include/drm/ttm/ttm_device.h
:internal:
Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver
<ttm_bo_driver>` structure to ttm_device_init, together with an
initialized global reference to the memory manager. The ttm_bo_driver
structure contains several fields with function pointers for
initializing the TTM, allocating and freeing memory, waiting for command
completion and fence synchronization, and memory migration.
.. kernel-doc:: drivers/gpu/drm/ttm/ttm_device.c
:export:
The :c:type:`struct drm_global_reference <drm_global_reference>` is made
up of several fields:
TTM resource placement reference
--------------------------------
.. code-block:: c
.. kernel-doc:: include/drm/ttm/ttm_placement.h
:internal:
struct drm_global_reference {
enum ttm_global_types global_type;
size_t size;
void *object;
int (*init) (struct drm_global_reference *);
void (*release) (struct drm_global_reference *);
};
TTM resource object reference
-----------------------------
.. kernel-doc:: include/drm/ttm/ttm_resource.h
:internal:
There should be one global reference structure for your memory manager
as a whole, and there will be others for each object created by the
memory manager at runtime. Your global TTM should have a type of
TTM_GLOBAL_TTM_MEM. The size field for the global object should be
sizeof(struct ttm_mem_global), and the init and release hooks should
point at your driver-specific init and release routines, which probably
eventually call ttm_mem_global_init and ttm_mem_global_release,
respectively.
.. kernel-doc:: drivers/gpu/drm/ttm/ttm_resource.c
:export:
Once your global TTM accounting structure is set up and initialized by
calling ttm_global_item_ref() on it, you need to create a buffer
object TTM to provide a pool for buffer object allocation by clients and
the kernel itself. The type of this object should be
TTM_GLOBAL_TTM_BO, and its size should be sizeof(struct
ttm_bo_global). Again, driver-specific init and release functions may
be provided, likely eventually calling ttm_bo_global_ref_init() and
ttm_bo_global_ref_release(), respectively. Also, like the previous
object, ttm_global_item_ref() is used to create an initial reference
count for the TTM, which will call your initialization function.
TTM TT object reference
-----------------------
.. kernel-doc:: include/drm/ttm/ttm_tt.h
:internal:
.. kernel-doc:: drivers/gpu/drm/ttm/ttm_tt.c
:export:
TTM page pool reference
-----------------------
.. kernel-doc:: include/drm/ttm/ttm_pool.h
:internal:
.. kernel-doc:: drivers/gpu/drm/ttm/ttm_pool.c
:export:
See the radeon_ttm.c file for an example of usage.
The Graphics Execution Manager (GEM)
====================================
@ -501,6 +504,3 @@ Scheduler Function References
.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
:export:
.. kernel-doc:: drivers/gpu/drm/scheduler/sched_entity.c
:export:

23
Documentation/gpu/i915.rst
View File

@ -187,19 +187,22 @@ Display Refresh Rate Switching (DRRS)
:doc: Display Refresh Rate Switching (DRRS)
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
:functions: intel_drrs_enable
:functions: intel_dp_set_drrs_state
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
:functions: intel_drrs_disable
:functions: intel_edp_drrs_enable
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
:functions: intel_drrs_invalidate
:functions: intel_edp_drrs_disable
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
:functions: intel_drrs_flush
:functions: intel_edp_drrs_invalidate
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
:functions: intel_drrs_init
:functions: intel_edp_drrs_flush
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_drrs.c
:functions: intel_dp_drrs_init
DPIO
----
@ -471,14 +474,6 @@ Object Tiling IOCTLs
.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c
:doc: buffer object tiling
Protected Objects
-----------------
.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp.c
:doc: PXP
.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h
Microcontrollers
================
@ -503,8 +498,6 @@ GuC
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
:doc: GuC
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h
GuC Firmware Layout
~~~~~~~~~~~~~~~~~~~

4
Documentation/gpu/rfc/i915_scheduler.rst
View File

@ -135,8 +135,8 @@ Add I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT and
drm_i915_context_engines_parallel_submit to the uAPI to implement this
extension.
.. kernel-doc:: include/uapi/drm/i915_drm.h
:functions: i915_context_engines_parallel_submit
.. kernel-doc:: Documentation/gpu/rfc/i915_parallel_execbuf.h
:functions: drm_i915_context_engines_parallel_submit
Extend execbuf2 IOCTL to support submitting N BBs in a single IOCTL
-------------------------------------------------------------------

54
Documentation/gpu/todo.rst
View File

@ -268,6 +268,17 @@ Contact: Daniel Vetter
Level: Intermediate
Clean up mmap forwarding
------------------------
A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers.
And also a lot of them forward dma-buf mmap to the gem mmap implementations.
There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
Contact: Daniel Vetter
Level: Intermediate
Generic fbdev defio support
---------------------------
@ -321,6 +332,23 @@ converted, except for struct drm_driver.gem_prime_mmap.
Level: Intermediate
Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
---------------------------------------------------------
For cases where drivers are attempting to grab the modeset locks with a local
acquire context. Replace the boilerplate code surrounding
drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END() instead.
This should also be done for all places where drm_modeset_lock_all() is still
used.
As a reference, take a look at the conversions already completed in drm core.
Contact: Sean Paul, respective driver maintainers
Level: Starter
Rename CMA helpers to DMA helpers
---------------------------------
@ -428,21 +456,6 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vette
Level: Intermediate
Review all drivers for setting struct drm_mode_config.{max_width,max_height} correctly
--------------------------------------------------------------------------------------
The values in struct drm_mode_config.{max_width,max_height} describe the
maximum supported framebuffer size. It's the virtual screen size, but many
drivers treat it like limitations of the physical resolution.
The maximum width depends on the hardware's maximum scanline pitch. The
maximum height depends on the amount of addressable video memory. Review all
drivers to initialize the fields to the correct values.
Contact: Thomas Zimmermann <tzimmermann@suse.de>
Level: Intermediate
Core refactorings
=================
@ -622,17 +635,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks.
Contact: Harry Wentland, Alex Deucher
vmwgfx: Replace hashtable with Linux' implementation
----------------------------------------------------
The vmwgfx driver uses its own hashtable implementation. Replace the
code with Linux' implementation and update the callers. It's mostly a
refactoring task, but the interfaces are different.
Contact: Zack Rusin, Thomas Zimmermann <tzimmermann@suse.de>
Level: Intermediate
Bootsplash
==========

14
Documentation/i2c/smbus-protocol.rst
View File

@ -36,8 +36,6 @@ Key to symbols
=============== =============================================================
S Start condition
Sr Repeated start condition, used to switch from write to
read mode.
P Stop condition
Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0.
A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit
@ -102,7 +100,7 @@ Implemented by i2c_smbus_read_byte_data()
This reads a single byte from a device, from a designated register.
The register is specified through the Comm byte::
S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P
S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA
@ -116,7 +114,7 @@ This operation is very like Read Byte; again, data is read from a
device, from a designated register that is specified through the Comm
byte. But this time, the data is a complete word (16 bits)::
S Addr Wr [A] Comm [A] Sr Addr Rd [A] [DataLow] A [DataHigh] NA P
S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA
@ -166,7 +164,7 @@ This command selects a device register (through the Comm byte), sends
16 bits of data to it, and reads 16 bits of data in return::
S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]
Sr Addr Rd [A] [DataLow] A [DataHigh] NA P
S Addr Rd [A] [DataLow] A [DataHigh] NA P
Functionality flag: I2C_FUNC_SMBUS_PROC_CALL
@ -183,7 +181,7 @@ of data is specified by the device in the Count byte.
::
S Addr Wr [A] Comm [A]
Sr Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA
@ -214,7 +212,7 @@ This command selects a device register (through the Comm byte), sends
1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return::
S Addr Wr [A] Comm [A] Count [A] Data [A] ...
Sr Addr Rd [A] [Count] A [Data] ... A P
S Addr Rd [A] [Count] A [Data] ... A P
Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL
@ -302,7 +300,7 @@ This command reads a block of bytes from a device, from a
designated register that is specified through the Comm byte::
S Addr Wr [A] Comm [A]
Sr Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK

8
Documentation/i2c/summary.rst
View File

@ -11,11 +11,9 @@ systems. Some systems use variants that don't meet branding requirements,
and so are not advertised as being I2C but come under different names,
e.g. TWI (Two Wire Interface), IIC.
The latest official I2C specification is the `"I2C-bus specification and user
manual" (UM10204) <https://www.nxp.com/webapp/Download?colCode=UM10204>`_
published by NXP Semiconductors. However, you need to log-in to the site to
access the PDF. An older version of the specification (revision 6) is archived
`here <https://web.archive.org/web/20210813122132/https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_.
The official I2C specification is the `"I2C-bus specification and user
manual" (UM10204) <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_
published by NXP Semiconductors.
SMBus (System Management Bus) is based on the I2C protocol, and is mostly
a subset of I2C protocols and signaling. Many I2C devices will work on an

2
Documentation/index.rst
View File

@ -137,7 +137,6 @@ needed).
misc-devices/index
scheduler/index
mhi/index
tty/index
Architecture-agnostic documentation
-----------------------------------
@ -166,7 +165,6 @@ to ReStructured Text format, or are simply too old.
.. toctree::
:maxdepth: 2
tools/index
staging/index
watch_queue

2
Documentation/locking/ww-mutex-design.rst
View File

@ -60,7 +60,7 @@ Concepts
Compared to normal mutexes two additional concepts/objects show up in the lock
interface for w/w mutexes:
Acquire context: To ensure eventual forward progress it is important that a task
Acquire context: To ensure eventual forward progress it is important the a task
trying to acquire locks doesn't grab a new reservation id, but keeps the one it
acquired when starting the lock acquisition. This ticket is stored in the
acquire context. Furthermore the acquire context keeps track of debugging state

8
Documentation/memory-barriers.txt
View File

@ -1950,14 +1950,6 @@ There are some more advanced barrier functions:
For load from persistent memory, existing read memory barriers are sufficient
to ensure read ordering.
(*) io_stop_wc();
For memory accesses with write-combining attributes (e.g. those returned
by ioremap_wc(), the CPU may wait for prior accesses to be merged with
subsequent ones. io_stop_wc() can be used to prevent the merging of
write-combining memory accesses before this macro with those after it when
such wait has performance implications.
===============================
IMPLICIT KERNEL MEMORY BARRIERS
===============================

53
Documentation/power/energy-model.rst
View File

@ -84,16 +84,6 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework.
2.2 Registration of performance domains
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Registration of 'advanced' EM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'advanced' EM gets it's name due to the fact that the driver is allowed
to provide more precised power model. It's not limited to some implemented math
formula in the framework (like it's in 'simple' EM case). It can better reflect
the real power measurements performed for each performance state. Thus, this
registration method should be preferred in case considering EM static power
(leakage) is important.
Drivers are expected to register performance domains into the EM framework by
calling the following API::
@ -113,18 +103,6 @@ to: return warning/error, stop working or panic.
See Section 3. for an example of driver implementing this
callback, or Section 2.4 for further documentation on this API
Registration of 'simple' EM
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'simple' EM is registered using the framework helper function
cpufreq_register_em_with_opp(). It implements a power model which is tight to
math formula::
Power = C * V^2 * f
The EM which is registered using this method might not reflect correctly the
physics of a real device, e.g. when static power (leakage) is important.
2.3 Accessing performance domains
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -160,10 +138,6 @@ or in Section 2.4
3. Example driver
-----------------
The CPUFreq framework supports dedicated callback for registering
the EM for a given CPU(s) 'policy' object: cpufreq_driver::register_em().
That callback has to be implemented properly for a given driver,
because the framework would call it at the right time during setup.
This section provides a simple example of a CPUFreq driver registering a
performance domain in the Energy Model framework using the (fake) 'foo'
protocol. The driver implements an est_power() function to be provided to the
@ -193,22 +167,25 @@ EM framework::
20 return 0;
21 }
22
23 static void foo_cpufreq_register_em(struct cpufreq_policy *policy)
23 static int foo_cpufreq_init(struct cpufreq_policy *policy)
24 {
25 struct em_data_callback em_cb = EM_DATA_CB(est_power);
26 struct device *cpu_dev;
27 int nr_opp;
27 int nr_opp, ret;
28
29 cpu_dev = get_cpu_device(cpumask_first(policy->cpus));
30
31 /* Find the number of OPPs for this policy */
32 nr_opp = foo_get_nr_opp(policy);
33
34 /* And register the new performance domain */
35 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus,
36 true);
37 }
31 /* Do the actual CPUFreq init work ... */
32 ret = do_foo_cpufreq_init(policy);
33 if (ret)
34 return ret;
35
36 /* Find the number of OPPs for this policy */
37 nr_opp = foo_get_nr_opp(policy);
38
39 static struct cpufreq_driver foo_cpufreq_driver = {
40 .register_em = foo_cpufreq_register_em,
41 };
39 /* And register the new performance domain */
40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus,
41 true);
42
43 return 0;
44 }

14
Documentation/power/opp.rst
View File

@ -48,9 +48,9 @@ We can represent these as three OPPs as the following {Hz, uV} tuples:
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/opp/ directory and the header
is located in include/linux/pm_opp.h. OPP library can be enabled by enabling
CONFIG_PM_OPP from power management menuconfig menu. Certain SoCs such as Texas
Instrument's OMAP framework allows to optionally boot at a certain OPP without
needing cpufreq.
CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
optionally boot at a certain OPP without needing cpufreq.
Typical usage of the OPP library is as follows::
@ -75,8 +75,8 @@ operations until that OPP could be re-enabled if possible.
OPP library facilitates this concept in its implementation. The following
operational functions operate only on available opps:
dev_pm_opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq,
dev_pm_opp_get_opp_count.
opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq,
dev_pm_opp_get_opp_count
dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer
which can then be used for dev_pm_opp_enable/disable functions to make an
@ -103,7 +103,7 @@ dev_pm_opp_add
The OPP is defined using the frequency and voltage. Once added, the OPP
is assumed to be available and control of its availability can be done
with the dev_pm_opp_enable/disable functions. OPP library
internally stores and manages this information in the dev_pm_opp struct.
internally stores and manages this information in the opp struct.
This function may be used by SoC framework to define a optimal list
as per the demands of SoC usage environment.
@ -247,7 +247,7 @@ dev_pm_opp_disable
5. OPP Data Retrieval Functions
===============================
Since OPP library abstracts away the OPP information, a set of functions to pull
information from the dev_pm_opp structure is necessary. Once an OPP pointer is
information from the OPP structure is necessary. Once an OPP pointer is
retrieved using the search functions, the following functions can be used by SoC
framework to retrieve the information represented inside the OPP layer.

14
Documentation/power/runtime_pm.rst
View File

@ -265,10 +265,6 @@ defined in include/linux/pm.h:
RPM_SUSPENDED, which means that each device is initially regarded by the
PM core as 'suspended', regardless of its real hardware status
`enum rpm_status last_status;`
- the last runtime PM status of the device captured before disabling runtime
PM for it (invalid initially and when disable_depth is 0)
`unsigned int runtime_auto;`
- if set, indicates that the user space has allowed the device driver to
power manage the device at run time via the /sys/devices/.../power/control
@ -337,12 +333,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
`int pm_runtime_resume(struct device *dev);`
- execute the subsystem-level resume callback for the device; returns 0 on
success, 1 if the device's runtime PM status is already 'active' (also if
'power.disable_depth' is nonzero, but the status was 'active' when it was
changing from 0 to 1) or error code on failure, where -EAGAIN means it may
be safe to attempt to resume the device again in future, but
'power.runtime_error' should be checked additionally, and -EACCES means
that the callback could not be run, because 'power.disable_depth' was
success, 1 if the device's runtime PM status was already 'active' or
error code on failure, where -EAGAIN means it may be safe to attempt to
resume the device again in future, but 'power.runtime_error' should be
checked additionally, and -EACCES means that 'power.disable_depth' is
different from 0
`int pm_runtime_resume_and_get(struct device *dev);`

43
Documentation/security/SCTP.rst
View File

@ -26,11 +26,11 @@ described in the `SCTP SELinux Support`_ chapter.
security_sctp_assoc_request()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Passes the ``@asoc`` and ``@chunk->skb`` of the association INIT packet to the
Passes the ``@ep`` and ``@chunk->skb`` of the association INIT packet to the
security module. Returns 0 on success, error on failure.
::
@asoc - pointer to sctp association structure.
@ep - pointer to sctp endpoint structure.
@skb - pointer to skbuff of association packet.
@ -117,9 +117,9 @@ Called whenever a new socket is created by **accept**\(2)
calls **sctp_peeloff**\(3).
::
@asoc - pointer to current sctp association structure.
@ep - pointer to current sctp endpoint structure.
@sk - pointer to current sock structure.
@newsk - pointer to new sock structure.
@sk - pointer to new sock structure.
security_inet_conn_established()
@ -151,9 +151,9 @@ establishing an association.
INIT --------------------------------------------->
sctp_sf_do_5_1B_init()
Respond to an INIT chunk.
SCTP peer endpoint "A" is asking
for a temporary association.
Call security_sctp_assoc_request()
SCTP peer endpoint "A" is
asking for an association. Call
security_sctp_assoc_request()
to set the peer label if first
association.
If not first association, check
@ -163,12 +163,9 @@ establishing an association.
| discard the packet.
|
COOKIE ECHO ------------------------------------------>
sctp_sf_do_5_1D_ce()
Respond to an COOKIE ECHO chunk.
Confirm the cookie and create a
permanent association.
Call security_sctp_assoc_request() to
do the same as for INIT chunk Response.
|
|
|
<------------------------------------------- COOKIE ACK
| |
sctp_sf_do_5_1E_ca |
@ -203,22 +200,22 @@ hooks with the SELinux specifics expanded below::
security_sctp_assoc_request()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Passes the ``@asoc`` and ``@chunk->skb`` of the association INIT packet to the
Passes the ``@ep`` and ``@chunk->skb`` of the association INIT packet to the
security module. Returns 0 on success, error on failure.
::
@asoc - pointer to sctp association structure.
@ep - pointer to sctp endpoint structure.
@skb - pointer to skbuff of association packet.
The security module performs the following operations:
IF this is the first association on ``@asoc->base.sk``, then set the peer
IF this is the first association on ``@ep->base.sk``, then set the peer
sid to that in ``@skb``. This will ensure there is only one peer sid
assigned to ``@asoc->base.sk`` that may support multiple associations.
assigned to ``@ep->base.sk`` that may support multiple associations.
ELSE validate the ``@asoc->base.sk peer_sid`` against the ``@skb peer sid``
ELSE validate the ``@ep->base.sk peer_sid`` against the ``@skb peer sid``
to determine whether the association should be allowed or denied.
Set the sctp ``@asoc sid`` to socket's sid (from ``asoc->base.sk``) with
Set the sctp ``@ep sid`` to socket's sid (from ``ep->base.sk``) with
MLS portion taken from ``@skb peer sid``. This will be used by SCTP
TCP style sockets and peeled off connections as they cause a new socket
to be generated.
@ -262,13 +259,13 @@ security_sctp_sk_clone()
Called whenever a new socket is created by **accept**\(2) (i.e. a TCP style
socket) or when a socket is 'peeled off' e.g userspace calls
**sctp_peeloff**\(3). ``security_sctp_sk_clone()`` will set the new
sockets sid and peer sid to that contained in the ``@asoc sid`` and
``@asoc peer sid`` respectively.
sockets sid and peer sid to that contained in the ``@ep sid`` and
``@ep peer sid`` respectively.
::
@asoc - pointer to current sctp association structure.
@ep - pointer to current sctp endpoint structure.
@sk - pointer to current sock structure.
@newsk - pointer to new sock structure.
@sk - pointer to new sock structure.
security_inet_conn_established()

3
Documentation/security/self-protection.rst
View File

@ -81,7 +81,8 @@ of the kernel, gaining the protection of the kernel's strict memory
permissions as described above.
For variables that are initialized once at ``__init`` time, these can
be marked with the ``__ro_after_init`` attribute.
be marked with the (new and under development) ``__ro_after_init``
attribute.
What remains are variables that are updated rarely (e.g. GDT). These
will need another infrastructure (similar to the temporary exceptions

34
Documentation/staging/tee.rst
View File

@ -184,36 +184,6 @@ order to support device enumeration. In other words, OP-TEE driver invokes this
application to retrieve a list of Trusted Applications which can be registered
as devices on the TEE bus.
OP-TEE notifications
--------------------
There are two kinds of notifications that secure world can use to make
normal world aware of some event.
1. Synchronous notifications delivered with ``OPTEE_RPC_CMD_NOTIFICATION``
using the ``OPTEE_RPC_NOTIFICATION_SEND`` parameter.
2. Asynchronous notifications delivered with a combination of a non-secure
edge-triggered interrupt and a fast call from the non-secure interrupt
handler.
Synchronous notifications are limited by depending on RPC for delivery,
this is only usable when secure world is entered with a yielding call via
``OPTEE_SMC_CALL_WITH_ARG``. This excludes such notifications from secure
world interrupt handlers.
An asynchronous notification is delivered via a non-secure edge-triggered
interrupt to an interrupt handler registered in the OP-TEE driver. The
actual notification value are retrieved with the fast call
``OPTEE_SMC_GET_ASYNC_NOTIF_VALUE``. Note that one interrupt can represent
multiple notifications.
One notification value ``OPTEE_SMC_ASYNC_NOTIF_VALUE_DO_BOTTOM_HALF`` has a
special meaning. When this value is received it means that normal world is
supposed to make a yielding call ``OPTEE_MSG_CMD_DO_BOTTOM_HALF``. This
call is done from the thread assisting the interrupt handler. This is a
building block for OP-TEE OS in secure world to implement the top half and
bottom half style of device drivers.
AMD-TEE driver
==============
@ -255,7 +225,7 @@ The following picture shows a high level overview of AMD-TEE::
+--------------------------+ +---------+--------------------+
At the lowest level (in x86), the AMD Secure Processor (ASP) driver uses the
CPU to PSP mailbox register to submit commands to the PSP. The format of the
CPU to PSP mailbox regsister to submit commands to the PSP. The format of the
command buffer is opaque to the ASP driver. It's role is to submit commands to
the secure processor and return results to AMD-TEE driver. The interface
between AMD-TEE driver and AMD Secure Processor driver can be found in [6].
@ -290,7 +260,7 @@ cancel_req driver callback is not supported by AMD-TEE.
The GlobalPlatform TEE Client API [5] can be used by the user space (client) to
talk to AMD's TEE. AMD's TEE provides a secure environment for loading, opening
a session, invoking commands and closing session with TA.
a session, invoking commands and clossing session with TA.
References
==========

2
Documentation/usb/gadget-testing.rst
View File

@ -931,7 +931,7 @@ The uac1 function provides these attributes in its function directory:
p_volume_min playback volume control min value (in 1/256 dB)
p_volume_max playback volume control max value (in 1/256 dB)
p_volume_res playback volume control resolution (in 1/256 dB)
req_number the number of pre-allocated requests for both capture
req_number the number of pre-allocated request for both capture
and playback
================ ====================================================

20
Documentation/vm/arch_pgtable_helpers.rst
View File

@ -66,11 +66,9 @@ PTE Page Table Helpers
+---------------------------+--------------------------------------------------+
| pte_mknotpresent | Invalidates a mapped PTE |
+---------------------------+--------------------------------------------------+
| ptep_clear | Clears a PTE |
| ptep_get_and_clear | Clears a PTE |
+---------------------------+--------------------------------------------------+
| ptep_get_and_clear | Clears and returns PTE |
+---------------------------+--------------------------------------------------+
| ptep_get_and_clear_full | Clears and returns PTE (batched PTE unmap) |
| ptep_get_and_clear_full | Clears a PTE |
+---------------------------+--------------------------------------------------+
| ptep_test_and_clear_young | Clears young from a PTE |
+---------------------------+--------------------------------------------------+
@ -249,12 +247,12 @@ SWAP Page Table Helpers
| __swp_to_pmd_entry | Creates a mapped PMD from a swapped entry (arch) |
+---------------------------+--------------------------------------------------+
| is_migration_entry | Tests a migration (read or write) swapped entry |
+-------------------------------+----------------------------------------------+
| is_writable_migration_entry | Tests a write migration swapped entry |
+-------------------------------+----------------------------------------------+
| make_readable_migration_entry | Creates a read migration swapped entry |
+-------------------------------+----------------------------------------------+
| make_writable_migration_entry | Creates a write migration swapped entry |
+-------------------------------+----------------------------------------------+
+---------------------------+--------------------------------------------------+
| is_write_migration_entry | Tests a write migration swapped entry |
+---------------------------+--------------------------------------------------+
| make_migration_entry_read | Converts into read migration swapped entry |
+---------------------------+--------------------------------------------------+
| make_migration_entry | Creates a migration swapped entry (read or write)|
+---------------------------+--------------------------------------------------+
[1] https://lore.kernel.org/linux-mm/20181017020930.GN30832@redhat.com/

29
Documentation/vm/damon/design.rst
View File

@ -35,17 +35,13 @@ two parts:
1. Identification of the monitoring target address range for the address space.
2. Access check of specific address range in the target space.
DAMON currently provides the implementations of the primitives for the physical
and virtual address spaces. Below two subsections describe how those work.
DAMON currently provides the implementation of the primitives for only the
virtual address spaces. Below two subsections describe how it works.
VMA-based Target Address Range Construction
-------------------------------------------
This is only for the virtual address space primitives implementation. That for
the physical address space simply asks users to manually set the monitoring
target address ranges.
Only small parts in the super-huge virtual address space of the processes are
mapped to the physical memory and accessed. Thus, tracking the unmapped
address regions is just wasteful. However, because DAMON can deal with some
@ -75,18 +71,15 @@ to make a reasonable trade-off. Below shows this in detail::
PTE Accessed-bit Based Access Check
-----------------------------------
Both of the implementations for physical and virtual address spaces use PTE
Accessed-bit for basic access checks. Only one difference is the way of
finding the relevant PTE Accessed bit(s) from the address. While the
implementation for the virtual address walks the page table for the target task
of the address, the implementation for the physical address walks every page
table having a mapping to the address. In this way, the implementations find
and clear the bit(s) for next sampling target address and checks whether the
bit(s) set again after one sampling period. This could disturb other kernel
subsystems using the Accessed bits, namely Idle page tracking and the reclaim
logic. To avoid such disturbances, DAMON makes it mutually exclusive with Idle
page tracking and uses ``PG_idle`` and ``PG_young`` page flags to solve the
conflict with the reclaim logic, as Idle page tracking does.
The implementation for the virtual address space uses PTE Accessed-bit for
basic access checks. It finds the relevant PTE Accessed bit from the address
by walking the page table for the target task of the address. In this way, the
implementation finds and clears the bit for next sampling target address and
checks whether the bit set again after one sampling period. This could disturb
other kernel subsystems using the Accessed bits, namely Idle page tracking and
the reclaim logic. To avoid such disturbances, DAMON makes it mutually
exclusive with Idle page tracking and uses ``PG_idle`` and ``PG_young`` page
flags to solve the conflict with the reclaim logic, as Idle page tracking does.
Address Space Independent Core Mechanisms

5
Documentation/vm/damon/faq.rst
View File

@ -36,9 +36,10 @@ constructions and actual access checks can be implemented and configured on the
DAMON core by the users. In this way, DAMON users can monitor any address
space with any access check technique.
Nonetheless, DAMON provides vma/rmap tracking and PTE Accessed bit check based
Nonetheless, DAMON provides vma tracking and PTE Accessed bit check based
implementations of the address space dependent functions for the virtual memory
and the physical memory by default, for a reference and convenient use.
by default, for a reference and convenient use. In near future, we will
provide those for physical memory address space.
Can I simply monitor page granularity?

1
Documentation/vm/damon/index.rst
View File

@ -27,3 +27,4 @@ workloads and systems.
faq
design
api
plans

31
Documentation/vm/frontswap.rst
View File

@ -8,6 +8,12 @@ Frontswap provides a "transcendent memory" interface for swap pages.
In some environments, dramatic performance savings may be obtained because
swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
(Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends"
and the only necessary changes to the core kernel for transcendent memory;
all other supporting code -- the "backends" -- is implemented as drivers.
See the LWN.net article `Transcendent memory in a nutshell`_
for a detailed overview of frontswap and related kernel parts)
.. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
Frontswap is so named because it can be thought of as the opposite of
@ -39,6 +45,12 @@ a disk write and, if the data is later read back, a disk read are avoided.
If a store returns failure, transcendent memory has rejected the data, and the
page can be written to swap as usual.
If a backend chooses, frontswap can be configured as a "writethrough
cache" by calling frontswap_writethrough(). In this mode, the reduction
in swap device writes is lost (and also a non-trivial performance advantage)
in order to allow the backend to arbitrarily "reclaim" space used to
store frontswap pages to more completely manage its memory usage.
Note that if a page is stored and the page already exists in transcendent memory
(a "duplicate" store), either the store succeeds and the data is overwritten,
or the store fails AND the page is invalidated. This ensures stale data may
@ -75,9 +87,11 @@ This interface is ideal when data is transformed to a different form
and size (such as with compression) or secretly moved (as might be
useful for write-balancing for some RAM-like devices). Swap pages (and
evicted page-cache pages) are a great use for this kind of slower-than-RAM-
but-much-faster-than-disk "pseudo-RAM device".
but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and
cleancache) interface to transcendent memory provides a nice way to read
and write -- and indirectly "name" -- the pages.
Frontswap with a fairly small impact on the kernel,
Frontswap -- and cleancache -- with a fairly small impact on the kernel,
provides a huge amount of flexibility for more dynamic, flexible RAM
utilization in various system configurations:
@ -255,6 +269,19 @@ the old data and ensure that it is no longer accessible. Since the
swap subsystem then writes the new data to the read swap device,
this is the correct course of action to ensure coherency.
* What is frontswap_shrink for?
When the (non-frontswap) swap subsystem swaps out a page to a real
swap device, that page is only taking up low-value pre-allocated disk
space. But if frontswap has placed a page in transcendent memory, that
page may be taking up valuable real estate. The frontswap_shrink
routine allows code outside of the swap subsystem to force pages out
of the memory managed by frontswap and back into kernel-addressable memory.
For example, in RAMster, a "suction driver" thread will attempt
to "repatriate" pages sent to a remote machine back to the local machine;
this is driven using the frontswap_shrink mechanism when memory pressure
subsides.
* Why does the frontswap patch create the new include file swapfile.h?
The frontswap code depends on some swap-subsystem-internal data

2
Documentation/vm/hmm.rst
View File

@ -360,7 +360,7 @@ between device driver specific code and shared common code:
system memory page, locks the page with ``lock_page()``, and fills in the
``dst`` array entry with::
dst[i] = migrate_pfn(page_to_pfn(dpage));
dst[i] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
Now that the driver knows that this page is being migrated, it can
invalidate device private MMU mappings and copy device private memory

29
Documentation/vm/index.rst
View File

@ -3,11 +3,27 @@ Linux Memory Management Documentation
=====================================
This is a collection of documents about the Linux memory management (mm)
subsystem internals with different level of details ranging from notes and
mailing list responses for elaborating descriptions of data structures and
algorithms. If you are looking for advice on simply allocating memory, see the
:ref:`memory_allocation`. For controlling and tuning guides, see the
:doc:`admin guide <../admin-guide/mm/index>`.
subsystem. If you are looking for advice on simply allocating memory,
see the :ref:`memory_allocation`.
User guides for MM features
===========================
The following documents provide guides for controlling and tuning
various features of the Linux memory management
.. toctree::
:maxdepth: 1
swap_numa
zswap
Kernel developers MM documentation
==================================
The below documents describe MM internals with different level of
details ranging from notes and mailing list responses to elaborate
descriptions of data structures and algorithms.
.. toctree::
:maxdepth: 1
@ -15,6 +31,7 @@ algorithms. If you are looking for advice on simply allocating memory, see the
active_mm
arch_pgtable_helpers
balance
cleancache
damon/index
free_page_reporting
frontswap
@ -30,12 +47,10 @@ algorithms. If you are looking for advice on simply allocating memory, see the
page_migration
page_frags
page_owner
page_table_check
remap_file_pages
slub
split_page_table_lock
transhuge
unevictable-lru
vmalloced-kernel-stacks
z3fold
zsmalloc

3
Documentation/vm/overcommit-accounting.rst
View File

@ -34,8 +34,7 @@ The Linux kernel supports the following overcommit handling modes
The overcommit policy is set via the sysctl ``vm.overcommit_memory``.
The overcommit amount can be set via ``vm.overcommit_ratio`` (percentage)
or ``vm.overcommit_kbytes`` (absolute value). These only have an effect
when ``vm.overcommit_memory`` is set to 2.
or ``vm.overcommit_kbytes`` (absolute value).
The current overcommit limit and amount committed are viewable in
``/proc/meminfo`` as CommitLimit and Committed_AS respectively.

14
Documentation/vm/page_migration.rst
View File

@ -205,7 +205,7 @@ which are function pointers of struct address_space_operations.
In this function, the driver should put the isolated page back into its own data
structure.
Non-LRU movable page flags
4. non-LRU movable page flags
There are two page flags for supporting non-LRU movable page.
@ -263,15 +263,15 @@ Monitoring Migration
The following events (counters) can be used to monitor page migration.
1. PGMIGRATE_SUCCESS: Normal page migration success. Each count means that a
page was migrated. If the page was a non-THP and non-hugetlb page, then
this counter is increased by one. If the page was a THP or hugetlb, then
this counter is increased by the number of THP or hugetlb subpages.
For example, migration of a single 2MB THP that has 4KB-size base pages
(subpages) will cause this counter to increase by 512.
page was migrated. If the page was a non-THP page, then this counter is
increased by one. If the page was a THP, then this counter is increased by
the number of THP subpages. For example, migration of a single 2MB THP that
has 4KB-size base pages (subpages) will cause this counter to increase by
512.
2. PGMIGRATE_FAIL: Normal page migration failure. Same counting rules as for
PGMIGRATE_SUCCESS, above: this will be increased by the number of subpages,
if it was a THP or hugetlb.
if it was a THP.
3. THP_MIGRATION_SUCCESS: A THP was migrated without being split.

23
Documentation/vm/page_owner.rst
View File

@ -85,26 +85,5 @@ Usage
cat /sys/kernel/debug/page_owner > page_owner_full.txt
./page_owner_sort page_owner_full.txt sorted_page_owner.txt
The general output of ``page_owner_full.txt`` is as follows:
Page allocated via order XXX, ...
PFN XXX ...
// Detailed stack
Page allocated via order XXX, ...
PFN XXX ...
// Detailed stack
The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows
in buf, uses regexp to extract the page order value, counts the times
and pages of buf, and finally sorts them according to the times.
See the result about who allocated each page
in the ``sorted_page_owner.txt``. General output:
XXX times, XXX pages:
Page allocated via order XXX, ...
// Detailed stack
By default, ``page_owner_sort`` is sorted according to the times of buf.
If you want to sort by the pages nums of buf, use the ``-m`` parameter.
in the ``sorted_page_owner.txt``.

1
arch/arm/Kconfig
View File

@ -1455,6 +1455,7 @@ config HIGHMEM
bool "High Memory Support"
depends on MMU
select KMAP_LOCAL
select KMAP_LOCAL_NON_LINEAR_PTE_ARRAY
help
The address space of ARM processors is only 4 Gigabytes large
and it has to accommodate user address space, kernel address

14
arch/arm/Kconfig.debug
View File

@ -410,12 +410,12 @@ choice
Say Y here if you want kernel low-level debugging support
on i.MX25.
config DEBUG_IMX21_IMX27_UART
bool "i.MX21 and i.MX27 Debug UART"
depends on SOC_IMX21 || SOC_IMX27
config DEBUG_IMX27_UART
bool "i.MX27 Debug UART"
depends on SOC_IMX27
help
Say Y here if you want kernel low-level debugging support
on i.MX21 or i.MX27.
on i.MX27.
config DEBUG_IMX28_UART
bool "i.MX28 Debug UART"
@ -1481,7 +1481,7 @@ config DEBUG_IMX_UART_PORT
int "i.MX Debug UART Port Selection"
depends on DEBUG_IMX1_UART || \
DEBUG_IMX25_UART || \
DEBUG_IMX21_IMX27_UART || \
DEBUG_IMX27_UART || \
DEBUG_IMX31_UART || \
DEBUG_IMX35_UART || \
DEBUG_IMX50_UART || \
@ -1540,12 +1540,12 @@ config DEBUG_LL_INCLUDE
default "debug/icedcc.S" if DEBUG_ICEDCC
default "debug/imx.S" if DEBUG_IMX1_UART || \
DEBUG_IMX25_UART || \
DEBUG_IMX21_IMX27_UART || \
DEBUG_IMX27_UART || \
DEBUG_IMX31_UART || \
DEBUG_IMX35_UART || \
DEBUG_IMX50_UART || \
DEBUG_IMX51_UART || \
DEBUG_IMX53_UART ||\
DEBUG_IMX53_UART || \
DEBUG_IMX6Q_UART || \
DEBUG_IMX6SL_UART || \
DEBUG_IMX6SX_UART || \

22
arch/arm/Makefile
View File

@ -60,15 +60,15 @@ KBUILD_CFLAGS += $(call cc-option,-fno-ipa-sra)
# Note that GCC does not numerically define an architecture version
# macro, but instead defines a whole series of macros which makes
# testing for a specific architecture or later rather impossible.
arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m
arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m
arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a
arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 -march=armv6
# Only override the compiler option if ARMv6. The ARMv6K extensions are
# always available in ARMv7
ifeq ($(CONFIG_CPU_32v6),y)
arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k)
arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 -march=armv6k
endif
arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 -march=armv5te
arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t
arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4
arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3m
@ -82,7 +82,7 @@ tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM740T) =-mtune=arm7tdmi
tune-$(CONFIG_CPU_ARM9TDMI) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM940T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM946E) =$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi)
tune-$(CONFIG_CPU_ARM946E) =-mtune=arm9e
tune-$(CONFIG_CPU_ARM920T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi
@ -90,11 +90,11 @@ tune-$(CONFIG_CPU_ARM926T) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_FA526) =-mtune=arm9tdmi
tune-$(CONFIG_CPU_SA110) =-mtune=strongarm110
tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100
tune-$(CONFIG_CPU_XSCALE) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_XSC3) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
tune-$(CONFIG_CPU_FEROCEON) =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
tune-$(CONFIG_CPU_V6) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
tune-$(CONFIG_CPU_V6K) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)
tune-$(CONFIG_CPU_XSCALE) =-mtune=xscale
tune-$(CONFIG_CPU_XSC3) =-mtune=xscale
tune-$(CONFIG_CPU_FEROCEON) =-mtune=xscale
tune-$(CONFIG_CPU_V6) =-mtune=arm1136j-s
tune-$(CONFIG_CPU_V6K) =-mtune=arm1136j-s
# Evaluate tune cc-option calls now
tune-y := $(tune-y)

2
arch/arm/boot/compressed/atags_to_fdt.c
View File

@ -121,7 +121,7 @@ static void hex_str(char *out, uint32_t value)
/*
* Convert and fold provided ATAGs into the provided FDT.
*
* REturn values:
* Return values:
* = 0 -> pretend success
* = 1 -> bad ATAG (may retry with another possible ATAG pointer)
* < 0 -> error from libfdt

22
arch/arm/boot/compressed/efi-header.S
View File

@ -9,16 +9,22 @@
#include <linux/sizes.h>
.macro __nop
#ifdef CONFIG_EFI_STUB
@ This is almost but not quite a NOP, since it does clobber the
@ condition flags. But it is the best we can do for EFI, since
@ PE/COFF expects the magic string "MZ" at offset 0, while the
@ ARM/Linux boot protocol expects an executable instruction
@ there.
.inst MZ_MAGIC | (0x1310 << 16) @ tstne r0, #0x4d000
#else
AR_CLASS( mov r0, r0 )
M_CLASS( nop.w )
.endm
.macro __initial_nops
#ifdef CONFIG_EFI_STUB
@ This is a two-instruction NOP, which happens to bear the
@ PE/COFF signature "MZ" in the first two bytes, so the kernel
@ is accepted as an EFI binary. Booting via the UEFI stub
@ will not execute those instructions, but the ARM/Linux
@ boot protocol does, so we need some NOPs here.
.inst MZ_MAGIC | (0xe225 << 16) @ eor r5, r5, 0x4d000
eor r5, r5, 0x4d000 @ undo previous insn
#else
__nop
__nop
#endif
.endm

3
arch/arm/boot/compressed/head.S
View File

@ -203,7 +203,8 @@ start:
* were patching the initial instructions of the kernel, i.e
* had started to exploit this "patch area".
*/
.rept 7
__initial_nops
.rept 5
__nop
.endr
#ifndef CONFIG_THUMB2_KERNEL

4
arch/arm/boot/dts/Makefile
View File

@ -16,7 +16,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2711-rpi-4-b.dtb \
bcm2711-rpi-400.dtb \
bcm2710-rpi-cm3.dtb \
bcm2711-rpi-cm4.dtb
bcm2711-rpi-cm4.dtb \
bcm2711-rpi-cm4s.dtb
dtb-$(CONFIG_ARCH_ALPINE) += \
alpine-db.dtb
@ -798,6 +799,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
logicpd-som-lv-37xx-devkit.dtb \
omap3430-sdp.dtb \
omap3-beagle.dtb \
omap3-beagle-ab4.dtb \
omap3-beagle-xm.dtb \
omap3-beagle-xm-ab.dtb \
omap3-cm-t3517.dtb \

4
arch/arm/boot/dts/armada-38x.dtsi
View File

@ -168,7 +168,7 @@ i2c1: i2c@11100 {
};
uart0: serial@12000 {
compatible = "marvell,armada-38x-uart";
compatible = "marvell,armada-38x-uart", "ns16550a";
reg = <0x12000 0x100>;
reg-shift = <2>;
interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
@ -178,7 +178,7 @@ uart0: serial@12000 {
};
uart1: serial@12100 {
compatible = "marvell,armada-38x-uart";
compatible = "marvell,armada-38x-uart", "ns16550a";
reg = <0x12100 0x100>;
reg-shift = <2>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;

2
arch/arm/boot/dts/at91-tse850-3.dts
View File

@ -262,7 +262,7 @@ &pwm0 {
&macb1 {
status = "okay";
phy-mode = "rgmii";
phy-mode = "rmii";
#address-cells = <1>;
#size-cells = <0>;

4
arch/arm/boot/dts/bcm-nsp.dtsi
View File

@ -77,7 +77,7 @@ pmu {
interrupt-affinity = <&cpu0>, <&cpu1>;
};
mpcore@19000000 {
mpcore-bus@19000000 {
compatible = "simple-bus";
ranges = <0x00000000 0x19000000 0x00023000>;
#address-cells = <1>;
@ -219,7 +219,7 @@ dma: dma@20000 {
status = "disabled";
};
sdio: sdhci@21000 {
sdio: mmc@21000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x21000 0x100>;
interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;

70
arch/arm/boot/dts/bcm2708-rpi-b-plus.dts
View File

@ -5,7 +5,6 @@
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
@ -13,6 +12,72 @@ / {
};
&gpio {
/*
* Taken from Raspberry-Pi-B-Plus-V1.2-Schematics.pdf
* RPI-BPLUS sheet 1
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD0",
"RXD0",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"SDA0",
"SCL0",
"NC", /* GPIO30 */
"LAN_RUN", /* GPIO31 */
"CAM_GPIO1", /* GPIO32 */
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"PWR_LOW_N", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
"USB_LIMIT", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT", /* GPIO40 */
"CAM_GPIO0", /* GPIO41 */
"NC", /* GPIO42 */
"NC", /* GPIO43 */
"ETH_CLK", /* GPIO44 */
"PWM1_OUT", /* GPIO45 */
"HDMI_HPD_N",
"STATUS_LED",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -116,6 +181,9 @@ &cam1_reg {
gpio = <&gpio 41 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

71
arch/arm/boot/dts/bcm2708-rpi-b-rev1.dts
View File

@ -4,7 +4,6 @@
#include "bcm2708-rpi.dtsi"
#include "bcm283x-rpi-smsc9512.dtsi"
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,model-b", "brcm,bcm2835";
@ -12,6 +11,73 @@ / {
};
&gpio {
/*
* Taken from Raspberry-Pi-Rev-1.0-Model-AB-Schematics.pdf
* RPI00021 sheet 02
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "SDA0",
"SCL0",
"SDA1",
"SCL1",
"GPIO_GCLK",
"CAM_GPIO1",
"LAN_RUN",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"NC", /* GPIO12 */
"NC", /* GPIO13 */
/* Serial port */
"TXD0",
"RXD0",
"STATUS_LED_N",
"GPIO17",
"GPIO18",
"NC", /* GPIO19 */
"NC", /* GPIO20 */
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"NC", /* GPIO26 */
"CAM_GPIO0",
/* Binary number representing build/revision */
"CONFIG0",
"CONFIG1",
"CONFIG2",
"CONFIG3",
"NC", /* GPIO32 */
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"NC", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
"NC", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT",
"NC", /* GPIO41 */
"NC", /* GPIO42 */
"NC", /* GPIO43 */
"NC", /* GPIO44 */
"PWM1_OUT",
"HDMI_HPD_P",
"SD_CARD_DET",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -123,6 +189,9 @@ &cam1_reg {
gpio = <&gpio 27 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

70
arch/arm/boot/dts/bcm2708-rpi-b.dts
View File

@ -5,7 +5,6 @@
#include "bcm283x-rpi-smsc9512.dtsi"
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,model-b", "brcm,bcm2835";
@ -13,6 +12,72 @@ / {
};
&gpio {
/*
* Taken from Raspberry-Pi-Rev-2.0-Model-AB-Schematics.pdf
* RPI00022 sheet 02
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "SDA0",
"SCL0",
"SDA1",
"SCL1",
"GPIO_GCLK",
"CAM_GPIO1",
"LAN_RUN",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"NC", /* GPIO12 */
"NC", /* GPIO13 */
/* Serial port */
"TXD0",
"RXD0",
"STATUS_LED_N",
"GPIO17",
"GPIO18",
"NC", /* GPIO19 */
"NC", /* GPIO20 */
"CAM_GPIO0",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"NC", /* GPIO26 */
"GPIO27",
"GPIO28",
"GPIO29",
"GPIO30",
"GPIO31",
"NC", /* GPIO32 */
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"NC", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
"NC", /* GPIO38 */
"NC", /* GPIO39 */
"PWM0_OUT",
"NC", /* GPIO41 */
"NC", /* GPIO42 */
"NC", /* GPIO43 */
"NC", /* GPIO44 */
"PWM1_OUT",
"HDMI_HPD_P",
"SD_CARD_DET",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -110,6 +175,9 @@ &cam1_reg {
gpio = <&gpio 21 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

87
arch/arm/boot/dts/bcm2708-rpi-cm.dts
View File

@ -8,21 +8,15 @@
/ {
compatible = "raspberrypi,compute-module", "brcm,bcm2835";
model = "Raspberry Pi Compute Module";
};
cam1_reg: cam1_reg {
compatible = "regulator-fixed";
regulator-name = "cam1-regulator";
gpio = <&gpio 2 GPIO_ACTIVE_HIGH>;
enable-active-high;
status = "disabled";
};
cam0_reg: cam0_reg {
compatible = "regulator-fixed";
regulator-name = "cam0-regulator";
gpio = <&gpio 30 GPIO_ACTIVE_HIGH>;
enable-active-high;
status = "disabled";
};
&cam1_reg {
gpio = <&gpio 2 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
cam0_reg: &cam0_regulator {
gpio = <&gpio 30 GPIO_ACTIVE_HIGH>;
};
&uart0 {
@ -30,6 +24,71 @@ &uart0 {
};
&gpio {
/*
* This is based on the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "GPIO0",
"GPIO1",
"GPIO2",
"GPIO3",
"GPIO4",
"GPIO5",
"GPIO6",
"GPIO7",
"GPIO8",
"GPIO9",
"GPIO10",
"GPIO11",
"GPIO12",
"GPIO13",
"GPIO14",
"GPIO15",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"GPIO28",
"GPIO29",
"GPIO30",
"GPIO31",
"GPIO32",
"GPIO33",
"GPIO34",
"GPIO35",
"GPIO36",
"GPIO37",
"GPIO38",
"GPIO39",
"GPIO40",
"GPIO41",
"GPIO42",
"GPIO43",
"GPIO44",
"GPIO45",
"HDMI_HPD_N",
/* Also used as ACT LED */
"EMMC_EN_N",
/* Used by eMMC */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */

4
arch/arm/boot/dts/bcm2708-rpi-cm.dtsi
View File

@ -14,5 +14,9 @@ __overrides__ {
act_led_gpio = <&act_led>,"gpios:4";
act_led_activelow = <&act_led>,"gpios:8";
act_led_trigger = <&act_led>,"linux,default-trigger";
cam0_reg = <&cam0_reg>,"status";
cam0_reg_gpio = <&cam0_reg>,"gpios:4";
cam1_reg = <&cam1_reg>,"status";
cam1_reg_gpio = <&cam1_reg>,"gpios:4";
};
};

71
arch/arm/boot/dts/bcm2708-rpi-zero-w.dts
View File

@ -5,7 +5,6 @@
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"
#include "bcm2708-rpi-bt.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,model-zero-w", "brcm,bcm2835";
@ -23,6 +22,73 @@ aliases {
};
&gpio {
/*
* This is based on the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD0",
"RXD0",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"SDA0",
"SCL0",
/* Used by BT module */
"CTS0",
"RTS0",
"TXD0",
"RXD0",
/* Used by Wifi */
"SD1_CLK",
"SD1_CMD",
"SD1_DATA0",
"SD1_DATA1",
"SD1_DATA2",
"SD1_DATA3",
"CAM_GPIO1", /* GPIO40 */
"WL_ON", /* GPIO41 */
"NC", /* GPIO42 */
"WIFI_CLK", /* GPIO43 */
"CAM_GPIO0", /* GPIO44 */
"BT_ON", /* GPIO45 */
"HDMI_HPD_N",
"STATUS_LED_N",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -167,6 +233,9 @@ &cam1_reg {
gpio = <&gpio 44 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

69
arch/arm/boot/dts/bcm2708-rpi-zero.dts
View File

@ -4,7 +4,6 @@
#include "bcm2708-rpi.dtsi"
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
@ -16,6 +15,71 @@ chosen {
};
&gpio {
/*
* This is based on the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD0",
"RXD0",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"SDA0",
"SCL0",
"NC", /* GPIO30 */
"NC", /* GPIO31 */
"CAM_GPIO1", /* GPIO32 */
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"NC", /* GPIO35 */
"NC", /* GPIO36 */
"NC", /* GPIO37 */
"NC", /* GPIO38 */
"NC", /* GPIO39 */
"NC", /* GPIO40 */
"CAM_GPIO0", /* GPIO41 */
"NC", /* GPIO42 */
"NC", /* GPIO43 */
"NC", /* GPIO44 */
"NC", /* GPIO45 */
"HDMI_HPD_N",
"STATUS_LED_N",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -114,6 +178,9 @@ &cam1_reg {
gpio = <&gpio 41 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

70
arch/arm/boot/dts/bcm2709-rpi-2-b.dts
View File

@ -5,7 +5,6 @@
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
@ -13,6 +12,72 @@ / {
};
&gpio {
/*
* Taken from rpi_SCH_2b_1p2_reduced.pdf and
* the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD0",
"RXD0",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"SDA0",
"SCL0",
"NC", /* GPIO30 */
"LAN_RUN",
"CAM_GPIO1",
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"PWR_LOW_N",
"NC", /* GPIO36 */
"NC", /* GPIO37 */
"USB_LIMIT",
"NC", /* GPIO39 */
"PWM0_OUT",
"CAM_GPIO0",
"SMPS_SCL",
"SMPS_SDA",
"ETH_CLK",
"PWM1_OUT",
"HDMI_HPD_N",
"STATUS_LED",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -116,6 +181,9 @@ &cam1_reg {
gpio = <&gpio 41 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

55
arch/arm/boot/dts/bcm270x.dtsi
View File

@ -153,6 +153,39 @@ axiperf: axiperf {
};
};
cam1_reg: cam1_regulator {
compatible = "regulator-fixed";
regulator-name = "cam1-reg";
enable-active-high;
/* Needs to be enabled, as removing a regulator is very unsafe */
status = "okay";
};
cam1_clk: cam1_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
status = "disabled";
};
cam0_regulator: cam0_regulator {
compatible = "regulator-fixed";
regulator-name = "cam0-reg";
enable-active-high;
status = "disabled";
};
cam0_clk: cam0_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
status = "disabled";
};
cam_dummy_reg: cam_dummy_reg {
compatible = "regulator-fixed";
regulator-name = "cam-dummy-reg";
status = "okay";
};
__overrides__ {
cam0-pwdn-ctrl;
cam0-pwdn;
@ -189,6 +222,28 @@ dpi_18bit_gpio2: dpi_18bit_gpio2 {
20 21>;
brcm,function = <BCM2835_FSEL_ALT2>;
};
dpi_16bit_gpio0: dpi_16bit_gpio0 {
brcm,pins = <0 1 2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19>;
brcm,function = <BCM2835_FSEL_ALT2>;
};
dpi_16bit_gpio2: dpi_16bit_gpio2 {
brcm,pins = <2 3 4 5 6 7 8 9 10 11
12 13 14 15 16 17 18 19>;
brcm,function = <BCM2835_FSEL_ALT2>;
};
dpi_16bit_cpadhi_gpio0: dpi_16bit_cpadhi_gpio0 {
brcm,pins = <0 1 2 3 4 5 6 7 8
12 13 14 15 16 17
20 21 22 23 24>;
brcm,function = <BCM2835_FSEL_ALT2>;
};
dpi_16bit_cpadhi_gpio2: dpi_16bit_cpadhi_gpio2 {
brcm,pins = <2 3 4 5 6 7 8
12 13 14 15 16 17
20 21 22 23 24>;
brcm,function = <BCM2835_FSEL_ALT2>;
};
};
&uart0 {

70
arch/arm/boot/dts/bcm2710-rpi-2-b.dts
View File

@ -5,7 +5,6 @@
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,2-model-b-rev2", "brcm,bcm2837";
@ -13,6 +12,72 @@ / {
};
&gpio {
/*
* Taken from rpi_SCH_2b_1p2_reduced.pdf and
* the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD0",
"RXD0",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"SDA0",
"SCL0",
"NC", /* GPIO30 */
"LAN_RUN",
"CAM_GPIO1",
"NC", /* GPIO33 */
"NC", /* GPIO34 */
"PWR_LOW_N",
"NC", /* GPIO36 */
"NC", /* GPIO37 */
"USB_LIMIT",
"NC", /* GPIO39 */
"PWM0_OUT",
"CAM_GPIO0",
"SMPS_SCL",
"SMPS_SDA",
"ETH_CLK",
"PWM1_OUT",
"HDMI_HPD_N",
"STATUS_LED",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -116,6 +181,9 @@ &cam1_reg {
gpio = <&gpio 41 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

80
arch/arm/boot/dts/bcm2710-rpi-3-b-plus.dts
View File

@ -6,7 +6,6 @@
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_44.dtsi"
#include "bcm271x-rpi-bt.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,3-model-b-plus", "brcm,bcm2837";
@ -24,6 +23,74 @@ aliases {
};
&gpio {
/*
* Taken from rpi_SCH_3bplus_1p0_reduced.pdf and
* the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD1",
"RXD1",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"HDMI_HPD_N",
"STATUS_LED_G",
/* Used by BT module */
"CTS0",
"RTS0",
"TXD0",
"RXD0",
/* Used by Wifi */
"SD1_CLK",
"SD1_CMD",
"SD1_DATA0",
"SD1_DATA1",
"SD1_DATA2",
"SD1_DATA3",
"PWM0_OUT",
"PWM1_OUT",
"ETH_CLK",
"WIFI_CLK",
"SDA0",
"SCL0",
"SMPS_SCL",
"SMPS_SDA",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -98,6 +165,14 @@ expgpio: expgpio {
compatible = "raspberrypi,firmware-gpio";
gpio-controller;
#gpio-cells = <2>;
gpio-line-names = "BT_ON",
"WL_ON",
"PWR_LED_R",
"LAN_RUN",
"NC",
"CAM_GPIO0",
"CAM_GPIO1",
"NC";
status = "okay";
};
};
@ -188,6 +263,9 @@ &cam1_reg {
gpio = <&expgpio 5 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

80
arch/arm/boot/dts/bcm2710-rpi-3-b.dts
View File

@ -6,7 +6,6 @@
#include "bcm283x-rpi-csi1-2lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_44.dtsi"
#include "bcm271x-rpi-bt.dtsi"
#include "bcm283x-rpi-cam1-regulator.dtsi"
/ {
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
@ -24,6 +23,74 @@ aliases {
};
&gpio {
/*
* Taken from rpi_SCH_3b_1p2_reduced.pdf and
* the official GPU firmware DT blob.
*
* Legend:
* "NC" = not connected (no rail from the SoC)
* "FOO" = GPIO line named "FOO" on the schematic
* "FOO_N" = GPIO line named "FOO" on schematic, active low
*/
gpio-line-names = "ID_SDA",
"ID_SCL",
"SDA1",
"SCL1",
"GPIO_GCLK",
"GPIO5",
"GPIO6",
"SPI_CE1_N",
"SPI_CE0_N",
"SPI_MISO",
"SPI_MOSI",
"SPI_SCLK",
"GPIO12",
"GPIO13",
/* Serial port */
"TXD1",
"RXD1",
"GPIO16",
"GPIO17",
"GPIO18",
"GPIO19",
"GPIO20",
"GPIO21",
"GPIO22",
"GPIO23",
"GPIO24",
"GPIO25",
"GPIO26",
"GPIO27",
"NC", /* GPIO 28 */
"LAN_RUN_BOOT",
/* Used by BT module */
"CTS0",
"RTS0",
"TXD0",
"RXD0",
/* Used by Wifi */
"SD1_CLK",
"SD1_CMD",
"SD1_DATA0",
"SD1_DATA1",
"SD1_DATA2",
"SD1_DATA3",
"PWM0_OUT",
"PWM1_OUT",
"ETH_CLK",
"WIFI_CLK",
"SDA0",
"SCL0",
"SMPS_SCL",
"SMPS_SDA",
/* Used by SD Card */
"SD_CLK_R",
"SD_CMD_R",
"SD_DATA0_R",
"SD_DATA1_R",
"SD_DATA2_R",
"SD_DATA3_R";
spi0_pins: spi0_pins {
brcm,pins = <9 10 11>;
brcm,function = <4>; /* alt0 */
@ -109,6 +176,14 @@ expgpio: expgpio {
compatible = "raspberrypi,firmware-gpio";
gpio-controller;
#gpio-cells = <2>;
gpio-line-names = "BT_ON",
"WL_ON",
"STATUS_LED",
"LAN_RUN",
"HDMI_HPD_N",
"CAM_GPIO0",
"CAM_GPIO1",
"PWR_LOW_N";
status = "okay";
};
};
@ -197,6 +272,9 @@ &cam1_reg {
gpio = <&expgpio 5 GPIO_ACTIVE_HIGH>;
};
cam0_reg: &cam_dummy_reg {
};
/ {
__overrides__ {
act_led_gpio = <&act_led>,"gpios:4";

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