Merge branch 'linus' into locking/core, to fix up conflicts
Conflicts: mm/page_alloc.c Signed-off-by: Ingo Molnar <mingo@kernel.org>zero-colors
commit
edc2988c54
|
@ -22,6 +22,8 @@ ifeq ($(HAVE_SPHINX),0)
|
||||||
|
|
||||||
.DEFAULT:
|
.DEFAULT:
|
||||||
$(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
|
$(warning The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the '$(SPHINXBUILD)' executable.)
|
||||||
|
@echo
|
||||||
|
@./scripts/sphinx-pre-install
|
||||||
@echo " SKIP Sphinx $@ target."
|
@echo " SKIP Sphinx $@ target."
|
||||||
|
|
||||||
else # HAVE_SPHINX
|
else # HAVE_SPHINX
|
||||||
|
@ -95,16 +97,6 @@ endif # HAVE_SPHINX
|
||||||
# The following targets are independent of HAVE_SPHINX, and the rules should
|
# The following targets are independent of HAVE_SPHINX, and the rules should
|
||||||
# work or silently pass without Sphinx.
|
# work or silently pass without Sphinx.
|
||||||
|
|
||||||
# no-ops for the Sphinx toolchain
|
|
||||||
sgmldocs:
|
|
||||||
@:
|
|
||||||
psdocs:
|
|
||||||
@:
|
|
||||||
mandocs:
|
|
||||||
@:
|
|
||||||
installmandocs:
|
|
||||||
@:
|
|
||||||
|
|
||||||
cleandocs:
|
cleandocs:
|
||||||
$(Q)rm -rf $(BUILDDIR)
|
$(Q)rm -rf $(BUILDDIR)
|
||||||
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean
|
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean
|
||||||
|
|
|
@ -60,7 +60,7 @@ Example of using a firmware operation:
|
||||||
|
|
||||||
/* some platform code, e.g. SMP initialization */
|
/* some platform code, e.g. SMP initialization */
|
||||||
|
|
||||||
__raw_writel(virt_to_phys(exynos4_secondary_startup),
|
__raw_writel(__pa_symbol(exynos4_secondary_startup),
|
||||||
CPU1_BOOT_REG);
|
CPU1_BOOT_REG);
|
||||||
|
|
||||||
/* Call Exynos specific smc call */
|
/* Call Exynos specific smc call */
|
||||||
|
|
|
@ -29,7 +29,7 @@ from load_config import loadConfig
|
||||||
# -- General configuration ------------------------------------------------
|
# -- General configuration ------------------------------------------------
|
||||||
|
|
||||||
# If your documentation needs a minimal Sphinx version, state it here.
|
# If your documentation needs a minimal Sphinx version, state it here.
|
||||||
needs_sphinx = '1.2'
|
needs_sphinx = '1.3'
|
||||||
|
|
||||||
# Add any Sphinx extension module names here, as strings. They can be
|
# Add any Sphinx extension module names here, as strings. They can be
|
||||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||||
|
@ -344,8 +344,8 @@ if major == 1 and minor > 3:
|
||||||
if major == 1 and minor <= 4:
|
if major == 1 and minor <= 4:
|
||||||
latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
|
latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
|
||||||
elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
|
elif major == 1 and (minor > 5 or (minor == 5 and patch >= 3)):
|
||||||
latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=0.5in'
|
latex_elements['sphinxsetup'] = 'hmargin=0.5in, vmargin=1in'
|
||||||
|
latex_elements['preamble'] += '\\fvset{fontsize=auto}\n'
|
||||||
|
|
||||||
# Grouping the document tree into LaTeX files. List of tuples
|
# Grouping the document tree into LaTeX files. List of tuples
|
||||||
# (source start file, target name, title,
|
# (source start file, target name, title,
|
||||||
|
|
|
@ -0,0 +1,144 @@
|
||||||
|
The genalloc/genpool subsystem
|
||||||
|
==============================
|
||||||
|
|
||||||
|
There are a number of memory-allocation subsystems in the kernel, each
|
||||||
|
aimed at a specific need. Sometimes, however, a kernel developer needs to
|
||||||
|
implement a new allocator for a specific range of special-purpose memory;
|
||||||
|
often that memory is located on a device somewhere. The author of the
|
||||||
|
driver for that device can certainly write a little allocator to get the
|
||||||
|
job done, but that is the way to fill the kernel with dozens of poorly
|
||||||
|
tested allocators. Back in 2005, Jes Sorensen lifted one of those
|
||||||
|
allocators from the sym53c8xx_2 driver and posted_ it as a generic module
|
||||||
|
for the creation of ad hoc memory allocators. This code was merged
|
||||||
|
for the 2.6.13 release; it has been modified considerably since then.
|
||||||
|
|
||||||
|
.. _posted: https://lwn.net/Articles/125842/
|
||||||
|
|
||||||
|
Code using this allocator should include <linux/genalloc.h>. The action
|
||||||
|
begins with the creation of a pool using one of:
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_create
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: devm_gen_pool_create
|
||||||
|
|
||||||
|
A call to :c:func:`gen_pool_create` will create a pool. The granularity of
|
||||||
|
allocations is set with min_alloc_order; it is a log-base-2 number like
|
||||||
|
those used by the page allocator, but it refers to bytes rather than pages.
|
||||||
|
So, if min_alloc_order is passed as 3, then all allocations will be a
|
||||||
|
multiple of eight bytes. Increasing min_alloc_order decreases the memory
|
||||||
|
required to track the memory in the pool. The nid parameter specifies
|
||||||
|
which NUMA node should be used for the allocation of the housekeeping
|
||||||
|
structures; it can be -1 if the caller doesn't care.
|
||||||
|
|
||||||
|
The "managed" interface :c:func:`devm_gen_pool_create` ties the pool to a
|
||||||
|
specific device. Among other things, it will automatically clean up the
|
||||||
|
pool when the given device is destroyed.
|
||||||
|
|
||||||
|
A pool is shut down with:
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_destroy
|
||||||
|
|
||||||
|
It's worth noting that, if there are still allocations outstanding from the
|
||||||
|
given pool, this function will take the rather extreme step of invoking
|
||||||
|
BUG(), crashing the entire system. You have been warned.
|
||||||
|
|
||||||
|
A freshly created pool has no memory to allocate. It is fairly useless in
|
||||||
|
that state, so one of the first orders of business is usually to add memory
|
||||||
|
to the pool. That can be done with one of:
|
||||||
|
|
||||||
|
.. kernel-doc:: include/linux/genalloc.h
|
||||||
|
:functions: gen_pool_add
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_add_virt
|
||||||
|
|
||||||
|
A call to :c:func:`gen_pool_add` will place the size bytes of memory
|
||||||
|
starting at addr (in the kernel's virtual address space) into the given
|
||||||
|
pool, once again using nid as the node ID for ancillary memory allocations.
|
||||||
|
The :c:func:`gen_pool_add_virt` variant associates an explicit physical
|
||||||
|
address with the memory; this is only necessary if the pool will be used
|
||||||
|
for DMA allocations.
|
||||||
|
|
||||||
|
The functions for allocating memory from the pool (and putting it back)
|
||||||
|
are:
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_alloc
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_dma_alloc
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_free
|
||||||
|
|
||||||
|
As one would expect, :c:func:`gen_pool_alloc` will allocate size< bytes
|
||||||
|
from the given pool. The :c:func:`gen_pool_dma_alloc` variant allocates
|
||||||
|
memory for use with DMA operations, returning the associated physical
|
||||||
|
address in the space pointed to by dma. This will only work if the memory
|
||||||
|
was added with :c:func:`gen_pool_add_virt`. Note that this function
|
||||||
|
departs from the usual genpool pattern of using unsigned long values to
|
||||||
|
represent kernel addresses; it returns a void * instead.
|
||||||
|
|
||||||
|
That all seems relatively simple; indeed, some developers clearly found it
|
||||||
|
to be too simple. After all, the interface above provides no control over
|
||||||
|
how the allocation functions choose which specific piece of memory to
|
||||||
|
return. If that sort of control is needed, the following functions will be
|
||||||
|
of interest:
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_alloc_algo
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_set_algo
|
||||||
|
|
||||||
|
Allocations with :c:func:`gen_pool_alloc_algo` specify an algorithm to be
|
||||||
|
used to choose the memory to be allocated; the default algorithm can be set
|
||||||
|
with :c:func:`gen_pool_set_algo`. The data value is passed to the
|
||||||
|
algorithm; most ignore it, but it is occasionally needed. One can,
|
||||||
|
naturally, write a special-purpose algorithm, but there is a fair set
|
||||||
|
already available:
|
||||||
|
|
||||||
|
- gen_pool_first_fit is a simple first-fit allocator; this is the default
|
||||||
|
algorithm if none other has been specified.
|
||||||
|
|
||||||
|
- gen_pool_first_fit_align forces the allocation to have a specific
|
||||||
|
alignment (passed via data in a genpool_data_align structure).
|
||||||
|
|
||||||
|
- gen_pool_first_fit_order_align aligns the allocation to the order of the
|
||||||
|
size. A 60-byte allocation will thus be 64-byte aligned, for example.
|
||||||
|
|
||||||
|
- gen_pool_best_fit, as one would expect, is a simple best-fit allocator.
|
||||||
|
|
||||||
|
- gen_pool_fixed_alloc allocates at a specific offset (passed in a
|
||||||
|
genpool_data_fixed structure via the data parameter) within the pool.
|
||||||
|
If the indicated memory is not available the allocation fails.
|
||||||
|
|
||||||
|
There is a handful of other functions, mostly for purposes like querying
|
||||||
|
the space available in the pool or iterating through chunks of memory.
|
||||||
|
Most users, however, should not need much beyond what has been described
|
||||||
|
above. With luck, wider awareness of this module will help to prevent the
|
||||||
|
writing of special-purpose memory allocators in the future.
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_virt_to_phys
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_for_each_chunk
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: addr_in_gen_pool
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_avail
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_size
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: gen_pool_get
|
||||||
|
|
||||||
|
.. kernel-doc:: lib/genalloc.c
|
||||||
|
:functions: of_gen_pool_get
|
|
@ -20,6 +20,7 @@ Core utilities
|
||||||
genericirq
|
genericirq
|
||||||
flexible-arrays
|
flexible-arrays
|
||||||
librs
|
librs
|
||||||
|
genalloc
|
||||||
|
|
||||||
Interfaces for kernel debugging
|
Interfaces for kernel debugging
|
||||||
===============================
|
===============================
|
||||||
|
|
|
@ -31,11 +31,13 @@ Setup
|
||||||
CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
|
CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
|
||||||
CONFIG_FRAME_POINTER, keep it enabled.
|
CONFIG_FRAME_POINTER, keep it enabled.
|
||||||
|
|
||||||
- Install that kernel on the guest.
|
- Install that kernel on the guest, turn off KASLR if necessary by adding
|
||||||
|
"nokaslr" to the kernel command line.
|
||||||
Alternatively, QEMU allows to boot the kernel directly using -kernel,
|
Alternatively, QEMU allows to boot the kernel directly using -kernel,
|
||||||
-append, -initrd command line switches. This is generally only useful if
|
-append, -initrd command line switches. This is generally only useful if
|
||||||
you do not depend on modules. See QEMU documentation for more details on
|
you do not depend on modules. See QEMU documentation for more details on
|
||||||
this mode.
|
this mode. In this case, you should build the kernel with
|
||||||
|
CONFIG_RANDOMIZE_BASE disabled if the architecture supports KASLR.
|
||||||
|
|
||||||
- Enable the gdb stub of QEMU/KVM, either
|
- Enable the gdb stub of QEMU/KVM, either
|
||||||
|
|
||||||
|
|
|
@ -348,6 +348,15 @@ default behavior is always set to 0.
|
||||||
- ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot``
|
- ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot``
|
||||||
- Enter the debugger on reboot notify.
|
- Enter the debugger on reboot notify.
|
||||||
|
|
||||||
|
Kernel parameter: ``nokaslr``
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
If the architecture that you are using enable KASLR by default,
|
||||||
|
you should consider turning it off. KASLR randomizes the
|
||||||
|
virtual address where the kernel image is mapped and confuse
|
||||||
|
gdb which resolve kernel symbol address from symbol table
|
||||||
|
of vmlinux.
|
||||||
|
|
||||||
Using kdb
|
Using kdb
|
||||||
=========
|
=========
|
||||||
|
|
||||||
|
@ -358,7 +367,7 @@ This is a quick example of how to use kdb.
|
||||||
|
|
||||||
1. Configure kgdboc at boot using kernel parameters::
|
1. Configure kgdboc at boot using kernel parameters::
|
||||||
|
|
||||||
console=ttyS0,115200 kgdboc=ttyS0,115200
|
console=ttyS0,115200 kgdboc=ttyS0,115200 nokaslr
|
||||||
|
|
||||||
OR
|
OR
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,32 @@
|
||||||
|
Synopsys DesignWare MIPI DSI host controller
|
||||||
|
============================================
|
||||||
|
|
||||||
|
This document defines device tree properties for the Synopsys DesignWare MIPI
|
||||||
|
DSI host controller. It doesn't constitue a device tree binding specification
|
||||||
|
by itself but is meant to be referenced by platform-specific device tree
|
||||||
|
bindings.
|
||||||
|
|
||||||
|
When referenced from platform device tree bindings the properties defined in
|
||||||
|
this document are defined as follows. The platform device tree bindings are
|
||||||
|
responsible for defining whether each optional property is used or not.
|
||||||
|
|
||||||
|
- reg: Memory mapped base address and length of the DesignWare MIPI DSI
|
||||||
|
host controller registers. (mandatory)
|
||||||
|
|
||||||
|
- clocks: References to all the clocks specified in the clock-names property
|
||||||
|
as specified in [1]. (mandatory)
|
||||||
|
|
||||||
|
- clock-names:
|
||||||
|
- "pclk" is the peripheral clock for either AHB and APB. (mandatory)
|
||||||
|
- "px_clk" is the pixel clock for the DPI/RGB input. (optional)
|
||||||
|
|
||||||
|
- resets: References to all the resets specified in the reset-names property
|
||||||
|
as specified in [2]. (optional)
|
||||||
|
|
||||||
|
- reset-names: string reset name, must be "apb" if used. (optional)
|
||||||
|
|
||||||
|
- panel or bridge node: see [3]. (mandatory)
|
||||||
|
|
||||||
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
|
[2] Documentation/devicetree/bindings/reset/reset.txt
|
||||||
|
[3] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
|
|
@ -25,12 +25,6 @@ Required properties:
|
||||||
size-cells must 1 and 0, respectively.
|
size-cells must 1 and 0, respectively.
|
||||||
- port: contains an endpoint node which is connected to the endpoint in the mic
|
- port: contains an endpoint node which is connected to the endpoint in the mic
|
||||||
node. The reg value muset be 0.
|
node. The reg value muset be 0.
|
||||||
- i80-if-timings: specify whether the panel which is connected to decon uses
|
|
||||||
i80 lcd interface or mipi video interface. This node contains
|
|
||||||
no timing information as that of fimd does. Because there is
|
|
||||||
no register in decon to specify i80 interface timing value,
|
|
||||||
it is not needed, but make it remain to use same kind of node
|
|
||||||
in fimd and exynos7 decon.
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
SoC specific DT entry:
|
SoC specific DT entry:
|
||||||
|
@ -59,9 +53,3 @@ decon: decon@13800000 {
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
Board specific DT entry:
|
|
||||||
&decon {
|
|
||||||
i80-if-timings {
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
|
@ -0,0 +1,52 @@
|
||||||
|
Pervasive Displays RePaper branded e-ink displays
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "pervasive,e1144cs021" for 1.44" display
|
||||||
|
"pervasive,e1190cs021" for 1.9" display
|
||||||
|
"pervasive,e2200cs021" for 2.0" display
|
||||||
|
"pervasive,e2271cs021" for 2.7" display
|
||||||
|
|
||||||
|
- panel-on-gpios: Timing controller power control
|
||||||
|
- discharge-gpios: Discharge control
|
||||||
|
- reset-gpios: RESET pin
|
||||||
|
- busy-gpios: BUSY pin
|
||||||
|
|
||||||
|
Required property for e2271cs021:
|
||||||
|
- border-gpios: Border control
|
||||||
|
|
||||||
|
The node for this driver must be a child node of a SPI controller, hence
|
||||||
|
all mandatory properties described in ../spi/spi-bus.txt must be specified.
|
||||||
|
|
||||||
|
Optional property:
|
||||||
|
- pervasive,thermal-zone: name of thermometer's thermal zone
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
display_temp: lm75@48 {
|
||||||
|
compatible = "lm75b";
|
||||||
|
reg = <0x48>;
|
||||||
|
#thermal-sensor-cells = <0>;
|
||||||
|
};
|
||||||
|
|
||||||
|
thermal-zones {
|
||||||
|
display {
|
||||||
|
polling-delay-passive = <0>;
|
||||||
|
polling-delay = <0>;
|
||||||
|
thermal-sensors = <&display_temp>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
papirus27@0{
|
||||||
|
compatible = "pervasive,e2271cs021";
|
||||||
|
reg = <0>;
|
||||||
|
|
||||||
|
spi-max-frequency = <8000000>;
|
||||||
|
|
||||||
|
panel-on-gpios = <&gpio 23 0>;
|
||||||
|
border-gpios = <&gpio 14 0>;
|
||||||
|
discharge-gpios = <&gpio 15 0>;
|
||||||
|
reset-gpios = <&gpio 24 0>;
|
||||||
|
busy-gpios = <&gpio 25 0>;
|
||||||
|
|
||||||
|
pervasive,thermal-zone = "display";
|
||||||
|
};
|
|
@ -11,7 +11,9 @@ following device-specific properties.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
|
||||||
- compatible: Shall contain "rockchip,rk3288-dw-hdmi".
|
- compatible: should be one of the following:
|
||||||
|
"rockchip,rk3288-dw-hdmi"
|
||||||
|
"rockchip,rk3399-dw-hdmi"
|
||||||
- reg: See dw_hdmi.txt.
|
- reg: See dw_hdmi.txt.
|
||||||
- reg-io-width: See dw_hdmi.txt. Shall be 4.
|
- reg-io-width: See dw_hdmi.txt. Shall be 4.
|
||||||
- interrupts: HDMI interrupt number
|
- interrupts: HDMI interrupt number
|
||||||
|
@ -30,7 +32,8 @@ Optional properties
|
||||||
I2C master controller.
|
I2C master controller.
|
||||||
- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
|
- clock-names: See dw_hdmi.txt. The "cec" clock is optional.
|
||||||
- clock-names: May contain "cec" as defined in dw_hdmi.txt.
|
- clock-names: May contain "cec" as defined in dw_hdmi.txt.
|
||||||
|
- clock-names: May contain "grf", power for grf io.
|
||||||
|
- clock-names: May contain "vpll", external clock for some hdmi phy.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
|
|
@ -8,8 +8,12 @@ Required properties:
|
||||||
- compatible: value should be one of the following
|
- compatible: value should be one of the following
|
||||||
"rockchip,rk3036-vop";
|
"rockchip,rk3036-vop";
|
||||||
"rockchip,rk3288-vop";
|
"rockchip,rk3288-vop";
|
||||||
|
"rockchip,rk3368-vop";
|
||||||
|
"rockchip,rk3366-vop";
|
||||||
"rockchip,rk3399-vop-big";
|
"rockchip,rk3399-vop-big";
|
||||||
"rockchip,rk3399-vop-lit";
|
"rockchip,rk3399-vop-lit";
|
||||||
|
"rockchip,rk3228-vop";
|
||||||
|
"rockchip,rk3328-vop";
|
||||||
|
|
||||||
- interrupts: should contain a list of all VOP IP block interrupts in the
|
- interrupts: should contain a list of all VOP IP block interrupts in the
|
||||||
order: VSYNC, LCD_SYSTEM. The interrupt specifier
|
order: VSYNC, LCD_SYSTEM. The interrupt specifier
|
||||||
|
|
|
@ -0,0 +1,22 @@
|
||||||
|
Sitronix ST7586 display panel
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "lego,ev3-lcd".
|
||||||
|
- a0-gpios: The A0 signal (since this binding is for serial mode, this is
|
||||||
|
the pin labeled D1 on the controller, not the pin labeled A0)
|
||||||
|
- reset-gpios: Reset pin
|
||||||
|
|
||||||
|
The node for this driver must be a child node of a SPI controller, hence
|
||||||
|
all mandatory properties described in ../spi/spi-bus.txt must be specified.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
|
||||||
|
|
||||||
|
Example:
|
||||||
|
display@0{
|
||||||
|
compatible = "lego,ev3-lcd";
|
||||||
|
reg = <0>;
|
||||||
|
spi-max-frequency = <10000000>;
|
||||||
|
a0-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
|
||||||
|
reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
|
||||||
|
};
|
|
@ -1,7 +1,6 @@
|
||||||
* STMicroelectronics STM32 lcd-tft display controller
|
* STMicroelectronics STM32 lcd-tft display controller
|
||||||
|
|
||||||
- ltdc: lcd-tft display controller host
|
- ltdc: lcd-tft display controller host
|
||||||
must be a sub-node of st-display-subsystem
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible: "st,stm32-ltdc"
|
- compatible: "st,stm32-ltdc"
|
||||||
- reg: Physical base address of the IP registers and length of memory mapped region.
|
- reg: Physical base address of the IP registers and length of memory mapped region.
|
||||||
|
@ -13,8 +12,40 @@
|
||||||
Required nodes:
|
Required nodes:
|
||||||
- Video port for RGB output.
|
- Video port for RGB output.
|
||||||
|
|
||||||
Example:
|
* STMicroelectronics STM32 DSI controller specific extensions to Synopsys
|
||||||
|
DesignWare MIPI DSI host controller
|
||||||
|
|
||||||
|
The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI
|
||||||
|
DSI host controller. For all mandatory properties & nodes, please refer
|
||||||
|
to the related documentation in [5].
|
||||||
|
|
||||||
|
Mandatory properties specific to STM32 DSI:
|
||||||
|
- #address-cells: Should be <1>.
|
||||||
|
- #size-cells: Should be <0>.
|
||||||
|
- compatible: "st,stm32-dsi".
|
||||||
|
- clock-names:
|
||||||
|
- phy pll reference clock string name, must be "ref".
|
||||||
|
- resets: see [5].
|
||||||
|
- reset-names: see [5].
|
||||||
|
|
||||||
|
Mandatory nodes specific to STM32 DSI:
|
||||||
|
- ports: A node containing DSI input & output port nodes with endpoint
|
||||||
|
definitions as documented in [3] & [4].
|
||||||
|
- port@0: DSI input port node, connected to the ltdc rgb output port.
|
||||||
|
- port@1: DSI output port node, connected to a panel or a bridge input port.
|
||||||
|
- panel or bridge node: A node containing the panel or bridge description as
|
||||||
|
documented in [6].
|
||||||
|
- port: panel or bridge port node, connected to the DSI output port (port@1).
|
||||||
|
|
||||||
|
Note: You can find more documentation in the following references
|
||||||
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
|
[2] Documentation/devicetree/bindings/reset/reset.txt
|
||||||
|
[3] Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||||
|
[4] Documentation/devicetree/bindings/graph.txt
|
||||||
|
[5] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
|
||||||
|
[6] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
|
||||||
|
|
||||||
|
Example 1: RGB panel
|
||||||
/ {
|
/ {
|
||||||
...
|
...
|
||||||
soc {
|
soc {
|
||||||
|
@ -34,3 +65,73 @@ Example:
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
Example 2: DSI panel
|
||||||
|
|
||||||
|
/ {
|
||||||
|
...
|
||||||
|
soc {
|
||||||
|
...
|
||||||
|
ltdc: display-controller@40016800 {
|
||||||
|
compatible = "st,stm32-ltdc";
|
||||||
|
reg = <0x40016800 0x200>;
|
||||||
|
interrupts = <88>, <89>;
|
||||||
|
resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
|
||||||
|
clocks = <&rcc 1 CLK_LCD>;
|
||||||
|
clock-names = "lcd";
|
||||||
|
|
||||||
|
port {
|
||||||
|
ltdc_out_dsi: endpoint {
|
||||||
|
remote-endpoint = <&dsi_in>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
|
dsi: dsi@40016c00 {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
compatible = "st,stm32-dsi";
|
||||||
|
reg = <0x40016c00 0x800>;
|
||||||
|
clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>;
|
||||||
|
clock-names = "ref", "pclk";
|
||||||
|
resets = <&rcc STM32F4_APB2_RESET(DSI)>;
|
||||||
|
reset-names = "apb";
|
||||||
|
|
||||||
|
ports {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
|
||||||
|
port@0 {
|
||||||
|
reg = <0>;
|
||||||
|
dsi_in: endpoint {
|
||||||
|
remote-endpoint = <<dc_out_dsi>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
port@1 {
|
||||||
|
reg = <1>;
|
||||||
|
dsi_out: endpoint {
|
||||||
|
remote-endpoint = <&dsi_in_panel>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
};
|
||||||
|
|
||||||
|
panel-dsi@0 {
|
||||||
|
reg = <0>; /* dsi virtual channel (0..3) */
|
||||||
|
compatible = ...;
|
||||||
|
enable-gpios = ...;
|
||||||
|
|
||||||
|
port {
|
||||||
|
dsi_in_panel: endpoint {
|
||||||
|
remote-endpoint = <&dsi_out>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
};
|
||||||
|
|
||||||
|
};
|
||||||
|
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
|
@ -4,15 +4,33 @@ Allwinner A10 Display Pipeline
|
||||||
The Allwinner A10 Display pipeline is composed of several components
|
The Allwinner A10 Display pipeline is composed of several components
|
||||||
that are going to be documented below:
|
that are going to be documented below:
|
||||||
|
|
||||||
For the input port of all components up to the TCON in the display
|
For all connections between components up to the TCONs in the display
|
||||||
pipeline, if there are multiple components, the local endpoint IDs
|
pipeline, when there are multiple components of the same type at the
|
||||||
must correspond to the index of the upstream block. For example, if
|
same depth, the local endpoint ID must be the same as the remote
|
||||||
the remote endpoint is Frontend 1, then the local endpoint ID must
|
component's index. For example, if the remote endpoint is Frontend 1,
|
||||||
be 1.
|
then the local endpoint ID must be 1.
|
||||||
|
|
||||||
Conversely, for the output ports of the same group, the remote endpoint
|
Frontend 0 [0] ------- [0] Backend 0 [0] ------- [0] TCON 0
|
||||||
ID must be the index of the local hardware block. If the local backend
|
[1] -- -- [1] [1] -- -- [1]
|
||||||
is backend 1, then the remote endpoint ID must be 1.
|
\ / \ /
|
||||||
|
X X
|
||||||
|
/ \ / \
|
||||||
|
[0] -- -- [0] [0] -- -- [0]
|
||||||
|
Frontend 1 [1] ------- [1] Backend 1 [1] ------- [1] TCON 1
|
||||||
|
|
||||||
|
For a two pipeline system such as the one depicted above, the lines
|
||||||
|
represent the connections between the components, while the numbers
|
||||||
|
within the square brackets corresponds to the ID of the local endpoint.
|
||||||
|
|
||||||
|
The same rule also applies to DE 2.0 mixer-TCON connections:
|
||||||
|
|
||||||
|
Mixer 0 [0] ----------- [0] TCON 0
|
||||||
|
[1] ---- ---- [1]
|
||||||
|
\ /
|
||||||
|
X
|
||||||
|
/ \
|
||||||
|
[0] ---- ---- [0]
|
||||||
|
Mixer 1 [1] ----------- [1] TCON 1
|
||||||
|
|
||||||
HDMI Encoder
|
HDMI Encoder
|
||||||
------------
|
------------
|
||||||
|
|
|
@ -11,6 +11,8 @@ Required properties for pwm-tacho node:
|
||||||
|
|
||||||
- #size-cells : should be 1.
|
- #size-cells : should be 1.
|
||||||
|
|
||||||
|
- #cooling-cells: should be 2.
|
||||||
|
|
||||||
- reg : address and length of the register set for the device.
|
- reg : address and length of the register set for the device.
|
||||||
|
|
||||||
- pinctrl-names : a pinctrl state named "default" must be defined.
|
- pinctrl-names : a pinctrl state named "default" must be defined.
|
||||||
|
@ -28,12 +30,17 @@ fan subnode format:
|
||||||
Under fan subnode there can upto 8 child nodes, with each child node
|
Under fan subnode there can upto 8 child nodes, with each child node
|
||||||
representing a fan. If there are 8 fans each fan can have one PWM port and
|
representing a fan. If there are 8 fans each fan can have one PWM port and
|
||||||
one/two Fan tach inputs.
|
one/two Fan tach inputs.
|
||||||
|
For PWM port can be configured cooling-levels to create cooling device.
|
||||||
|
Cooling device could be bound to a thermal zone for the thermal control.
|
||||||
|
|
||||||
Required properties for each child node:
|
Required properties for each child node:
|
||||||
- reg : should specify PWM source port.
|
- reg : should specify PWM source port.
|
||||||
integer value in the range 0 to 7 with 0 indicating PWM port A and
|
integer value in the range 0 to 7 with 0 indicating PWM port A and
|
||||||
7 indicating PWM port H.
|
7 indicating PWM port H.
|
||||||
|
|
||||||
|
- cooling-levels: PWM duty cycle values in a range from 0 to 255
|
||||||
|
which correspond to thermal cooling states.
|
||||||
|
|
||||||
- aspeed,fan-tach-ch : should specify the Fan tach input channel.
|
- aspeed,fan-tach-ch : should specify the Fan tach input channel.
|
||||||
integer value in the range 0 through 15, with 0 indicating
|
integer value in the range 0 through 15, with 0 indicating
|
||||||
Fan tach channel 0 and 15 indicating Fan tach channel 15.
|
Fan tach channel 0 and 15 indicating Fan tach channel 15.
|
||||||
|
@ -50,6 +57,7 @@ pwm_tacho_fixed_clk: fixedclk {
|
||||||
pwm_tacho: pwmtachocontroller@1e786000 {
|
pwm_tacho: pwmtachocontroller@1e786000 {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
|
#cooling-cells = <2>;
|
||||||
reg = <0x1E786000 0x1000>;
|
reg = <0x1E786000 0x1000>;
|
||||||
compatible = "aspeed,ast2500-pwm-tacho";
|
compatible = "aspeed,ast2500-pwm-tacho";
|
||||||
clocks = <&pwm_tacho_fixed_clk>;
|
clocks = <&pwm_tacho_fixed_clk>;
|
||||||
|
@ -58,6 +66,7 @@ pwm_tacho: pwmtachocontroller@1e786000 {
|
||||||
|
|
||||||
fan@0 {
|
fan@0 {
|
||||||
reg = <0x00>;
|
reg = <0x00>;
|
||||||
|
cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
|
||||||
aspeed,fan-tach-ch = /bits/ 8 <0x00>;
|
aspeed,fan-tach-ch = /bits/ 8 <0x00>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,21 @@
|
||||||
|
Device-tree bindings for IBM Common Form Factor Power Supply Version 1
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible = "ibm,cffps1";
|
||||||
|
- reg = < I2C bus address >; : Address of the power supply on the
|
||||||
|
I2C bus.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
i2c-bus@100 {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
#interrupt-cells = <1>;
|
||||||
|
< more properties >
|
||||||
|
|
||||||
|
power-supply@68 {
|
||||||
|
compatible = "ibm,cffps1";
|
||||||
|
reg = <0x68>;
|
||||||
|
};
|
||||||
|
};
|
|
@ -0,0 +1,10 @@
|
||||||
|
Lantiq cpu temperatur sensor
|
||||||
|
|
||||||
|
Requires node properties:
|
||||||
|
- compatible value :
|
||||||
|
"lantiq,cputemp"
|
||||||
|
|
||||||
|
Example:
|
||||||
|
cputemp@0 {
|
||||||
|
compatible = "lantiq,cputemp";
|
||||||
|
};
|
|
@ -1,84 +0,0 @@
|
||||||
* Allwinner sun8i GMAC ethernet controller
|
|
||||||
|
|
||||||
This device is a platform glue layer for stmmac.
|
|
||||||
Please see stmmac.txt for the other unchanged properties.
|
|
||||||
|
|
||||||
Required properties:
|
|
||||||
- compatible: should be one of the following string:
|
|
||||||
"allwinner,sun8i-a83t-emac"
|
|
||||||
"allwinner,sun8i-h3-emac"
|
|
||||||
"allwinner,sun8i-v3s-emac"
|
|
||||||
"allwinner,sun50i-a64-emac"
|
|
||||||
- reg: address and length of the register for the device.
|
|
||||||
- interrupts: interrupt for the device
|
|
||||||
- interrupt-names: should be "macirq"
|
|
||||||
- clocks: A phandle to the reference clock for this device
|
|
||||||
- clock-names: should be "stmmaceth"
|
|
||||||
- resets: A phandle to the reset control for this device
|
|
||||||
- reset-names: should be "stmmaceth"
|
|
||||||
- phy-mode: See ethernet.txt
|
|
||||||
- phy-handle: See ethernet.txt
|
|
||||||
- #address-cells: shall be 1
|
|
||||||
- #size-cells: shall be 0
|
|
||||||
- syscon: A phandle to the syscon of the SoC with one of the following
|
|
||||||
compatible string:
|
|
||||||
- allwinner,sun8i-h3-system-controller
|
|
||||||
- allwinner,sun8i-v3s-system-controller
|
|
||||||
- allwinner,sun50i-a64-system-controller
|
|
||||||
- allwinner,sun8i-a83t-system-controller
|
|
||||||
|
|
||||||
Optional properties:
|
|
||||||
- allwinner,tx-delay-ps: TX clock delay chain value in ps. Range value is 0-700. Default is 0)
|
|
||||||
- allwinner,rx-delay-ps: RX clock delay chain value in ps. Range value is 0-3100. Default is 0)
|
|
||||||
Both delay properties need to be a multiple of 100. They control the delay for
|
|
||||||
external PHY.
|
|
||||||
|
|
||||||
Optional properties for the following compatibles:
|
|
||||||
- "allwinner,sun8i-h3-emac",
|
|
||||||
- "allwinner,sun8i-v3s-emac":
|
|
||||||
- allwinner,leds-active-low: EPHY LEDs are active low
|
|
||||||
|
|
||||||
Required child node of emac:
|
|
||||||
- mdio bus node: should be named mdio
|
|
||||||
|
|
||||||
Required properties of the mdio node:
|
|
||||||
- #address-cells: shall be 1
|
|
||||||
- #size-cells: shall be 0
|
|
||||||
|
|
||||||
The device node referenced by "phy" or "phy-handle" should be a child node
|
|
||||||
of the mdio node. See phy.txt for the generic PHY bindings.
|
|
||||||
|
|
||||||
Required properties of the phy node with the following compatibles:
|
|
||||||
- "allwinner,sun8i-h3-emac",
|
|
||||||
- "allwinner,sun8i-v3s-emac":
|
|
||||||
- clocks: a phandle to the reference clock for the EPHY
|
|
||||||
- resets: a phandle to the reset control for the EPHY
|
|
||||||
|
|
||||||
Example:
|
|
||||||
|
|
||||||
emac: ethernet@1c0b000 {
|
|
||||||
compatible = "allwinner,sun8i-h3-emac";
|
|
||||||
syscon = <&syscon>;
|
|
||||||
reg = <0x01c0b000 0x104>;
|
|
||||||
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
|
|
||||||
interrupt-names = "macirq";
|
|
||||||
resets = <&ccu RST_BUS_EMAC>;
|
|
||||||
reset-names = "stmmaceth";
|
|
||||||
clocks = <&ccu CLK_BUS_EMAC>;
|
|
||||||
clock-names = "stmmaceth";
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
|
|
||||||
phy-handle = <&int_mii_phy>;
|
|
||||||
phy-mode = "mii";
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
mdio: mdio {
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
int_mii_phy: ethernet-phy@1 {
|
|
||||||
reg = <1>;
|
|
||||||
clocks = <&ccu CLK_BUS_EPHY>;
|
|
||||||
resets = <&ccu RST_BUS_EPHY>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
};
|
|
|
@ -249,6 +249,7 @@ oxsemi Oxford Semiconductor, Ltd.
|
||||||
panasonic Panasonic Corporation
|
panasonic Panasonic Corporation
|
||||||
parade Parade Technologies Inc.
|
parade Parade Technologies Inc.
|
||||||
pericom Pericom Technology Inc.
|
pericom Pericom Technology Inc.
|
||||||
|
pervasive Pervasive Displays, Inc.
|
||||||
phytec PHYTEC Messtechnik GmbH
|
phytec PHYTEC Messtechnik GmbH
|
||||||
picochip Picochip Ltd
|
picochip Picochip Ltd
|
||||||
pine64 Pine64
|
pine64 Pine64
|
||||||
|
|
|
@ -19,6 +19,110 @@ Finally, there are thousands of plain text documentation files scattered around
|
||||||
``Documentation``. Some of these will likely be converted to reStructuredText
|
``Documentation``. Some of these will likely be converted to reStructuredText
|
||||||
over time, but the bulk of them will remain in plain text.
|
over time, but the bulk of them will remain in plain text.
|
||||||
|
|
||||||
|
.. _sphinx_install:
|
||||||
|
|
||||||
|
Sphinx Install
|
||||||
|
==============
|
||||||
|
|
||||||
|
The ReST markups currently used by the Documentation/ files are meant to be
|
||||||
|
built with ``Sphinx`` version 1.3 or upper. If you're desiring to build
|
||||||
|
PDF outputs, it is recommended to use version 1.4.6 or upper.
|
||||||
|
|
||||||
|
There's a script that checks for the Spinx requirements. Please see
|
||||||
|
:ref:`sphinx-pre-install` for further details.
|
||||||
|
|
||||||
|
Most distributions are shipped with Sphinx, but its toolchain is fragile,
|
||||||
|
and it is not uncommon that upgrading it or some other Python packages
|
||||||
|
on your machine would cause the documentation build to break.
|
||||||
|
|
||||||
|
A way to get rid of that is to use a different version than the one shipped
|
||||||
|
on your distributions. In order to do that, it is recommended to install
|
||||||
|
Sphinx inside a virtual environment, using ``virtualenv-3``
|
||||||
|
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 upper. 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 in separate,
|
||||||
|
with ``pip install sphinx_rtd_theme``.
|
||||||
|
|
||||||
|
#) Some ReST pages contain math expressions. Due to the way Sphinx work,
|
||||||
|
those expressions are written using LaTeX notation. It needs texlive
|
||||||
|
installed with amdfonts and amsmath in order to evaluate them.
|
||||||
|
|
||||||
|
In summary, if you want to install Sphinx version 1.4.9, you should do::
|
||||||
|
|
||||||
|
$ virtualenv sphinx_1.4
|
||||||
|
$ . sphinx_1.4/bin/activate
|
||||||
|
(sphinx_1.4) $ pip install -r Documentation/sphinx/requirements.txt
|
||||||
|
|
||||||
|
After running ``. sphinx_1.4/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.
|
||||||
|
|
||||||
|
Image output
|
||||||
|
------------
|
||||||
|
|
||||||
|
The kernel documentation build system contains an extension that
|
||||||
|
handles images on both GraphViz and SVG formats (see
|
||||||
|
:ref:`sphinx_kfigure`).
|
||||||
|
|
||||||
|
For it to work, you need to install both GraphViz and ImageMagick
|
||||||
|
packages. If those packages are not installed, the build system will
|
||||||
|
still build the documentation, but won't include any images at the
|
||||||
|
output.
|
||||||
|
|
||||||
|
PDF and LaTeX builds
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
Such builds are currently supported only with Sphinx versions 1.4 and upper.
|
||||||
|
|
||||||
|
For PDF and LaTeX output, you'll also need ``XeLaTeX`` version 3.14159265.
|
||||||
|
|
||||||
|
Depending on the distribution, you may also need to install a series of
|
||||||
|
``texlive`` packages that provide the minimal set of functionalities
|
||||||
|
required for ``XeLaTeX`` to work.
|
||||||
|
|
||||||
|
.. _sphinx-pre-install:
|
||||||
|
|
||||||
|
Checking for Sphinx dependencies
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
There's a script that automatically check for Sphinx dependencies. If it can
|
||||||
|
recognize your distribution, it will also give a hint about the install
|
||||||
|
command line options for your distro::
|
||||||
|
|
||||||
|
$ ./scripts/sphinx-pre-install
|
||||||
|
Checking if the needed tools for Fedora release 26 (Twenty Six) are available
|
||||||
|
Warning: better to also install "texlive-luatex85".
|
||||||
|
You should run:
|
||||||
|
|
||||||
|
sudo dnf install -y texlive-luatex85
|
||||||
|
/usr/bin/virtualenv sphinx_1.4
|
||||||
|
. sphinx_1.4/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.
|
||||||
|
|
||||||
|
By default, it checks all the requirements for both html and PDF, including
|
||||||
|
the requirements for images, math expressions and LaTeX build, and assumes
|
||||||
|
that a virtual Python environment will be used. The ones needed for html
|
||||||
|
builds are assumed to be mandatory; the others to be optional.
|
||||||
|
|
||||||
|
It supports two optional parameters:
|
||||||
|
|
||||||
|
``--no-pdf``
|
||||||
|
Disable checks for PDF;
|
||||||
|
|
||||||
|
``--no-virtualenv``
|
||||||
|
Use OS packaging for Sphinx instead of Python virtual environment.
|
||||||
|
|
||||||
|
|
||||||
Sphinx Build
|
Sphinx Build
|
||||||
============
|
============
|
||||||
|
|
||||||
|
@ -118,7 +222,7 @@ Here are some specific guidelines for the kernel documentation:
|
||||||
the C domain
|
the C domain
|
||||||
------------
|
------------
|
||||||
|
|
||||||
The `Sphinx C Domain`_ (name c) is suited for documentation of C API. E.g. a
|
The **Sphinx C Domain** (name c) is suited for documentation of C API. E.g. a
|
||||||
function prototype:
|
function prototype:
|
||||||
|
|
||||||
.. code-block:: rst
|
.. code-block:: rst
|
||||||
|
@ -229,6 +333,7 @@ Rendered as:
|
||||||
|
|
||||||
- column 3
|
- column 3
|
||||||
|
|
||||||
|
.. _sphinx_kfigure:
|
||||||
|
|
||||||
Figures & Images
|
Figures & Images
|
||||||
================
|
================
|
||||||
|
|
|
@ -4,7 +4,7 @@ Driver Basics
|
||||||
Driver Entry and Exit points
|
Driver Entry and Exit points
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
.. kernel-doc:: include/linux/init.h
|
.. kernel-doc:: include/linux/module.h
|
||||||
:internal:
|
:internal:
|
||||||
|
|
||||||
Driver device table
|
Driver device table
|
||||||
|
@ -103,9 +103,6 @@ Kernel utility functions
|
||||||
.. kernel-doc:: kernel/panic.c
|
.. kernel-doc:: kernel/panic.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
.. kernel-doc:: kernel/sys.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
.. kernel-doc:: kernel/rcu/tree.c
|
.. kernel-doc:: kernel/rcu/tree.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
|
|
|
@ -139,9 +139,6 @@ DMA Fences
|
||||||
Seqno Hardware Fences
|
Seqno Hardware Fences
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. kernel-doc:: drivers/dma-buf/seqno-fence.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
.. kernel-doc:: include/linux/seqno-fence.h
|
.. kernel-doc:: include/linux/seqno-fence.h
|
||||||
:internal:
|
:internal:
|
||||||
|
|
||||||
|
|
|
@ -47,4 +47,3 @@ used by one consumer at a time.
|
||||||
|
|
||||||
.. kernel-doc:: drivers/pwm/core.c
|
.. kernel-doc:: drivers/pwm/core.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
|
|
|
@ -75,7 +75,7 @@ The channel-measurement facility provides a means to collect measurement
|
||||||
data which is made available by the channel subsystem for each channel
|
data which is made available by the channel subsystem for each channel
|
||||||
attached device.
|
attached device.
|
||||||
|
|
||||||
.. kernel-doc:: arch/s390/include/asm/cmb.h
|
.. kernel-doc:: arch/s390/include/uapi/asm/cmb.h
|
||||||
:internal:
|
:internal:
|
||||||
|
|
||||||
.. kernel-doc:: drivers/s390/cio/cmf.c
|
.. kernel-doc:: drivers/s390/cio/cmf.c
|
||||||
|
|
|
@ -224,14 +224,6 @@ mid to lowlevel SCSI driver interface
|
||||||
.. kernel-doc:: drivers/scsi/hosts.c
|
.. kernel-doc:: drivers/scsi/hosts.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
drivers/scsi/constants.c
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
mid to lowlevel SCSI driver interface
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/scsi/constants.c
|
|
||||||
:export:
|
|
||||||
|
|
||||||
Transport classes
|
Transport classes
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
|
|
|
@ -25,7 +25,7 @@
|
||||||
| mn10300: | ok |
|
| mn10300: | ok |
|
||||||
| nios2: | ok |
|
| nios2: | ok |
|
||||||
| openrisc: | ok |
|
| openrisc: | ok |
|
||||||
| parisc: | TODO |
|
| parisc: | ok |
|
||||||
| powerpc: | ok |
|
| powerpc: | ok |
|
||||||
| s390: | ok |
|
| s390: | ok |
|
||||||
| score: | TODO |
|
| score: | TODO |
|
||||||
|
|
|
@ -829,9 +829,7 @@ struct address_space_operations {
|
||||||
swap_activate: Called when swapon is used on a file to allocate
|
swap_activate: Called when swapon is used on a file to allocate
|
||||||
space if necessary and pin the block lookup information in
|
space if necessary and pin the block lookup information in
|
||||||
memory. A return value of zero indicates success,
|
memory. A return value of zero indicates success,
|
||||||
in which case this file can be used to back swapspace. The
|
in which case this file can be used to back swapspace.
|
||||||
swapspace operations will be proxied to this address space's
|
|
||||||
->swap_{out,in} methods.
|
|
||||||
|
|
||||||
swap_deactivate: Called during swapoff on files where swap_activate
|
swap_deactivate: Called during swapoff on files where swap_activate
|
||||||
was successful.
|
was successful.
|
||||||
|
|
|
@ -201,6 +201,8 @@ drivers.
|
||||||
Open/Close, File Operations and IOCTLs
|
Open/Close, File Operations and IOCTLs
|
||||||
======================================
|
======================================
|
||||||
|
|
||||||
|
.. _drm_driver_fops:
|
||||||
|
|
||||||
File Operations
|
File Operations
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
|
|
|
@ -296,3 +296,12 @@ Auxiliary Modeset Helpers
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
|
.. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
|
Framebuffer GEM Helper Reference
|
||||||
|
================================
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
|
||||||
|
:doc: overview
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
|
||||||
|
:export:
|
||||||
|
|
|
@ -523,9 +523,6 @@ Color Management Properties
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
|
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
|
||||||
:doc: overview
|
:doc: overview
|
||||||
|
|
||||||
.. kernel-doc:: include/drm/drm_color_mgmt.h
|
|
||||||
:internal:
|
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
|
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
|
||||||
:export:
|
:export:
|
||||||
|
|
||||||
|
@ -554,60 +551,8 @@ various modules/drivers.
|
||||||
Vertical Blanking
|
Vertical Blanking
|
||||||
=================
|
=================
|
||||||
|
|
||||||
Vertical blanking plays a major role in graphics rendering. To achieve
|
.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
|
||||||
tear-free display, users must synchronize page flips and/or rendering to
|
:doc: vblank handling
|
||||||
vertical blanking. The DRM API offers ioctls to perform page flips
|
|
||||||
synchronized to vertical blanking and wait for vertical blanking.
|
|
||||||
|
|
||||||
The DRM core handles most of the vertical blanking management logic,
|
|
||||||
which involves filtering out spurious interrupts, keeping race-free
|
|
||||||
blanking counters, coping with counter wrap-around and resets and
|
|
||||||
keeping use counts. It relies on the driver to generate vertical
|
|
||||||
blanking interrupts and optionally provide a hardware vertical blanking
|
|
||||||
counter. Drivers must implement the following operations.
|
|
||||||
|
|
||||||
- int (\*enable_vblank) (struct drm_device \*dev, int crtc); void
|
|
||||||
(\*disable_vblank) (struct drm_device \*dev, int crtc);
|
|
||||||
Enable or disable vertical blanking interrupts for the given CRTC.
|
|
||||||
|
|
||||||
- u32 (\*get_vblank_counter) (struct drm_device \*dev, int crtc);
|
|
||||||
Retrieve the value of the vertical blanking counter for the given
|
|
||||||
CRTC. If the hardware maintains a vertical blanking counter its value
|
|
||||||
should be returned. Otherwise drivers can use the
|
|
||||||
:c:func:`drm_vblank_count()` helper function to handle this
|
|
||||||
operation.
|
|
||||||
|
|
||||||
Drivers must initialize the vertical blanking handling core with a call
|
|
||||||
to :c:func:`drm_vblank_init()` in their load operation.
|
|
||||||
|
|
||||||
Vertical blanking interrupts can be enabled by the DRM core or by
|
|
||||||
drivers themselves (for instance to handle page flipping operations).
|
|
||||||
The DRM core maintains a vertical blanking use count to ensure that the
|
|
||||||
interrupts are not disabled while a user still needs them. To increment
|
|
||||||
the use count, drivers call :c:func:`drm_vblank_get()`. Upon
|
|
||||||
return vertical blanking interrupts are guaranteed to be enabled.
|
|
||||||
|
|
||||||
To decrement the use count drivers call
|
|
||||||
:c:func:`drm_vblank_put()`. Only when the use count drops to zero
|
|
||||||
will the DRM core disable the vertical blanking interrupts after a delay
|
|
||||||
by scheduling a timer. The delay is accessible through the
|
|
||||||
vblankoffdelay module parameter or the ``drm_vblank_offdelay`` global
|
|
||||||
variable and expressed in milliseconds. Its default value is 5000 ms.
|
|
||||||
Zero means never disable, and a negative value means disable
|
|
||||||
immediately. Drivers may override the behaviour by setting the
|
|
||||||
:c:type:`struct drm_device <drm_device>`
|
|
||||||
vblank_disable_immediate flag, which when set causes vblank interrupts
|
|
||||||
to be disabled immediately regardless of the drm_vblank_offdelay
|
|
||||||
value. The flag should only be set if there's a properly working
|
|
||||||
hardware vblank counter present.
|
|
||||||
|
|
||||||
When a vertical blanking interrupt occurs drivers only need to call the
|
|
||||||
:c:func:`drm_handle_vblank()` function to account for the
|
|
||||||
interrupt.
|
|
||||||
|
|
||||||
Resources allocated by :c:func:`drm_vblank_init()` must be freed
|
|
||||||
with a call to :c:func:`drm_vblank_cleanup()` in the driver unload
|
|
||||||
operation handler.
|
|
||||||
|
|
||||||
Vertical Blanking and Interrupt Handling Functions Reference
|
Vertical Blanking and Interrupt Handling Functions Reference
|
||||||
------------------------------------------------------------
|
------------------------------------------------------------
|
||||||
|
|
|
@ -191,7 +191,7 @@ acquired and release by :c:func:`calling drm_gem_object_get()` and
|
||||||
holding the lock.
|
holding the lock.
|
||||||
|
|
||||||
When the last reference to a GEM object is released the GEM core calls
|
When the last reference to a GEM object is released the GEM core calls
|
||||||
the :c:type:`struct drm_driver <drm_driver>` gem_free_object
|
the :c:type:`struct drm_driver <drm_driver>` gem_free_object_unlocked
|
||||||
operation. That operation is mandatory for GEM-enabled drivers and must
|
operation. That operation is mandatory for GEM-enabled drivers and must
|
||||||
free the GEM object and all associated resources.
|
free the GEM object and all associated resources.
|
||||||
|
|
||||||
|
@ -492,7 +492,7 @@ DRM Sync Objects
|
||||||
:doc: Overview
|
:doc: Overview
|
||||||
|
|
||||||
.. kernel-doc:: include/drm/drm_syncobj.h
|
.. kernel-doc:: include/drm/drm_syncobj.h
|
||||||
:export:
|
:internal:
|
||||||
|
|
||||||
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
|
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
|
||||||
:export:
|
:export:
|
||||||
|
|
|
@ -160,6 +160,8 @@ other hand, a driver requires shared state between clients which is
|
||||||
visible to user-space and accessible beyond open-file boundaries, they
|
visible to user-space and accessible beyond open-file boundaries, they
|
||||||
cannot support render nodes.
|
cannot support render nodes.
|
||||||
|
|
||||||
|
.. _drm_driver_ioctl:
|
||||||
|
|
||||||
IOCTL Support on Device Nodes
|
IOCTL Support on Device Nodes
|
||||||
=============================
|
=============================
|
||||||
|
|
||||||
|
|
|
@ -417,6 +417,10 @@ integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl.
|
||||||
:functions: i915_perf_open_ioctl
|
:functions: i915_perf_open_ioctl
|
||||||
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||||
:functions: i915_perf_release
|
:functions: i915_perf_release
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||||
|
:functions: i915_perf_add_config_ioctl
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||||
|
:functions: i915_perf_remove_config_ioctl
|
||||||
|
|
||||||
i915 Perf Stream
|
i915 Perf Stream
|
||||||
----------------
|
----------------
|
||||||
|
@ -477,4 +481,16 @@ specific details than found in the more high-level sections.
|
||||||
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||||
:internal:
|
:internal:
|
||||||
|
|
||||||
.. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/drm/i915/i915_irq.c
|
Style
|
||||||
|
=====
|
||||||
|
|
||||||
|
The drm/i915 driver codebase has some style rules in addition to (and, in some
|
||||||
|
cases, deviating from) the kernel coding style.
|
||||||
|
|
||||||
|
Register macro definition style
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
The style guide for ``i915_reg.h``.
|
||||||
|
|
||||||
|
.. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
|
||||||
|
:doc: The i915 register macro definition style guide
|
||||||
|
|
|
@ -108,8 +108,8 @@ This would be especially useful for tinydrm:
|
||||||
crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
|
crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
|
||||||
__drm_atomic_helper_crtc_duplicate_state().
|
__drm_atomic_helper_crtc_duplicate_state().
|
||||||
|
|
||||||
- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_
|
- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_
|
||||||
prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this
|
prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this
|
||||||
is a function useful to implement the fb->dirty function.
|
is a function useful to implement the fb->dirty function.
|
||||||
|
|
||||||
- Create a new drm_fb_dirty function which does essentially what e.g.
|
- Create a new drm_fb_dirty function which does essentially what e.g.
|
||||||
|
|
|
@ -18,6 +18,10 @@ enhancements. It can monitor up to 4 voltages, 16 temperatures and
|
||||||
8 fans. It also contains an integrated watchdog which is currently
|
8 fans. It also contains an integrated watchdog which is currently
|
||||||
implemented in this driver.
|
implemented in this driver.
|
||||||
|
|
||||||
|
To clear a temperature or fan alarm, execute the following command with the
|
||||||
|
correct path to the alarm file:
|
||||||
|
echo 0 >XXXX_alarm
|
||||||
|
|
||||||
Specification of the chip can be found here:
|
Specification of the chip can be found here:
|
||||||
ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf
|
ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf
|
||||||
ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf
|
ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf
|
||||||
|
|
|
@ -0,0 +1,54 @@
|
||||||
|
Kernel driver ibm-cffps
|
||||||
|
=======================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* IBM Common Form Factor power supply
|
||||||
|
|
||||||
|
Author: Eddie James <eajames@us.ibm.com>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver supports IBM Common Form Factor (CFF) power supplies. This driver
|
||||||
|
is a client to the core PMBus driver.
|
||||||
|
|
||||||
|
Usage Notes
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver does not auto-detect devices. You will have to instantiate the
|
||||||
|
devices explicitly. Please see Documentation/i2c/instantiating-devices for
|
||||||
|
details.
|
||||||
|
|
||||||
|
Sysfs entries
|
||||||
|
-------------
|
||||||
|
|
||||||
|
The following attributes are supported:
|
||||||
|
|
||||||
|
curr1_alarm Output current over-current alarm.
|
||||||
|
curr1_input Measured output current in mA.
|
||||||
|
curr1_label "iout1"
|
||||||
|
|
||||||
|
fan1_alarm Fan 1 warning.
|
||||||
|
fan1_fault Fan 1 fault.
|
||||||
|
fan1_input Fan 1 speed in RPM.
|
||||||
|
fan2_alarm Fan 2 warning.
|
||||||
|
fan2_fault Fan 2 fault.
|
||||||
|
fan2_input Fan 2 speed in RPM.
|
||||||
|
|
||||||
|
in1_alarm Input voltage under-voltage alarm.
|
||||||
|
in1_input Measured input voltage in mV.
|
||||||
|
in1_label "vin"
|
||||||
|
in2_alarm Output voltage over-voltage alarm.
|
||||||
|
in2_input Measured output voltage in mV.
|
||||||
|
in2_label "vout1"
|
||||||
|
|
||||||
|
power1_alarm Input fault or alarm.
|
||||||
|
power1_input Measured input power in uW.
|
||||||
|
power1_label "pin"
|
||||||
|
|
||||||
|
temp1_alarm PSU inlet ambient temperature over-temperature alarm.
|
||||||
|
temp1_input Measured PSU inlet ambient temp in millidegrees C.
|
||||||
|
temp2_alarm Secondary rectifier temp over-temperature alarm.
|
||||||
|
temp2_input Measured secondary rectifier temp in millidegrees C.
|
||||||
|
temp3_alarm ORing FET temperature over-temperature alarm.
|
||||||
|
temp3_input Measured ORing FET temperature in millidegrees C.
|
|
@ -29,6 +29,11 @@ Supported chips:
|
||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet:
|
Datasheet:
|
||||||
http://www.national.com/pf/LM/LM5066.html
|
http://www.national.com/pf/LM/LM5066.html
|
||||||
|
* Texas Instruments LM5066I
|
||||||
|
Prefix: 'lm5066i'
|
||||||
|
Addresses scanned: -
|
||||||
|
Datasheet:
|
||||||
|
http://www.ti.com/product/LM5066I
|
||||||
|
|
||||||
Author: Guenter Roeck <linux@roeck-us.net>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
@ -37,8 +42,8 @@ Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver supports hardware monitoring for National Semiconductor / TI LM25056,
|
This driver supports hardware monitoring for National Semiconductor / TI LM25056,
|
||||||
LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and
|
LM25063, LM25066, LM5064, and LM5066/LM5066I Power Management, Monitoring,
|
||||||
Protection ICs.
|
Control, and Protection ICs.
|
||||||
|
|
||||||
The driver is a client driver to the core PMBus driver. Please see
|
The driver is a client driver to the core PMBus driver. Please see
|
||||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||||
|
|
|
@ -0,0 +1,64 @@
|
||||||
|
Tag matching logic
|
||||||
|
|
||||||
|
The MPI standard defines a set of rules, known as tag-matching, for matching
|
||||||
|
source send operations to destination receives. The following parameters must
|
||||||
|
match the following source and destination parameters:
|
||||||
|
* Communicator
|
||||||
|
* User tag - wild card may be specified by the receiver
|
||||||
|
* Source rank – wild car may be specified by the receiver
|
||||||
|
* Destination rank – wild
|
||||||
|
The ordering rules require that when more than one pair of send and receive
|
||||||
|
message envelopes may match, the pair that includes the earliest posted-send
|
||||||
|
and the earliest posted-receive is the pair that must be used to satisfy the
|
||||||
|
matching operation. However, this doesn’t imply that tags are consumed in
|
||||||
|
the order they are created, e.g., a later generated tag may be consumed, if
|
||||||
|
earlier tags can’t be used to satisfy the matching rules.
|
||||||
|
|
||||||
|
When a message is sent from the sender to the receiver, the communication
|
||||||
|
library may attempt to process the operation either after or before the
|
||||||
|
corresponding matching receive is posted. If a matching receive is posted,
|
||||||
|
this is an expected message, otherwise it is called an unexpected message.
|
||||||
|
Implementations frequently use different matching schemes for these two
|
||||||
|
different matching instances.
|
||||||
|
|
||||||
|
To keep MPI library memory footprint down, MPI implementations typically use
|
||||||
|
two different protocols for this purpose:
|
||||||
|
|
||||||
|
1. The Eager protocol- the complete message is sent when the send is
|
||||||
|
processed by the sender. A completion send is received in the send_cq
|
||||||
|
notifying that the buffer can be reused.
|
||||||
|
|
||||||
|
2. The Rendezvous Protocol - the sender sends the tag-matching header,
|
||||||
|
and perhaps a portion of data when first notifying the receiver. When the
|
||||||
|
corresponding buffer is posted, the responder will use the information from
|
||||||
|
the header to initiate an RDMA READ operation directly to the matching buffer.
|
||||||
|
A fin message needs to be received in order for the buffer to be reused.
|
||||||
|
|
||||||
|
Tag matching implementation
|
||||||
|
|
||||||
|
There are two types of matching objects used, the posted receive list and the
|
||||||
|
unexpected message list. The application posts receive buffers through calls
|
||||||
|
to the MPI receive routines in the posted receive list and posts send messages
|
||||||
|
using the MPI send routines. The head of the posted receive list may be
|
||||||
|
maintained by the hardware, with the software expected to shadow this list.
|
||||||
|
|
||||||
|
When send is initiated and arrives at the receive side, if there is no
|
||||||
|
pre-posted receive for this arriving message, it is passed to the software and
|
||||||
|
placed in the unexpected message list. Otherwise the match is processed,
|
||||||
|
including rendezvous processing, if appropriate, delivering the data to the
|
||||||
|
specified receive buffer. This allows overlapping receive-side MPI tag
|
||||||
|
matching with computation.
|
||||||
|
|
||||||
|
When a receive-message is posted, the communication library will first check
|
||||||
|
the software unexpected message list for a matching receive. If a match is
|
||||||
|
found, data is delivered to the user buffer, using a software controlled
|
||||||
|
protocol. The UCX implementation uses either an eager or rendezvous protocol,
|
||||||
|
depending on data size. If no match is found, the entire pre-posted receive
|
||||||
|
list is maintained by the hardware, and there is space to add one more
|
||||||
|
pre-posted receive to this list, this receive is passed to the hardware.
|
||||||
|
Software is expected to shadow this list, to help with processing MPI cancel
|
||||||
|
operations. In addition, because hardware and software are not expected to be
|
||||||
|
tightly synchronized with respect to the tag-matching operation, this shadow
|
||||||
|
list is used to detect the case that a pre-posted receive is passed to the
|
||||||
|
hardware, as the matching unexpected message is being passed from the hardware
|
||||||
|
to the software.
|
|
@ -109,7 +109,7 @@ evdev nodes are created with minors starting with 256.
|
||||||
keyboard
|
keyboard
|
||||||
~~~~~~~~
|
~~~~~~~~
|
||||||
|
|
||||||
``keyboard`` is in-kernel input handler ad is a part of VT code. It
|
``keyboard`` is in-kernel input handler and is a part of VT code. It
|
||||||
consumes keyboard keystrokes and handles user input for VT consoles.
|
consumes keyboard keystrokes and handles user input for VT consoles.
|
||||||
|
|
||||||
mousedev
|
mousedev
|
||||||
|
|
|
@ -12,7 +12,6 @@ Linux Joystick support
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 3
|
:maxdepth: 3
|
||||||
:numbered:
|
|
||||||
|
|
||||||
joystick
|
joystick
|
||||||
joystick-api
|
joystick-api
|
||||||
|
|
|
@ -297,8 +297,8 @@ more details, with real examples.
|
||||||
ccflags-y specifies options for compiling with $(CC).
|
ccflags-y specifies options for compiling with $(CC).
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
# drivers/acpi/Makefile
|
# drivers/acpi/acpica/Makefile
|
||||||
ccflags-y := -Os
|
ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
|
||||||
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
||||||
|
|
||||||
This variable is necessary because the top Makefile owns the
|
This variable is necessary because the top Makefile owns the
|
||||||
|
|
|
@ -97,9 +97,9 @@ waiter - A waiter is a struct that is stored on the stack of a blocked
|
||||||
a process being blocked on the mutex, it is fine to allocate
|
a process being blocked on the mutex, it is fine to allocate
|
||||||
the waiter on the process's stack (local variable). This
|
the waiter on the process's stack (local variable). This
|
||||||
structure holds a pointer to the task, as well as the mutex that
|
structure holds a pointer to the task, as well as the mutex that
|
||||||
the task is blocked on. It also has the plist node structures to
|
the task is blocked on. It also has rbtree node structures to
|
||||||
place the task in the waiter_list of a mutex as well as the
|
place the task in the waiters rbtree of a mutex as well as the
|
||||||
pi_list of a mutex owner task (described below).
|
pi_waiters rbtree of a mutex owner task (described below).
|
||||||
|
|
||||||
waiter is sometimes used in reference to the task that is waiting
|
waiter is sometimes used in reference to the task that is waiting
|
||||||
on a mutex. This is the same as waiter->task.
|
on a mutex. This is the same as waiter->task.
|
||||||
|
@ -179,53 +179,34 @@ again.
|
||||||
|
|
|
|
||||||
F->L5-+
|
F->L5-+
|
||||||
|
|
||||||
|
If process G has the highest priority in the chain, then all the tasks up
|
||||||
|
the chain (A and B in this example), must have their priorities increased
|
||||||
|
to that of G.
|
||||||
|
|
||||||
Plist
|
Mutex Waiters Tree
|
||||||
-----
|
|
||||||
|
|
||||||
Before I go further and talk about how the PI chain is stored through lists
|
|
||||||
on both mutexes and processes, I'll explain the plist. This is similar to
|
|
||||||
the struct list_head functionality that is already in the kernel.
|
|
||||||
The implementation of plist is out of scope for this document, but it is
|
|
||||||
very important to understand what it does.
|
|
||||||
|
|
||||||
There are a few differences between plist and list, the most important one
|
|
||||||
being that plist is a priority sorted linked list. This means that the
|
|
||||||
priorities of the plist are sorted, such that it takes O(1) to retrieve the
|
|
||||||
highest priority item in the list. Obviously this is useful to store processes
|
|
||||||
based on their priorities.
|
|
||||||
|
|
||||||
Another difference, which is important for implementation, is that, unlike
|
|
||||||
list, the head of the list is a different element than the nodes of a list.
|
|
||||||
So the head of the list is declared as struct plist_head and nodes that will
|
|
||||||
be added to the list are declared as struct plist_node.
|
|
||||||
|
|
||||||
|
|
||||||
Mutex Waiter List
|
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
Every mutex keeps track of all the waiters that are blocked on itself. The mutex
|
Every mutex keeps track of all the waiters that are blocked on itself. The
|
||||||
has a plist to store these waiters by priority. This list is protected by
|
mutex has a rbtree to store these waiters by priority. This tree is protected
|
||||||
a spin lock that is located in the struct of the mutex. This lock is called
|
by a spin lock that is located in the struct of the mutex. This lock is called
|
||||||
wait_lock. Since the modification of the waiter list is never done in
|
wait_lock.
|
||||||
interrupt context, the wait_lock can be taken without disabling interrupts.
|
|
||||||
|
|
||||||
|
|
||||||
Task PI List
|
Task PI Tree
|
||||||
------------
|
------------
|
||||||
|
|
||||||
To keep track of the PI chains, each process has its own PI list. This is
|
To keep track of the PI chains, each process has its own PI rbtree. This is
|
||||||
a list of all top waiters of the mutexes that are owned by the process.
|
a tree of all top waiters of the mutexes that are owned by the process.
|
||||||
Note that this list only holds the top waiters and not all waiters that are
|
Note that this tree only holds the top waiters and not all waiters that are
|
||||||
blocked on mutexes owned by the process.
|
blocked on mutexes owned by the process.
|
||||||
|
|
||||||
The top of the task's PI list is always the highest priority task that
|
The top of the task's PI tree is always the highest priority task that
|
||||||
is waiting on a mutex that is owned by the task. So if the task has
|
is waiting on a mutex that is owned by the task. So if the task has
|
||||||
inherited a priority, it will always be the priority of the task that is
|
inherited a priority, it will always be the priority of the task that is
|
||||||
at the top of this list.
|
at the top of this tree.
|
||||||
|
|
||||||
This list is stored in the task structure of a process as a plist called
|
This tree is stored in the task structure of a process as a rbtree called
|
||||||
pi_list. This list is protected by a spin lock also in the task structure,
|
pi_waiters. It is protected by a spin lock also in the task structure,
|
||||||
called pi_lock. This lock may also be taken in interrupt context, so when
|
called pi_lock. This lock may also be taken in interrupt context, so when
|
||||||
locking the pi_lock, interrupts must be disabled.
|
locking the pi_lock, interrupts must be disabled.
|
||||||
|
|
||||||
|
@ -312,15 +293,12 @@ Mutex owner and flags
|
||||||
|
|
||||||
The mutex structure contains a pointer to the owner of the mutex. If the
|
The mutex structure contains a pointer to the owner of the mutex. If the
|
||||||
mutex is not owned, this owner is set to NULL. Since all architectures
|
mutex is not owned, this owner is set to NULL. Since all architectures
|
||||||
have the task structure on at least a four byte alignment (and if this is
|
have the task structure on at least a two byte alignment (and if this is
|
||||||
not true, the rtmutex.c code will be broken!), this allows for the two
|
not true, the rtmutex.c code will be broken!), this allows for the least
|
||||||
least significant bits to be used as flags. This part is also described
|
significant bit to be used as a flag. Bit 0 is used as the "Has Waiters"
|
||||||
in Documentation/rt-mutex.txt, but will also be briefly described here.
|
flag. It's set whenever there are waiters on a mutex.
|
||||||
|
|
||||||
Bit 0 is used as the "Pending Owner" flag. This is described later.
|
|
||||||
Bit 1 is used as the "Has Waiters" flags. This is also described later
|
|
||||||
in more detail, but is set whenever there are waiters on a mutex.
|
|
||||||
|
|
||||||
|
See Documentation/locking/rt-mutex.txt for further details.
|
||||||
|
|
||||||
cmpxchg Tricks
|
cmpxchg Tricks
|
||||||
--------------
|
--------------
|
||||||
|
@ -359,40 +337,31 @@ Priority adjustments
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
The implementation of the PI code in rtmutex.c has several places that a
|
The implementation of the PI code in rtmutex.c has several places that a
|
||||||
process must adjust its priority. With the help of the pi_list of a
|
process must adjust its priority. With the help of the pi_waiters of a
|
||||||
process this is rather easy to know what needs to be adjusted.
|
process this is rather easy to know what needs to be adjusted.
|
||||||
|
|
||||||
The functions implementing the task adjustments are rt_mutex_adjust_prio,
|
The functions implementing the task adjustments are rt_mutex_adjust_prio
|
||||||
__rt_mutex_adjust_prio (same as the former, but expects the task pi_lock
|
and rt_mutex_setprio. rt_mutex_setprio is only used in rt_mutex_adjust_prio.
|
||||||
to already be taken), rt_mutex_getprio, and rt_mutex_setprio.
|
|
||||||
|
|
||||||
rt_mutex_getprio and rt_mutex_setprio are only used in __rt_mutex_adjust_prio.
|
rt_mutex_adjust_prio examines the priority of the task, and the highest
|
||||||
|
priority process that is waiting any of mutexes owned by the task. Since
|
||||||
|
the pi_waiters of a task holds an order by priority of all the top waiters
|
||||||
|
of all the mutexes that the task owns, we simply need to compare the top
|
||||||
|
pi waiter to its own normal/deadline priority and take the higher one.
|
||||||
|
Then rt_mutex_setprio is called to adjust the priority of the task to the
|
||||||
|
new priority. Note that rt_mutex_setprio is defined in kernel/sched/core.c
|
||||||
|
to implement the actual change in priority.
|
||||||
|
|
||||||
rt_mutex_getprio returns the priority that the task should have. Either the
|
(Note: For the "prio" field in task_struct, the lower the number, the
|
||||||
task's own normal priority, or if a process of a higher priority is waiting on
|
higher the priority. A "prio" of 5 is of higher priority than a
|
||||||
a mutex owned by the task, then that higher priority should be returned.
|
"prio" of 10.)
|
||||||
Since the pi_list of a task holds an order by priority list of all the top
|
|
||||||
waiters of all the mutexes that the task owns, rt_mutex_getprio simply needs
|
|
||||||
to compare the top pi waiter to its own normal priority, and return the higher
|
|
||||||
priority back.
|
|
||||||
|
|
||||||
(Note: if looking at the code, you will notice that the lower number of
|
It is interesting to note that rt_mutex_adjust_prio can either increase
|
||||||
prio is returned. This is because the prio field in the task structure
|
|
||||||
is an inverse order of the actual priority. So a "prio" of 5 is
|
|
||||||
of higher priority than a "prio" of 10.)
|
|
||||||
|
|
||||||
__rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the
|
|
||||||
result does not equal the task's current priority, then rt_mutex_setprio
|
|
||||||
is called to adjust the priority of the task to the new priority.
|
|
||||||
Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the
|
|
||||||
actual change in priority.
|
|
||||||
|
|
||||||
It is interesting to note that __rt_mutex_adjust_prio can either increase
|
|
||||||
or decrease the priority of the task. In the case that a higher priority
|
or decrease the priority of the task. In the case that a higher priority
|
||||||
process has just blocked on a mutex owned by the task, __rt_mutex_adjust_prio
|
process has just blocked on a mutex owned by the task, rt_mutex_adjust_prio
|
||||||
would increase/boost the task's priority. But if a higher priority task
|
would increase/boost the task's priority. But if a higher priority task
|
||||||
were for some reason to leave the mutex (timeout or signal), this same function
|
were for some reason to leave the mutex (timeout or signal), this same function
|
||||||
would decrease/unboost the priority of the task. That is because the pi_list
|
would decrease/unboost the priority of the task. That is because the pi_waiters
|
||||||
always contains the highest priority task that is waiting on a mutex owned
|
always contains the highest priority task that is waiting on a mutex owned
|
||||||
by the task, so we only need to compare the priority of that top pi waiter
|
by the task, so we only need to compare the priority of that top pi waiter
|
||||||
to the normal priority of the given task.
|
to the normal priority of the given task.
|
||||||
|
@ -412,9 +381,10 @@ priorities.
|
||||||
|
|
||||||
rt_mutex_adjust_prio_chain is called with a task to be checked for PI
|
rt_mutex_adjust_prio_chain is called with a task to be checked for PI
|
||||||
(de)boosting (the owner of a mutex that a process is blocking on), a flag to
|
(de)boosting (the owner of a mutex that a process is blocking on), a flag to
|
||||||
check for deadlocking, the mutex that the task owns, and a pointer to a waiter
|
check for deadlocking, the mutex that the task owns, a pointer to a waiter
|
||||||
that is the process's waiter struct that is blocked on the mutex (although this
|
that is the process's waiter struct that is blocked on the mutex (although this
|
||||||
parameter may be NULL for deboosting).
|
parameter may be NULL for deboosting), a pointer to the mutex on which the task
|
||||||
|
is blocked, and a top_task as the top waiter of the mutex.
|
||||||
|
|
||||||
For this explanation, I will not mention deadlock detection. This explanation
|
For this explanation, I will not mention deadlock detection. This explanation
|
||||||
will try to stay at a high level.
|
will try to stay at a high level.
|
||||||
|
@ -424,133 +394,14 @@ that the state of the owner and lock can change when entered into this function.
|
||||||
|
|
||||||
Before this function is called, the task has already had rt_mutex_adjust_prio
|
Before this function is called, the task has already had rt_mutex_adjust_prio
|
||||||
performed on it. This means that the task is set to the priority that it
|
performed on it. This means that the task is set to the priority that it
|
||||||
should be at, but the plist nodes of the task's waiter have not been updated
|
should be at, but the rbtree nodes of the task's waiter have not been updated
|
||||||
with the new priorities, and that this task may not be in the proper locations
|
with the new priorities, and this task may not be in the proper locations
|
||||||
in the pi_lists and wait_lists that the task is blocked on. This function
|
in the pi_waiters and waiters trees that the task is blocked on. This function
|
||||||
solves all that.
|
solves all that.
|
||||||
|
|
||||||
A loop is entered, where task is the owner to be checked for PI changes that
|
The main operation of this function is summarized by Thomas Gleixner in
|
||||||
was passed by parameter (for the first iteration). The pi_lock of this task is
|
rtmutex.c. See the 'Chain walk basics and protection scope' comment for further
|
||||||
taken to prevent any more changes to the pi_list of the task. This also
|
details.
|
||||||
prevents new tasks from completing the blocking on a mutex that is owned by this
|
|
||||||
task.
|
|
||||||
|
|
||||||
If the task is not blocked on a mutex then the loop is exited. We are at
|
|
||||||
the top of the PI chain.
|
|
||||||
|
|
||||||
A check is now done to see if the original waiter (the process that is blocked
|
|
||||||
on the current mutex) is the top pi waiter of the task. That is, is this
|
|
||||||
waiter on the top of the task's pi_list. If it is not, it either means that
|
|
||||||
there is another process higher in priority that is blocked on one of the
|
|
||||||
mutexes that the task owns, or that the waiter has just woken up via a signal
|
|
||||||
or timeout and has left the PI chain. In either case, the loop is exited, since
|
|
||||||
we don't need to do any more changes to the priority of the current task, or any
|
|
||||||
task that owns a mutex that this current task is waiting on. A priority chain
|
|
||||||
walk is only needed when a new top pi waiter is made to a task.
|
|
||||||
|
|
||||||
The next check sees if the task's waiter plist node has the priority equal to
|
|
||||||
the priority the task is set at. If they are equal, then we are done with
|
|
||||||
the loop. Remember that the function started with the priority of the
|
|
||||||
task adjusted, but the plist nodes that hold the task in other processes
|
|
||||||
pi_lists have not been adjusted.
|
|
||||||
|
|
||||||
Next, we look at the mutex that the task is blocked on. The mutex's wait_lock
|
|
||||||
is taken. This is done by a spin_trylock, because the locking order of the
|
|
||||||
pi_lock and wait_lock goes in the opposite direction. If we fail to grab the
|
|
||||||
lock, the pi_lock is released, and we restart the loop.
|
|
||||||
|
|
||||||
Now that we have both the pi_lock of the task as well as the wait_lock of
|
|
||||||
the mutex the task is blocked on, we update the task's waiter's plist node
|
|
||||||
that is located on the mutex's wait_list.
|
|
||||||
|
|
||||||
Now we release the pi_lock of the task.
|
|
||||||
|
|
||||||
Next the owner of the mutex has its pi_lock taken, so we can update the
|
|
||||||
task's entry in the owner's pi_list. If the task is the highest priority
|
|
||||||
process on the mutex's wait_list, then we remove the previous top waiter
|
|
||||||
from the owner's pi_list, and replace it with the task.
|
|
||||||
|
|
||||||
Note: It is possible that the task was the current top waiter on the mutex,
|
|
||||||
in which case the task is not yet on the pi_list of the waiter. This
|
|
||||||
is OK, since plist_del does nothing if the plist node is not on any
|
|
||||||
list.
|
|
||||||
|
|
||||||
If the task was not the top waiter of the mutex, but it was before we
|
|
||||||
did the priority updates, that means we are deboosting/lowering the
|
|
||||||
task. In this case, the task is removed from the pi_list of the owner,
|
|
||||||
and the new top waiter is added.
|
|
||||||
|
|
||||||
Lastly, we unlock both the pi_lock of the task, as well as the mutex's
|
|
||||||
wait_lock, and continue the loop again. On the next iteration of the
|
|
||||||
loop, the previous owner of the mutex will be the task that will be
|
|
||||||
processed.
|
|
||||||
|
|
||||||
Note: One might think that the owner of this mutex might have changed
|
|
||||||
since we just grab the mutex's wait_lock. And one could be right.
|
|
||||||
The important thing to remember is that the owner could not have
|
|
||||||
become the task that is being processed in the PI chain, since
|
|
||||||
we have taken that task's pi_lock at the beginning of the loop.
|
|
||||||
So as long as there is an owner of this mutex that is not the same
|
|
||||||
process as the tasked being worked on, we are OK.
|
|
||||||
|
|
||||||
Looking closely at the code, one might be confused. The check for the
|
|
||||||
end of the PI chain is when the task isn't blocked on anything or the
|
|
||||||
task's waiter structure "task" element is NULL. This check is
|
|
||||||
protected only by the task's pi_lock. But the code to unlock the mutex
|
|
||||||
sets the task's waiter structure "task" element to NULL with only
|
|
||||||
the protection of the mutex's wait_lock, which was not taken yet.
|
|
||||||
Isn't this a race condition if the task becomes the new owner?
|
|
||||||
|
|
||||||
The answer is No! The trick is the spin_trylock of the mutex's
|
|
||||||
wait_lock. If we fail that lock, we release the pi_lock of the
|
|
||||||
task and continue the loop, doing the end of PI chain check again.
|
|
||||||
|
|
||||||
In the code to release the lock, the wait_lock of the mutex is held
|
|
||||||
the entire time, and it is not let go when we grab the pi_lock of the
|
|
||||||
new owner of the mutex. So if the switch of a new owner were to happen
|
|
||||||
after the check for end of the PI chain and the grabbing of the
|
|
||||||
wait_lock, the unlocking code would spin on the new owner's pi_lock
|
|
||||||
but never give up the wait_lock. So the PI chain loop is guaranteed to
|
|
||||||
fail the spin_trylock on the wait_lock, release the pi_lock, and
|
|
||||||
try again.
|
|
||||||
|
|
||||||
If you don't quite understand the above, that's OK. You don't have to,
|
|
||||||
unless you really want to make a proof out of it ;)
|
|
||||||
|
|
||||||
|
|
||||||
Pending Owners and Lock stealing
|
|
||||||
--------------------------------
|
|
||||||
|
|
||||||
One of the flags in the owner field of the mutex structure is "Pending Owner".
|
|
||||||
What this means is that an owner was chosen by the process releasing the
|
|
||||||
mutex, but that owner has yet to wake up and actually take the mutex.
|
|
||||||
|
|
||||||
Why is this important? Why can't we just give the mutex to another process
|
|
||||||
and be done with it?
|
|
||||||
|
|
||||||
The PI code is to help with real-time processes, and to let the highest
|
|
||||||
priority process run as long as possible with little latencies and delays.
|
|
||||||
If a high priority process owns a mutex that a lower priority process is
|
|
||||||
blocked on, when the mutex is released it would be given to the lower priority
|
|
||||||
process. What if the higher priority process wants to take that mutex again.
|
|
||||||
The high priority process would fail to take that mutex that it just gave up
|
|
||||||
and it would need to boost the lower priority process to run with full
|
|
||||||
latency of that critical section (since the low priority process just entered
|
|
||||||
it).
|
|
||||||
|
|
||||||
There's no reason a high priority process that gives up a mutex should be
|
|
||||||
penalized if it tries to take that mutex again. If the new owner of the
|
|
||||||
mutex has not woken up yet, there's no reason that the higher priority process
|
|
||||||
could not take that mutex away.
|
|
||||||
|
|
||||||
To solve this, we introduced Pending Ownership and Lock Stealing. When a
|
|
||||||
new process is given a mutex that it was blocked on, it is only given
|
|
||||||
pending ownership. This means that it's the new owner, unless a higher
|
|
||||||
priority process comes in and tries to grab that mutex. If a higher priority
|
|
||||||
process does come along and wants that mutex, we let the higher priority
|
|
||||||
process "steal" the mutex from the pending owner (only if it is still pending)
|
|
||||||
and continue with the mutex.
|
|
||||||
|
|
||||||
|
|
||||||
Taking of a mutex (The walk through)
|
Taking of a mutex (The walk through)
|
||||||
------------------------------------
|
------------------------------------
|
||||||
|
@ -563,14 +414,14 @@ done when we have CMPXCHG enabled (otherwise the fast taking automatically
|
||||||
fails). Only when the owner field of the mutex is NULL can the lock be
|
fails). Only when the owner field of the mutex is NULL can the lock be
|
||||||
taken with the CMPXCHG and nothing else needs to be done.
|
taken with the CMPXCHG and nothing else needs to be done.
|
||||||
|
|
||||||
If there is contention on the lock, whether it is owned or pending owner
|
If there is contention on the lock, we go about the slow path
|
||||||
we go about the slow path (rt_mutex_slowlock).
|
(rt_mutex_slowlock).
|
||||||
|
|
||||||
The slow path function is where the task's waiter structure is created on
|
The slow path function is where the task's waiter structure is created on
|
||||||
the stack. This is because the waiter structure is only needed for the
|
the stack. This is because the waiter structure is only needed for the
|
||||||
scope of this function. The waiter structure holds the nodes to store
|
scope of this function. The waiter structure holds the nodes to store
|
||||||
the task on the wait_list of the mutex, and if need be, the pi_list of
|
the task on the waiters tree of the mutex, and if need be, the pi_waiters
|
||||||
the owner.
|
tree of the owner.
|
||||||
|
|
||||||
The wait_lock of the mutex is taken since the slow path of unlocking the
|
The wait_lock of the mutex is taken since the slow path of unlocking the
|
||||||
mutex also takes this lock.
|
mutex also takes this lock.
|
||||||
|
@ -581,102 +432,45 @@ contention).
|
||||||
|
|
||||||
try_to_take_rt_mutex is used every time the task tries to grab a mutex in the
|
try_to_take_rt_mutex is used every time the task tries to grab a mutex in the
|
||||||
slow path. The first thing that is done here is an atomic setting of
|
slow path. The first thing that is done here is an atomic setting of
|
||||||
the "Has Waiters" flag of the mutex's owner field. Yes, this could really
|
the "Has Waiters" flag of the mutex's owner field. By setting this flag
|
||||||
be false, because if the mutex has no owner, there are no waiters and
|
now, the current owner of the mutex being contended for can't release the mutex
|
||||||
the current task also won't have any waiters. But we don't have the lock
|
without going into the slow unlock path, and it would then need to grab the
|
||||||
yet, so we assume we are going to be a waiter. The reason for this is to
|
wait_lock, which this code currently holds. So setting the "Has Waiters" flag
|
||||||
play nice for those architectures that do have CMPXCHG. By setting this flag
|
forces the current owner to synchronize with this code.
|
||||||
now, the owner of the mutex can't release the mutex without going into the
|
|
||||||
slow unlock path, and it would then need to grab the wait_lock, which this
|
|
||||||
code currently holds. So setting the "Has Waiters" flag forces the owner
|
|
||||||
to synchronize with this code.
|
|
||||||
|
|
||||||
Now that we know that we can't have any races with the owner releasing the
|
The lock is taken if the following are true:
|
||||||
mutex, we check to see if we can take the ownership. This is done if the
|
1) The lock has no owner
|
||||||
mutex doesn't have a owner, or if we can steal the mutex from a pending
|
2) The current task is the highest priority against all other
|
||||||
owner. Let's look at the situations we have here.
|
waiters of the lock
|
||||||
|
|
||||||
1) Has owner that is pending
|
If the task succeeds to acquire the lock, then the task is set as the
|
||||||
----------------------------
|
owner of the lock, and if the lock still has waiters, the top_waiter
|
||||||
|
(highest priority task waiting on the lock) is added to this task's
|
||||||
|
pi_waiters tree.
|
||||||
|
|
||||||
The mutex has a owner, but it hasn't woken up and the mutex flag
|
If the lock is not taken by try_to_take_rt_mutex(), then the
|
||||||
"Pending Owner" is set. The first check is to see if the owner isn't the
|
task_blocks_on_rt_mutex() function is called. This will add the task to
|
||||||
current task. This is because this function is also used for the pending
|
the lock's waiter tree and propagate the pi chain of the lock as well
|
||||||
owner to grab the mutex. When a pending owner wakes up, it checks to see
|
as the lock's owner's pi_waiters tree. This is described in the next
|
||||||
if it can take the mutex, and this is done if the owner is already set to
|
section.
|
||||||
itself. If so, we succeed and leave the function, clearing the "Pending
|
|
||||||
Owner" bit.
|
|
||||||
|
|
||||||
If the pending owner is not current, we check to see if the current priority is
|
|
||||||
higher than the pending owner. If not, we fail the function and return.
|
|
||||||
|
|
||||||
There's also something special about a pending owner. That is a pending owner
|
|
||||||
is never blocked on a mutex. So there is no PI chain to worry about. It also
|
|
||||||
means that if the mutex doesn't have any waiters, there's no accounting needed
|
|
||||||
to update the pending owner's pi_list, since we only worry about processes
|
|
||||||
blocked on the current mutex.
|
|
||||||
|
|
||||||
If there are waiters on this mutex, and we just stole the ownership, we need
|
|
||||||
to take the top waiter, remove it from the pi_list of the pending owner, and
|
|
||||||
add it to the current pi_list. Note that at this moment, the pending owner
|
|
||||||
is no longer on the list of waiters. This is fine, since the pending owner
|
|
||||||
would add itself back when it realizes that it had the ownership stolen
|
|
||||||
from itself. When the pending owner tries to grab the mutex, it will fail
|
|
||||||
in try_to_take_rt_mutex if the owner field points to another process.
|
|
||||||
|
|
||||||
2) No owner
|
|
||||||
-----------
|
|
||||||
|
|
||||||
If there is no owner (or we successfully stole the lock), we set the owner
|
|
||||||
of the mutex to current, and set the flag of "Has Waiters" if the current
|
|
||||||
mutex actually has waiters, or we clear the flag if it doesn't. See, it was
|
|
||||||
OK that we set that flag early, since now it is cleared.
|
|
||||||
|
|
||||||
3) Failed to grab ownership
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
The most interesting case is when we fail to take ownership. This means that
|
|
||||||
there exists an owner, or there's a pending owner with equal or higher
|
|
||||||
priority than the current task.
|
|
||||||
|
|
||||||
We'll continue on the failed case.
|
|
||||||
|
|
||||||
If the mutex has a timeout, we set up a timer to go off to break us out
|
|
||||||
of this mutex if we failed to get it after a specified amount of time.
|
|
||||||
|
|
||||||
Now we enter a loop that will continue to try to take ownership of the mutex, or
|
|
||||||
fail from a timeout or signal.
|
|
||||||
|
|
||||||
Once again we try to take the mutex. This will usually fail the first time
|
|
||||||
in the loop, since it had just failed to get the mutex. But the second time
|
|
||||||
in the loop, this would likely succeed, since the task would likely be
|
|
||||||
the pending owner.
|
|
||||||
|
|
||||||
If the mutex is TASK_INTERRUPTIBLE a check for signals and timeout is done
|
|
||||||
here.
|
|
||||||
|
|
||||||
The waiter structure has a "task" field that points to the task that is blocked
|
|
||||||
on the mutex. This field can be NULL the first time it goes through the loop
|
|
||||||
or if the task is a pending owner and had its mutex stolen. If the "task"
|
|
||||||
field is NULL then we need to set up the accounting for it.
|
|
||||||
|
|
||||||
Task blocks on mutex
|
Task blocks on mutex
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
The accounting of a mutex and process is done with the waiter structure of
|
The accounting of a mutex and process is done with the waiter structure of
|
||||||
the process. The "task" field is set to the process, and the "lock" field
|
the process. The "task" field is set to the process, and the "lock" field
|
||||||
to the mutex. The plist nodes are initialized to the processes current
|
to the mutex. The rbtree node of waiter are initialized to the processes
|
||||||
priority.
|
current priority.
|
||||||
|
|
||||||
Since the wait_lock was taken at the entry of the slow lock, we can safely
|
Since the wait_lock was taken at the entry of the slow lock, we can safely
|
||||||
add the waiter to the wait_list. If the current process is the highest
|
add the waiter to the task waiter tree. If the current process is the
|
||||||
priority process currently waiting on this mutex, then we remove the
|
highest priority process currently waiting on this mutex, then we remove the
|
||||||
previous top waiter process (if it exists) from the pi_list of the owner,
|
previous top waiter process (if it exists) from the pi_waiters of the owner,
|
||||||
and add the current process to that list. Since the pi_list of the owner
|
and add the current process to that tree. Since the pi_waiter of the owner
|
||||||
has changed, we call rt_mutex_adjust_prio on the owner to see if the owner
|
has changed, we call rt_mutex_adjust_prio on the owner to see if the owner
|
||||||
should adjust its priority accordingly.
|
should adjust its priority accordingly.
|
||||||
|
|
||||||
If the owner is also blocked on a lock, and had its pi_list changed
|
If the owner is also blocked on a lock, and had its pi_waiters changed
|
||||||
(or deadlock checking is on), we unlock the wait_lock of the mutex and go ahead
|
(or deadlock checking is on), we unlock the wait_lock of the mutex and go ahead
|
||||||
and run rt_mutex_adjust_prio_chain on the owner, as described earlier.
|
and run rt_mutex_adjust_prio_chain on the owner, as described earlier.
|
||||||
|
|
||||||
|
@ -686,30 +480,23 @@ mutex (waiter "task" field is not NULL), then we go to sleep (call schedule).
|
||||||
Waking up in the loop
|
Waking up in the loop
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
The schedule can then wake up for a few reasons.
|
The task can then wake up for a couple of reasons:
|
||||||
1) we were given pending ownership of the mutex.
|
1) The previous lock owner released the lock, and the task now is top_waiter
|
||||||
2) we received a signal and was TASK_INTERRUPTIBLE
|
2) we received a signal or timeout
|
||||||
3) we had a timeout and was TASK_INTERRUPTIBLE
|
|
||||||
|
|
||||||
In any of these cases, we continue the loop and once again try to grab the
|
In both cases, the task will try again to acquire the lock. If it
|
||||||
ownership of the mutex. If we succeed, we exit the loop, otherwise we continue
|
does, then it will take itself off the waiters tree and set itself back
|
||||||
and on signal and timeout, will exit the loop, or if we had the mutex stolen
|
to the TASK_RUNNING state.
|
||||||
we just simply add ourselves back on the lists and go back to sleep.
|
|
||||||
|
|
||||||
Note: For various reasons, because of timeout and signals, the steal mutex
|
In first case, if the lock was acquired by another task before this task
|
||||||
algorithm needs to be careful. This is because the current process is
|
could get the lock, then it will go back to sleep and wait to be woken again.
|
||||||
still on the wait_list. And because of dynamic changing of priorities,
|
|
||||||
especially on SCHED_OTHER tasks, the current process can be the
|
|
||||||
highest priority task on the wait_list.
|
|
||||||
|
|
||||||
Failed to get mutex on Timeout or Signal
|
The second case is only applicable for tasks that are grabbing a mutex
|
||||||
----------------------------------------
|
that can wake up before getting the lock, either due to a signal or
|
||||||
|
a timeout (i.e. rt_mutex_timed_futex_lock()). When woken, it will try to
|
||||||
If a timeout or signal occurred, the waiter's "task" field would not be
|
take the lock again, if it succeeds, then the task will return with the
|
||||||
NULL and the task needs to be taken off the wait_list of the mutex and perhaps
|
lock held, otherwise it will return with -EINTR if the task was woken
|
||||||
pi_list of the owner. If this process was a high priority process, then
|
by a signal, or -ETIMEDOUT if it timed out.
|
||||||
the rt_mutex_adjust_prio_chain needs to be executed again on the owner,
|
|
||||||
but this time it will be lowering the priorities.
|
|
||||||
|
|
||||||
|
|
||||||
Unlocking the Mutex
|
Unlocking the Mutex
|
||||||
|
@ -739,25 +526,12 @@ owner still needs to make this check. If there are no waiters then the mutex
|
||||||
owner field is set to NULL, the wait_lock is released and nothing more is
|
owner field is set to NULL, the wait_lock is released and nothing more is
|
||||||
needed.
|
needed.
|
||||||
|
|
||||||
If there are waiters, then we need to wake one up and give that waiter
|
If there are waiters, then we need to wake one up.
|
||||||
pending ownership.
|
|
||||||
|
|
||||||
On the wake up code, the pi_lock of the current owner is taken. The top
|
On the wake up code, the pi_lock of the current owner is taken. The top
|
||||||
waiter of the lock is found and removed from the wait_list of the mutex
|
waiter of the lock is found and removed from the waiters tree of the mutex
|
||||||
as well as the pi_list of the current owner. The task field of the new
|
as well as the pi_waiters tree of the current owner. The "Has Waiters" bit is
|
||||||
pending owner's waiter structure is set to NULL, and the owner field of the
|
marked to prevent lower priority tasks from stealing the lock.
|
||||||
mutex is set to the new owner with the "Pending Owner" bit set, as well
|
|
||||||
as the "Has Waiters" bit if there still are other processes blocked on the
|
|
||||||
mutex.
|
|
||||||
|
|
||||||
The pi_lock of the previous owner is released, and the new pending owner's
|
|
||||||
pi_lock is taken. Remember that this is the trick to prevent the race
|
|
||||||
condition in rt_mutex_adjust_prio_chain from adding itself as a waiter
|
|
||||||
on the mutex.
|
|
||||||
|
|
||||||
We now clear the "pi_blocked_on" field of the new pending owner, and if
|
|
||||||
the mutex still has waiters pending, we add the new top waiter to the pi_list
|
|
||||||
of the pending owner.
|
|
||||||
|
|
||||||
Finally we unlock the pi_lock of the pending owner and wake it up.
|
Finally we unlock the pi_lock of the pending owner and wake it up.
|
||||||
|
|
||||||
|
@ -772,10 +546,14 @@ Credits
|
||||||
-------
|
-------
|
||||||
|
|
||||||
Author: Steven Rostedt <rostedt@goodmis.org>
|
Author: Steven Rostedt <rostedt@goodmis.org>
|
||||||
|
Updated: Alex Shi <alex.shi@linaro.org> - 7/6/2017
|
||||||
|
|
||||||
Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap
|
Original Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and
|
||||||
|
Randy Dunlap
|
||||||
|
Update (7/6/2017) Reviewers: Steven Rostedt and Sebastian Siewior
|
||||||
|
|
||||||
Updates
|
Updates
|
||||||
-------
|
-------
|
||||||
|
|
||||||
This document was originally written for 2.6.17-rc3-mm1
|
This document was originally written for 2.6.17-rc3-mm1
|
||||||
|
was updated on 4.12
|
||||||
|
|
|
@ -28,14 +28,13 @@ magic bullet for poorly designed applications, but it allows
|
||||||
well-designed applications to use userspace locks in critical parts of
|
well-designed applications to use userspace locks in critical parts of
|
||||||
an high priority thread, without losing determinism.
|
an high priority thread, without losing determinism.
|
||||||
|
|
||||||
The enqueueing of the waiters into the rtmutex waiter list is done in
|
The enqueueing of the waiters into the rtmutex waiter tree is done in
|
||||||
priority order. For same priorities FIFO order is chosen. For each
|
priority order. For same priorities FIFO order is chosen. For each
|
||||||
rtmutex, only the top priority waiter is enqueued into the owner's
|
rtmutex, only the top priority waiter is enqueued into the owner's
|
||||||
priority waiters list. This list too queues in priority order. Whenever
|
priority waiters tree. This tree too queues in priority order. Whenever
|
||||||
the top priority waiter of a task changes (for example it timed out or
|
the top priority waiter of a task changes (for example it timed out or
|
||||||
got a signal), the priority of the owner task is readjusted. [The
|
got a signal), the priority of the owner task is readjusted. The
|
||||||
priority enqueueing is handled by "plists", see include/linux/plist.h
|
priority enqueueing is handled by "pi_waiters".
|
||||||
for more details.]
|
|
||||||
|
|
||||||
RT-mutexes are optimized for fastpath operations and have no internal
|
RT-mutexes are optimized for fastpath operations and have no internal
|
||||||
locking overhead when locking an uncontended mutex or unlocking a mutex
|
locking overhead when locking an uncontended mutex or unlocking a mutex
|
||||||
|
@ -46,34 +45,29 @@ is used]
|
||||||
The state of the rt-mutex is tracked via the owner field of the rt-mutex
|
The state of the rt-mutex is tracked via the owner field of the rt-mutex
|
||||||
structure:
|
structure:
|
||||||
|
|
||||||
rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1
|
lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
|
||||||
are used to keep track of the "owner is pending" and "rtmutex has
|
keep track of the "lock has waiters" state.
|
||||||
waiters" state.
|
|
||||||
|
|
||||||
owner bit1 bit0
|
owner bit0
|
||||||
NULL 0 0 mutex is free (fast acquire possible)
|
NULL 0 lock is free (fast acquire possible)
|
||||||
NULL 0 1 invalid state
|
NULL 1 lock is free and has waiters and the top waiter
|
||||||
NULL 1 0 Transitional state*
|
is going to take the lock*
|
||||||
NULL 1 1 invalid state
|
taskpointer 0 lock is held (fast release possible)
|
||||||
taskpointer 0 0 mutex is held (fast release possible)
|
taskpointer 1 lock is held and has waiters**
|
||||||
taskpointer 0 1 task is pending owner
|
|
||||||
taskpointer 1 0 mutex is held and has waiters
|
|
||||||
taskpointer 1 1 task is pending owner and mutex has waiters
|
|
||||||
|
|
||||||
Pending-ownership handling is a performance optimization:
|
The fast atomic compare exchange based acquire and release is only
|
||||||
pending-ownership is assigned to the first (highest priority) waiter of
|
possible when bit 0 of lock->owner is 0.
|
||||||
the mutex, when the mutex is released. The thread is woken up and once
|
|
||||||
it starts executing it can acquire the mutex. Until the mutex is taken
|
|
||||||
by it (bit 0 is cleared) a competing higher priority thread can "steal"
|
|
||||||
the mutex which puts the woken up thread back on the waiters list.
|
|
||||||
|
|
||||||
The pending-ownership optimization is especially important for the
|
(*) It also can be a transitional state when grabbing the lock
|
||||||
uninterrupted workflow of high-prio tasks which repeatedly
|
with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
|
||||||
takes/releases locks that have lower-prio waiters. Without this
|
we need to set the bit0 before looking at the lock, and the owner may be
|
||||||
optimization the higher-prio thread would ping-pong to the lower-prio
|
NULL in this small time, hence this can be a transitional state.
|
||||||
task [because at unlock time we always assign a new owner].
|
|
||||||
|
|
||||||
(*) The "mutex has waiters" bit gets set to take the lock. If the lock
|
(**) There is a small time when bit 0 is set but there are no
|
||||||
doesn't already have an owner, this bit is quickly cleared if there are
|
waiters. This can happen when grabbing the lock in the slow path.
|
||||||
no waiters. So this is a transitional state to synchronize with looking
|
To prevent a cmpxchg of the owner releasing the lock, we need to
|
||||||
at the owner field of the mutex and the mutex owner releasing the lock.
|
set this bit before looking at the lock.
|
||||||
|
|
||||||
|
BTW, there is still technically a "Pending Owner", it's just not called
|
||||||
|
that anymore. The pending owner happens to be the top_waiter of a lock
|
||||||
|
that has no owner and has been woken up to grab the lock.
|
||||||
|
|
|
@ -7,7 +7,6 @@ Function Reference
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
:numbered:
|
|
||||||
|
|
||||||
cec-func-open
|
cec-func-open
|
||||||
cec-func-close
|
cec-func-close
|
||||||
|
|
|
@ -84,17 +84,17 @@ Device drivers API
|
||||||
==================
|
==================
|
||||||
|
|
||||||
The include/net/mac802154.h defines following functions:
|
The include/net/mac802154.h defines following functions:
|
||||||
- struct ieee802154_dev *ieee802154_alloc_device
|
- struct ieee802154_hw *
|
||||||
(size_t priv_size, struct ieee802154_ops *ops):
|
ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops):
|
||||||
allocation of IEEE 802.15.4 compatible device
|
allocation of IEEE 802.15.4 compatible hardware device
|
||||||
|
|
||||||
- void ieee802154_free_device(struct ieee802154_dev *dev):
|
- void ieee802154_free_hw(struct ieee802154_hw *hw):
|
||||||
freeing allocated device
|
freeing allocated hardware device
|
||||||
|
|
||||||
- int ieee802154_register_device(struct ieee802154_dev *dev):
|
- int ieee802154_register_hw(struct ieee802154_hw *hw):
|
||||||
register PHY in the system
|
register PHY which is the allocated hardware device, in the system
|
||||||
|
|
||||||
- void ieee802154_unregister_device(struct ieee802154_dev *dev):
|
- void ieee802154_unregister_hw(struct ieee802154_hw *hw):
|
||||||
freeing registered PHY
|
freeing registered PHY
|
||||||
|
|
||||||
Moreover IEEE 802.15.4 device operations structure should be filled.
|
Moreover IEEE 802.15.4 device operations structure should be filled.
|
||||||
|
|
|
@ -112,7 +112,7 @@ take nvmem_device as parameter.
|
||||||
5. Releasing a reference to the NVMEM
|
5. Releasing a reference to the NVMEM
|
||||||
=====================================
|
=====================================
|
||||||
|
|
||||||
When a consumers no longer needs the NVMEM, it has to release the reference
|
When a consumer no longer needs the NVMEM, it has to release the reference
|
||||||
to the NVMEM it has obtained using the APIs mentioned in the above section.
|
to the NVMEM it has obtained using the APIs mentioned in the above section.
|
||||||
The NVMEM framework provides 2 APIs to release a reference to the NVMEM.
|
The NVMEM framework provides 2 APIs to release a reference to the NVMEM.
|
||||||
|
|
||||||
|
|
|
@ -6,9 +6,6 @@ Applying Patches To The Linux Kernel
|
||||||
Original by:
|
Original by:
|
||||||
Jesper Juhl, August 2005
|
Jesper Juhl, August 2005
|
||||||
|
|
||||||
Last update:
|
|
||||||
2016-09-14
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
This document is obsolete. In most cases, rather than using ``patch``
|
This document is obsolete. In most cases, rather than using ``patch``
|
||||||
|
@ -344,7 +341,7 @@ possible.
|
||||||
|
|
||||||
This is a good branch to run for people who want to help out testing
|
This is a good branch to run for people who want to help out testing
|
||||||
development kernels but do not want to run some of the really experimental
|
development kernels but do not want to run some of the really experimental
|
||||||
stuff (such people should see the sections about -git and -mm kernels below).
|
stuff (such people should see the sections about -next and -mm kernels below).
|
||||||
|
|
||||||
The -rc patches are not incremental, they apply to a base 4.x kernel, just
|
The -rc patches are not incremental, they apply to a base 4.x kernel, just
|
||||||
like the 4.x.y patches described above. The kernel version before the -rcN
|
like the 4.x.y patches described above. The kernel version before the -rcN
|
||||||
|
@ -380,44 +377,6 @@ Here are 3 examples of how to apply these patches::
|
||||||
$ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir
|
$ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir
|
||||||
|
|
||||||
|
|
||||||
The -git kernels
|
|
||||||
================
|
|
||||||
|
|
||||||
These are daily snapshots of Linus' kernel tree (managed in a git
|
|
||||||
repository, hence the name).
|
|
||||||
|
|
||||||
These patches are usually released daily and represent the current state of
|
|
||||||
Linus's tree. They are more experimental than -rc kernels since they are
|
|
||||||
generated automatically without even a cursory glance to see if they are
|
|
||||||
sane.
|
|
||||||
|
|
||||||
-git patches are not incremental and apply either to a base 4.x kernel or
|
|
||||||
a base 4.x-rc kernel -- you can see which from their name.
|
|
||||||
A patch named 4.7-git1 applies to the 4.7 kernel source and a patch
|
|
||||||
named 4.8-rc3-git2 applies to the source of the 4.8-rc3 kernel.
|
|
||||||
|
|
||||||
Here are some examples of how to apply these patches::
|
|
||||||
|
|
||||||
# moving from 4.7 to 4.7-git1
|
|
||||||
|
|
||||||
$ cd ~/linux-4.7 # change to the kernel source dir
|
|
||||||
$ patch -p1 < ../patch-4.7-git1 # apply the 4.7-git1 patch
|
|
||||||
$ cd ..
|
|
||||||
$ mv linux-4.7 linux-4.7-git1 # rename the kernel source dir
|
|
||||||
|
|
||||||
# moving from 4.7-git1 to 4.8-rc2-git3
|
|
||||||
|
|
||||||
$ cd ~/linux-4.7-git1 # change to the kernel source dir
|
|
||||||
$ patch -p1 -R < ../patch-4.7-git1 # revert the 4.7-git1 patch
|
|
||||||
# we now have a 4.7 kernel
|
|
||||||
$ patch -p1 < ../patch-4.8-rc2 # apply the 4.8-rc2 patch
|
|
||||||
# the kernel is now 4.8-rc2
|
|
||||||
$ patch -p1 < ../patch-4.8-rc2-git3 # apply the 4.8-rc2-git3 patch
|
|
||||||
# the kernel is now 4.8-rc2-git3
|
|
||||||
$ cd ..
|
|
||||||
$ mv linux-4.7-git1 linux-4.8-rc2-git3 # rename source dir
|
|
||||||
|
|
||||||
|
|
||||||
The -mm patches and the linux-next tree
|
The -mm patches and the linux-next tree
|
||||||
=======================================
|
=======================================
|
||||||
|
|
||||||
|
|
|
@ -53,7 +53,7 @@ mcelog 0.6 mcelog --version
|
||||||
iptables 1.4.2 iptables -V
|
iptables 1.4.2 iptables -V
|
||||||
openssl & libcrypto 1.0.0 openssl version
|
openssl & libcrypto 1.0.0 openssl version
|
||||||
bc 1.06.95 bc --version
|
bc 1.06.95 bc --version
|
||||||
Sphinx\ [#f1]_ 1.2 sphinx-build --version
|
Sphinx\ [#f1]_ 1.3 sphinx-build --version
|
||||||
====================== =============== ========================================
|
====================== =============== ========================================
|
||||||
|
|
||||||
.. [#f1] Sphinx is needed only to build the Kernel documentation
|
.. [#f1] Sphinx is needed only to build the Kernel documentation
|
||||||
|
@ -309,18 +309,8 @@ Kernel documentation
|
||||||
Sphinx
|
Sphinx
|
||||||
------
|
------
|
||||||
|
|
||||||
The ReST markups currently used by the Documentation/ files are meant to be
|
Please see :ref:`sphinx_install` in ``Documentation/doc-guide/sphinx.rst``
|
||||||
built with ``Sphinx`` version 1.2 or upper. If you're desiring to build
|
for details about Sphinx requirements.
|
||||||
PDF outputs, it is recommended to use version 1.4.6.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Please notice that, for PDF and LaTeX output, you'll also need ``XeLaTeX``
|
|
||||||
version 3.14159265. Depending on the distribution, you may also need to
|
|
||||||
install a series of ``texlive`` packages that provide the minimal set of
|
|
||||||
functionalities required for ``XeLaTex`` to work. For PDF output you'll also
|
|
||||||
need ``convert(1)`` from ImageMagick (https://www.imagemagick.org).
|
|
||||||
|
|
||||||
|
|
||||||
Getting updated software
|
Getting updated software
|
||||||
========================
|
========================
|
||||||
|
|
|
@ -166,12 +166,12 @@ Trees
|
||||||
- The queues of patches, for both completed versions and in progress
|
- The queues of patches, for both completed versions and in progress
|
||||||
versions can be found at:
|
versions can be found at:
|
||||||
|
|
||||||
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git
|
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
|
||||||
|
|
||||||
- The finalized and tagged releases of all stable kernels can be found
|
- The finalized and tagged releases of all stable kernels can be found
|
||||||
in separate branches per version at:
|
in separate branches per version at:
|
||||||
|
|
||||||
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git
|
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
|
||||||
|
|
||||||
|
|
||||||
Review committee
|
Review committee
|
||||||
|
|
|
@ -413,7 +413,7 @@ e-mail discussions.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
11) Sign your work — the Developer's Certificate of Origin
|
11) Sign your work - the Developer's Certificate of Origin
|
||||||
----------------------------------------------------------
|
----------------------------------------------------------
|
||||||
|
|
||||||
To improve tracking of who did what, especially with patches that can
|
To improve tracking of who did what, especially with patches that can
|
||||||
|
|
|
@ -16,17 +16,7 @@ The key service can be configured on by enabling:
|
||||||
|
|
||||||
This document has the following sections:
|
This document has the following sections:
|
||||||
|
|
||||||
- Key overview
|
.. contents:: :local:
|
||||||
- Key service overview
|
|
||||||
- Key access permissions
|
|
||||||
- SELinux support
|
|
||||||
- New procfs files
|
|
||||||
- Userspace system call interface
|
|
||||||
- Kernel services
|
|
||||||
- Notes on accessing payload contents
|
|
||||||
- Defining a key type
|
|
||||||
- Request-key callback service
|
|
||||||
- Garbage collection
|
|
||||||
|
|
||||||
|
|
||||||
Key Overview
|
Key Overview
|
||||||
|
@ -443,7 +433,7 @@ The main syscalls are:
|
||||||
/sbin/request-key will be invoked in an attempt to obtain a key. The
|
/sbin/request-key will be invoked in an attempt to obtain a key. The
|
||||||
callout_info string will be passed as an argument to the program.
|
callout_info string will be passed as an argument to the program.
|
||||||
|
|
||||||
See also Documentation/security/keys-request-key.txt.
|
See also Documentation/security/keys/request-key.rst.
|
||||||
|
|
||||||
|
|
||||||
The keyctl syscall functions are:
|
The keyctl syscall functions are:
|
||||||
|
@ -973,7 +963,7 @@ payload contents" for more information.
|
||||||
If successful, the key will have been attached to the default keyring for
|
If successful, the key will have been attached to the default keyring for
|
||||||
implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
|
implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
|
||||||
|
|
||||||
See also Documentation/security/keys-request-key.txt.
|
See also Documentation/security/keys/request-key.rst.
|
||||||
|
|
||||||
|
|
||||||
* To search for a key, passing auxiliary data to the upcaller, call::
|
* To search for a key, passing auxiliary data to the upcaller, call::
|
||||||
|
|
|
@ -3,7 +3,7 @@ Key Request Service
|
||||||
===================
|
===================
|
||||||
|
|
||||||
The key request service is part of the key retention service (refer to
|
The key request service is part of the key retention service (refer to
|
||||||
Documentation/security/keys.txt). This document explains more fully how
|
Documentation/security/core.rst). This document explains more fully how
|
||||||
the requesting algorithm works.
|
the requesting algorithm works.
|
||||||
|
|
||||||
The process starts by either the kernel requesting a service by calling
|
The process starts by either the kernel requesting a service by calling
|
||||||
|
|
|
@ -172,4 +172,4 @@ Other uses for trusted and encrypted keys, such as for disk and file encryption
|
||||||
are anticipated. In particular the new format 'ecryptfs' has been defined in
|
are anticipated. In particular the new format 'ecryptfs' has been defined in
|
||||||
in order to use encrypted keys to mount an eCryptfs filesystem. More details
|
in order to use encrypted keys to mount an eCryptfs filesystem. More details
|
||||||
about the usage can be found in the file
|
about the usage can be found in the file
|
||||||
``Documentation/security/keys-ecryptfs.txt``.
|
``Documentation/security/keys/ecryptfs.rst``.
|
||||||
|
|
|
@ -4,6 +4,17 @@
|
||||||
*
|
*
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
/* Interim: Code-blocks with line nos - lines and line numbers don't line up.
|
||||||
|
* see: https://github.com/rtfd/sphinx_rtd_theme/issues/419
|
||||||
|
*/
|
||||||
|
|
||||||
|
div[class^="highlight"] pre {
|
||||||
|
line-height: normal;
|
||||||
|
}
|
||||||
|
.rst-content .highlight > pre {
|
||||||
|
line-height: normal;
|
||||||
|
}
|
||||||
|
|
||||||
@media screen {
|
@media screen {
|
||||||
|
|
||||||
/* content column
|
/* content column
|
||||||
|
@ -56,6 +67,12 @@
|
||||||
font-family: "Courier New", Courier, monospace
|
font-family: "Courier New", Courier, monospace
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/* fix bottom margin of lists items */
|
||||||
|
|
||||||
|
.rst-content .section ul li:last-child, .rst-content .section ul li p:last-child {
|
||||||
|
margin-bottom: 12px;
|
||||||
|
}
|
||||||
|
|
||||||
/* inline literal: drop the borderbox, padding and red color */
|
/* inline literal: drop the borderbox, padding and red color */
|
||||||
|
|
||||||
code, .rst-content tt, .rst-content code {
|
code, .rst-content tt, .rst-content code {
|
||||||
|
|
|
@ -27,6 +27,7 @@
|
||||||
# Please make sure this works on both python2 and python3.
|
# Please make sure this works on both python2 and python3.
|
||||||
#
|
#
|
||||||
|
|
||||||
|
import codecs
|
||||||
import os
|
import os
|
||||||
import subprocess
|
import subprocess
|
||||||
import sys
|
import sys
|
||||||
|
@ -88,13 +89,10 @@ class KernelDocDirective(Directive):
|
||||||
try:
|
try:
|
||||||
env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
|
env.app.verbose('calling kernel-doc \'%s\'' % (" ".join(cmd)))
|
||||||
|
|
||||||
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
|
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
|
||||||
out, err = p.communicate()
|
out, err = p.communicate()
|
||||||
|
|
||||||
# python2 needs conversion to unicode.
|
out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
|
||||||
# python3 with universal_newlines=True returns strings.
|
|
||||||
if sys.version_info.major < 3:
|
|
||||||
out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
|
|
||||||
|
|
||||||
if p.returncode != 0:
|
if p.returncode != 0:
|
||||||
sys.stderr.write(err)
|
sys.stderr.write(err)
|
||||||
|
|
|
@ -0,0 +1,3 @@
|
||||||
|
docutils==0.12
|
||||||
|
Sphinx==1.4.9
|
||||||
|
sphinx_rtd_theme
|
|
@ -149,9 +149,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
|
||||||
核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册
|
核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册
|
||||||
页等不同格式的文档:
|
页等不同格式的文档:
|
||||||
make pdfdocs
|
make pdfdocs
|
||||||
make psdocs
|
|
||||||
make htmldocs
|
make htmldocs
|
||||||
make mandocs
|
|
||||||
|
|
||||||
|
|
||||||
如何成为内核开发者
|
如何成为内核开发者
|
||||||
|
|
23
MAINTAINERS
23
MAINTAINERS
|
@ -4359,6 +4359,12 @@ S: Maintained
|
||||||
F: drivers/gpu/drm/qxl/
|
F: drivers/gpu/drm/qxl/
|
||||||
F: include/uapi/drm/qxl_drm.h
|
F: include/uapi/drm/qxl_drm.h
|
||||||
|
|
||||||
|
DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
|
||||||
|
M: Noralf Trønnes <noralf@tronnes.org>
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/gpu/drm/tinydrm/repaper.c
|
||||||
|
F: Documentation/devicetree/bindings/display/repaper.txt
|
||||||
|
|
||||||
DRM DRIVER FOR RAGE 128 VIDEO CARDS
|
DRM DRIVER FOR RAGE 128 VIDEO CARDS
|
||||||
S: Orphan / Obsolete
|
S: Orphan / Obsolete
|
||||||
F: drivers/gpu/drm/r128/
|
F: drivers/gpu/drm/r128/
|
||||||
|
@ -4374,6 +4380,12 @@ S: Orphan / Obsolete
|
||||||
F: drivers/gpu/drm/sis/
|
F: drivers/gpu/drm/sis/
|
||||||
F: include/uapi/drm/sis_drm.h
|
F: include/uapi/drm/sis_drm.h
|
||||||
|
|
||||||
|
DRM DRIVER FOR SITRONIX ST7586 PANELS
|
||||||
|
M: David Lechner <david@lechnology.com>
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/gpu/drm/tinydrm/st7586.c
|
||||||
|
F: Documentation/devicetree/bindings/display/st7586.txt
|
||||||
|
|
||||||
DRM DRIVER FOR TDFX VIDEO CARDS
|
DRM DRIVER FOR TDFX VIDEO CARDS
|
||||||
S: Orphan / Obsolete
|
S: Orphan / Obsolete
|
||||||
F: drivers/gpu/drm/tdfx/
|
F: drivers/gpu/drm/tdfx/
|
||||||
|
@ -4622,6 +4634,14 @@ F: drivers/gpu/drm/panel/
|
||||||
F: include/drm/drm_panel.h
|
F: include/drm/drm_panel.h
|
||||||
F: Documentation/devicetree/bindings/display/panel/
|
F: Documentation/devicetree/bindings/display/panel/
|
||||||
|
|
||||||
|
DRM TINYDRM DRIVERS
|
||||||
|
M: Noralf Trønnes <noralf@tronnes.org>
|
||||||
|
W: https://github.com/notro/tinydrm/wiki/Development
|
||||||
|
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/gpu/drm/tinydrm/
|
||||||
|
F: include/drm/tinydrm/
|
||||||
|
|
||||||
DSBR100 USB FM RADIO DRIVER
|
DSBR100 USB FM RADIO DRIVER
|
||||||
M: Alexey Klimov <klimov.linux@gmail.com>
|
M: Alexey Klimov <klimov.linux@gmail.com>
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
|
@ -6744,8 +6764,9 @@ S: Supported
|
||||||
F: drivers/scsi/isci/
|
F: drivers/scsi/isci/
|
||||||
|
|
||||||
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
|
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
|
||||||
M: Daniel Vetter <daniel.vetter@intel.com>
|
|
||||||
M: Jani Nikula <jani.nikula@linux.intel.com>
|
M: Jani Nikula <jani.nikula@linux.intel.com>
|
||||||
|
M: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
||||||
|
M: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
||||||
L: intel-gfx@lists.freedesktop.org
|
L: intel-gfx@lists.freedesktop.org
|
||||||
W: https://01.org/linuxgraphics/
|
W: https://01.org/linuxgraphics/
|
||||||
B: https://01.org/linuxgraphics/documentation/how-report-bugs
|
B: https://01.org/linuxgraphics/documentation/how-report-bugs
|
||||||
|
|
4
Makefile
4
Makefile
|
@ -1,7 +1,7 @@
|
||||||
VERSION = 4
|
VERSION = 4
|
||||||
PATCHLEVEL = 13
|
PATCHLEVEL = 13
|
||||||
SUBLEVEL = 0
|
SUBLEVEL = 0
|
||||||
EXTRAVERSION = -rc6
|
EXTRAVERSION =
|
||||||
NAME = Fearless Coyote
|
NAME = Fearless Coyote
|
||||||
|
|
||||||
# *DOCUMENTATION*
|
# *DOCUMENTATION*
|
||||||
|
@ -1468,7 +1468,7 @@ $(help-board-dirs): help-%:
|
||||||
|
|
||||||
# Documentation targets
|
# Documentation targets
|
||||||
# ---------------------------------------------------------------------------
|
# ---------------------------------------------------------------------------
|
||||||
DOC_TARGETS := xmldocs sgmldocs psdocs latexdocs pdfdocs htmldocs mandocs installmandocs epubdocs cleandocs linkcheckdocs
|
DOC_TARGETS := xmldocs latexdocs pdfdocs htmldocs epubdocs cleandocs linkcheckdocs
|
||||||
PHONY += $(DOC_TARGETS)
|
PHONY += $(DOC_TARGETS)
|
||||||
$(DOC_TARGETS): scripts_basic FORCE
|
$(DOC_TARGETS): scripts_basic FORCE
|
||||||
$(Q)$(MAKE) $(build)=Documentation $@
|
$(Q)$(MAKE) $(build)=Documentation $@
|
||||||
|
|
|
@ -299,6 +299,7 @@ static inline void __iomem * ioremap_nocache(unsigned long offset,
|
||||||
return ioremap(offset, size);
|
return ioremap(offset, size);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
#define ioremap_wc ioremap_nocache
|
||||||
#define ioremap_uc ioremap_nocache
|
#define ioremap_uc ioremap_nocache
|
||||||
|
|
||||||
static inline void iounmap(volatile void __iomem *addr)
|
static inline void iounmap(volatile void __iomem *addr)
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
#ifndef _ALPHA_TYPES_H
|
#ifndef _ALPHA_TYPES_H
|
||||||
#define _ALPHA_TYPES_H
|
#define _ALPHA_TYPES_H
|
||||||
|
|
||||||
#include <asm-generic/int-ll64.h>
|
#include <uapi/asm/types.h>
|
||||||
|
|
||||||
#endif /* _ALPHA_TYPES_H */
|
#endif /* _ALPHA_TYPES_H */
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
|
|
||||||
#include <uapi/asm/unistd.h>
|
#include <uapi/asm/unistd.h>
|
||||||
|
|
||||||
#define NR_SYSCALLS 514
|
#define NR_SYSCALLS 523
|
||||||
|
|
||||||
#define __ARCH_WANT_OLD_READDIR
|
#define __ARCH_WANT_OLD_READDIR
|
||||||
#define __ARCH_WANT_STAT64
|
#define __ARCH_WANT_STAT64
|
||||||
|
|
|
@ -9,8 +9,18 @@
|
||||||
* need to be careful to avoid a name clashes.
|
* need to be careful to avoid a name clashes.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#ifndef __KERNEL__
|
/*
|
||||||
|
* This is here because we used to use l64 for alpha
|
||||||
|
* and we don't want to impact user mode with our change to ll64
|
||||||
|
* in the kernel.
|
||||||
|
*
|
||||||
|
* However, some user programs are fine with this. They can
|
||||||
|
* flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
|
||||||
|
*/
|
||||||
|
#if !defined(__SANE_USERSPACE_TYPES__) && !defined(__KERNEL__)
|
||||||
#include <asm-generic/int-l64.h>
|
#include <asm-generic/int-l64.h>
|
||||||
|
#else
|
||||||
|
#include <asm-generic/int-ll64.h>
|
||||||
#endif
|
#endif
|
||||||
|
|
||||||
#endif /* _UAPI_ALPHA_TYPES_H */
|
#endif /* _UAPI_ALPHA_TYPES_H */
|
||||||
|
|
|
@ -475,5 +475,19 @@
|
||||||
#define __NR_getrandom 511
|
#define __NR_getrandom 511
|
||||||
#define __NR_memfd_create 512
|
#define __NR_memfd_create 512
|
||||||
#define __NR_execveat 513
|
#define __NR_execveat 513
|
||||||
|
#define __NR_seccomp 514
|
||||||
|
#define __NR_bpf 515
|
||||||
|
#define __NR_userfaultfd 516
|
||||||
|
#define __NR_membarrier 517
|
||||||
|
#define __NR_mlock2 518
|
||||||
|
#define __NR_copy_file_range 519
|
||||||
|
#define __NR_preadv2 520
|
||||||
|
#define __NR_pwritev2 521
|
||||||
|
#define __NR_statx 522
|
||||||
|
|
||||||
|
/* Alpha doesn't have protection keys. */
|
||||||
|
#define __IGNORE_pkey_mprotect
|
||||||
|
#define __IGNORE_pkey_alloc
|
||||||
|
#define __IGNORE_pkey_free
|
||||||
|
|
||||||
#endif /* _UAPI_ALPHA_UNISTD_H */
|
#endif /* _UAPI_ALPHA_UNISTD_H */
|
||||||
|
|
|
@ -351,7 +351,7 @@ marvel_init_io7(struct io7 *io7)
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
void
|
void __init
|
||||||
marvel_io7_present(gct6_node *node)
|
marvel_io7_present(gct6_node *node)
|
||||||
{
|
{
|
||||||
int pe;
|
int pe;
|
||||||
|
@ -369,6 +369,7 @@ marvel_io7_present(gct6_node *node)
|
||||||
static void __init
|
static void __init
|
||||||
marvel_find_console_vga_hose(void)
|
marvel_find_console_vga_hose(void)
|
||||||
{
|
{
|
||||||
|
#ifdef CONFIG_VGA_HOSE
|
||||||
u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset);
|
u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset);
|
||||||
|
|
||||||
if (pu64[7] == 3) { /* TERM_TYPE == graphics */
|
if (pu64[7] == 3) { /* TERM_TYPE == graphics */
|
||||||
|
@ -402,9 +403,10 @@ marvel_find_console_vga_hose(void)
|
||||||
pci_vga_hose = hose;
|
pci_vga_hose = hose;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
#endif
|
||||||
}
|
}
|
||||||
|
|
||||||
gct6_search_struct gct_wanted_node_list[] = {
|
gct6_search_struct gct_wanted_node_list[] __initdata = {
|
||||||
{ GCT_TYPE_HOSE, GCT_SUBTYPE_IO_PORT_MODULE, marvel_io7_present },
|
{ GCT_TYPE_HOSE, GCT_SUBTYPE_IO_PORT_MODULE, marvel_io7_present },
|
||||||
{ 0, 0, NULL }
|
{ 0, 0, NULL }
|
||||||
};
|
};
|
||||||
|
|
|
@ -461,6 +461,7 @@ titan_ioremap(unsigned long addr, unsigned long size)
|
||||||
unsigned long *ptes;
|
unsigned long *ptes;
|
||||||
unsigned long pfn;
|
unsigned long pfn;
|
||||||
|
|
||||||
|
#ifdef CONFIG_VGA_HOSE
|
||||||
/*
|
/*
|
||||||
* Adjust the address and hose, if necessary.
|
* Adjust the address and hose, if necessary.
|
||||||
*/
|
*/
|
||||||
|
@ -468,6 +469,7 @@ titan_ioremap(unsigned long addr, unsigned long size)
|
||||||
h = pci_vga_hose->index;
|
h = pci_vga_hose->index;
|
||||||
addr += pci_vga_hose->mem_space->start;
|
addr += pci_vga_hose->mem_space->start;
|
||||||
}
|
}
|
||||||
|
#endif
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* Find the hose.
|
* Find the hose.
|
||||||
|
|
|
@ -181,6 +181,9 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
|
||||||
switch (r_type) {
|
switch (r_type) {
|
||||||
case R_ALPHA_NONE:
|
case R_ALPHA_NONE:
|
||||||
break;
|
break;
|
||||||
|
case R_ALPHA_REFLONG:
|
||||||
|
*(u32 *)location = value;
|
||||||
|
break;
|
||||||
case R_ALPHA_REFQUAD:
|
case R_ALPHA_REFQUAD:
|
||||||
/* BUG() can produce misaligned relocations. */
|
/* BUG() can produce misaligned relocations. */
|
||||||
((u32 *)location)[0] = value;
|
((u32 *)location)[0] = value;
|
||||||
|
|
|
@ -115,7 +115,7 @@ wait_boot_cpu_to_stop(int cpuid)
|
||||||
/*
|
/*
|
||||||
* Where secondaries begin a life of C.
|
* Where secondaries begin a life of C.
|
||||||
*/
|
*/
|
||||||
void
|
void __init
|
||||||
smp_callin(void)
|
smp_callin(void)
|
||||||
{
|
{
|
||||||
int cpuid = hard_smp_processor_id();
|
int cpuid = hard_smp_processor_id();
|
||||||
|
|
|
@ -532,6 +532,15 @@ sys_call_table:
|
||||||
.quad sys_getrandom
|
.quad sys_getrandom
|
||||||
.quad sys_memfd_create
|
.quad sys_memfd_create
|
||||||
.quad sys_execveat
|
.quad sys_execveat
|
||||||
|
.quad sys_seccomp
|
||||||
|
.quad sys_bpf /* 515 */
|
||||||
|
.quad sys_userfaultfd
|
||||||
|
.quad sys_membarrier
|
||||||
|
.quad sys_mlock2
|
||||||
|
.quad sys_copy_file_range
|
||||||
|
.quad sys_preadv2 /* 520 */
|
||||||
|
.quad sys_pwritev2
|
||||||
|
.quad sys_statx
|
||||||
|
|
||||||
.size sys_call_table, . - sys_call_table
|
.size sys_call_table, . - sys_call_table
|
||||||
.type sys_call_table, @object
|
.type sys_call_table, @object
|
||||||
|
|
|
@ -20,12 +20,8 @@ lib-y = __divqu.o __remqu.o __divlu.o __remlu.o \
|
||||||
checksum.o \
|
checksum.o \
|
||||||
csum_partial_copy.o \
|
csum_partial_copy.o \
|
||||||
$(ev67-y)strlen.o \
|
$(ev67-y)strlen.o \
|
||||||
$(ev67-y)strcat.o \
|
stycpy.o \
|
||||||
strcpy.o \
|
styncpy.o \
|
||||||
$(ev67-y)strncat.o \
|
|
||||||
strncpy.o \
|
|
||||||
$(ev6-y)stxcpy.o \
|
|
||||||
$(ev6-y)stxncpy.o \
|
|
||||||
$(ev67-y)strchr.o \
|
$(ev67-y)strchr.o \
|
||||||
$(ev67-y)strrchr.o \
|
$(ev67-y)strrchr.o \
|
||||||
$(ev6-y)memchr.o \
|
$(ev6-y)memchr.o \
|
||||||
|
@ -49,3 +45,17 @@ AFLAGS___remlu.o = -DREM -DINTSIZE
|
||||||
$(addprefix $(obj)/,__divqu.o __remqu.o __divlu.o __remlu.o): \
|
$(addprefix $(obj)/,__divqu.o __remqu.o __divlu.o __remlu.o): \
|
||||||
$(src)/$(ev6-y)divide.S FORCE
|
$(src)/$(ev6-y)divide.S FORCE
|
||||||
$(call if_changed_rule,as_o_S)
|
$(call if_changed_rule,as_o_S)
|
||||||
|
|
||||||
|
# There are direct branches between {str*cpy,str*cat} and stx*cpy.
|
||||||
|
# Ensure the branches are within range by merging these objects.
|
||||||
|
|
||||||
|
LDFLAGS_stycpy.o := -r
|
||||||
|
LDFLAGS_styncpy.o := -r
|
||||||
|
|
||||||
|
$(obj)/stycpy.o: $(obj)/strcpy.o $(obj)/$(ev67-y)strcat.o \
|
||||||
|
$(obj)/$(ev6-y)stxcpy.o FORCE
|
||||||
|
$(call if_changed,ld)
|
||||||
|
|
||||||
|
$(obj)/styncpy.o: $(obj)/strncpy.o $(obj)/$(ev67-y)strncat.o \
|
||||||
|
$(obj)/$(ev6-y)stxncpy.o FORCE
|
||||||
|
$(call if_changed,ld)
|
||||||
|
|
|
@ -34,7 +34,7 @@
|
||||||
.ent __copy_user
|
.ent __copy_user
|
||||||
__copy_user:
|
__copy_user:
|
||||||
.prologue 0
|
.prologue 0
|
||||||
and $18,$18,$0
|
mov $18,$0
|
||||||
and $16,7,$3
|
and $16,7,$3
|
||||||
beq $0,$35
|
beq $0,$35
|
||||||
beq $3,$36
|
beq $3,$36
|
||||||
|
|
|
@ -45,9 +45,10 @@
|
||||||
# Pipeline info: Slotting & Comments
|
# Pipeline info: Slotting & Comments
|
||||||
__copy_user:
|
__copy_user:
|
||||||
.prologue 0
|
.prologue 0
|
||||||
andq $18, $18, $0
|
mov $18, $0 # .. .. .. E
|
||||||
subq $18, 32, $1 # .. E .. .. : Is this going to be a small copy?
|
subq $18, 32, $1 # .. .. E. .. : Is this going to be a small copy?
|
||||||
beq $0, $zerolength # U .. .. .. : U L U L
|
nop # .. E .. ..
|
||||||
|
beq $18, $zerolength # U .. .. .. : U L U L
|
||||||
|
|
||||||
and $16,7,$3 # .. .. .. E : is leading dest misalignment
|
and $16,7,$3 # .. .. .. E : is leading dest misalignment
|
||||||
ble $1, $onebyteloop # .. .. U .. : 1st branch : small amount of data
|
ble $1, $onebyteloop # .. .. U .. : 1st branch : small amount of data
|
||||||
|
|
|
@ -75,12 +75,19 @@ void arc_init_IRQ(void)
|
||||||
* Set a default priority for all available interrupts to prevent
|
* Set a default priority for all available interrupts to prevent
|
||||||
* switching of register banks if Fast IRQ and multiple register banks
|
* switching of register banks if Fast IRQ and multiple register banks
|
||||||
* are supported by CPU.
|
* are supported by CPU.
|
||||||
* Also disable all IRQ lines so faulty external hardware won't
|
* Also disable private-per-core IRQ lines so faulty external HW won't
|
||||||
* trigger interrupt that kernel is not ready to handle.
|
* trigger interrupt that kernel is not ready to handle.
|
||||||
*/
|
*/
|
||||||
for (i = NR_EXCEPTIONS; i < irq_bcr.irqs + NR_EXCEPTIONS; i++) {
|
for (i = NR_EXCEPTIONS; i < irq_bcr.irqs + NR_EXCEPTIONS; i++) {
|
||||||
write_aux_reg(AUX_IRQ_SELECT, i);
|
write_aux_reg(AUX_IRQ_SELECT, i);
|
||||||
write_aux_reg(AUX_IRQ_PRIORITY, ARCV2_IRQ_DEF_PRIO);
|
write_aux_reg(AUX_IRQ_PRIORITY, ARCV2_IRQ_DEF_PRIO);
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Only mask cpu private IRQs here.
|
||||||
|
* "common" interrupts are masked at IDU, otherwise it would
|
||||||
|
* need to be unmasked at each cpu, with IPIs
|
||||||
|
*/
|
||||||
|
if (i < FIRST_EXT_IRQ)
|
||||||
write_aux_reg(AUX_IRQ_ENABLE, 0);
|
write_aux_reg(AUX_IRQ_ENABLE, 0);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
@ -27,7 +27,7 @@
|
||||||
*/
|
*/
|
||||||
void arc_init_IRQ(void)
|
void arc_init_IRQ(void)
|
||||||
{
|
{
|
||||||
int level_mask = 0, i;
|
unsigned int level_mask = 0, i;
|
||||||
|
|
||||||
/* Is timer high priority Interrupt (Level2 in ARCompact jargon) */
|
/* Is timer high priority Interrupt (Level2 in ARCompact jargon) */
|
||||||
level_mask |= IS_ENABLED(CONFIG_ARC_COMPACT_IRQ_LEVELS) << TIMER0_IRQ;
|
level_mask |= IS_ENABLED(CONFIG_ARC_COMPACT_IRQ_LEVELS) << TIMER0_IRQ;
|
||||||
|
|
|
@ -56,8 +56,6 @@
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
|
|
||||||
ethernet0 = &emac;
|
|
||||||
ethernet1 = &xr819;
|
ethernet1 = &xr819;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -104,13 +102,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
phy-handle = <&int_mii_phy>;
|
|
||||||
phy-mode = "mii";
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins_a>;
|
pinctrl-0 = <&mmc0_pins_a>;
|
||||||
|
|
|
@ -52,7 +52,6 @@
|
||||||
compatible = "sinovoip,bpi-m2-plus", "allwinner,sun8i-h3";
|
compatible = "sinovoip,bpi-m2-plus", "allwinner,sun8i-h3";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
serial1 = &uart1;
|
serial1 = &uart1;
|
||||||
};
|
};
|
||||||
|
@ -115,30 +114,12 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&emac_rgmii_pins>;
|
|
||||||
phy-supply = <®_gmac_3v3>;
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&ir {
|
&ir {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&ir_pins_a>;
|
pinctrl-0 = <&ir_pins_a>;
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <0>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||||
|
|
|
@ -46,10 +46,3 @@
|
||||||
model = "FriendlyARM NanoPi NEO";
|
model = "FriendlyARM NanoPi NEO";
|
||||||
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
|
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
phy-handle = <&int_mii_phy>;
|
|
||||||
phy-mode = "mii";
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
|
@ -54,7 +54,6 @@
|
||||||
aliases {
|
aliases {
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
|
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
|
||||||
ethernet0 = &emac;
|
|
||||||
ethernet1 = &rtl8189;
|
ethernet1 = &rtl8189;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -118,13 +117,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
phy-handle = <&int_mii_phy>;
|
|
||||||
phy-mode = "mii";
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&ir {
|
&ir {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&ir_pins_a>;
|
pinctrl-0 = <&ir_pins_a>;
|
||||||
|
|
|
@ -52,7 +52,6 @@
|
||||||
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
|
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -98,13 +97,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
phy-handle = <&int_mii_phy>;
|
|
||||||
phy-mode = "mii";
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||||
|
|
|
@ -53,11 +53,6 @@
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
/* LEDs changed to active high on the plus */
|
|
||||||
/delete-property/ allwinner,leds-active-low;
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc1 {
|
&mmc1 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc1_pins_a>;
|
pinctrl-0 = <&mmc1_pins_a>;
|
||||||
|
|
|
@ -52,7 +52,6 @@
|
||||||
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
|
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -114,13 +113,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
phy-handle = <&int_mii_phy>;
|
|
||||||
phy-mode = "mii";
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&ir {
|
&ir {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&ir_pins_a>;
|
pinctrl-0 = <&ir_pins_a>;
|
||||||
|
|
|
@ -47,10 +47,6 @@
|
||||||
model = "Xunlong Orange Pi Plus / Plus 2";
|
model = "Xunlong Orange Pi Plus / Plus 2";
|
||||||
compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
|
compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
|
||||||
|
|
||||||
aliases {
|
|
||||||
ethernet0 = &emac;
|
|
||||||
};
|
|
||||||
|
|
||||||
reg_gmac_3v3: gmac-3v3 {
|
reg_gmac_3v3: gmac-3v3 {
|
||||||
compatible = "regulator-fixed";
|
compatible = "regulator-fixed";
|
||||||
regulator-name = "gmac-3v3";
|
regulator-name = "gmac-3v3";
|
||||||
|
@ -78,24 +74,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&emac_rgmii_pins>;
|
|
||||||
phy-supply = <®_gmac_3v3>;
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
|
|
||||||
allwinner,leds-active-low;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <0>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc2 {
|
&mmc2 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc2_8bit_pins>;
|
pinctrl-0 = <&mmc2_8bit_pins>;
|
||||||
|
|
|
@ -61,19 +61,3 @@
|
||||||
gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
|
gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&emac_rgmii_pins>;
|
|
||||||
phy-supply = <®_gmac_3v3>;
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
|
@ -391,32 +391,6 @@
|
||||||
clocks = <&osc24M>;
|
clocks = <&osc24M>;
|
||||||
};
|
};
|
||||||
|
|
||||||
emac: ethernet@1c30000 {
|
|
||||||
compatible = "allwinner,sun8i-h3-emac";
|
|
||||||
syscon = <&syscon>;
|
|
||||||
reg = <0x01c30000 0x10000>;
|
|
||||||
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
|
|
||||||
interrupt-names = "macirq";
|
|
||||||
resets = <&ccu RST_BUS_EMAC>;
|
|
||||||
reset-names = "stmmaceth";
|
|
||||||
clocks = <&ccu CLK_BUS_EMAC>;
|
|
||||||
clock-names = "stmmaceth";
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
status = "disabled";
|
|
||||||
|
|
||||||
mdio: mdio {
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
int_mii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
clocks = <&ccu CLK_BUS_EPHY>;
|
|
||||||
resets = <&ccu RST_BUS_EPHY>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
spi0: spi@01c68000 {
|
spi0: spi@01c68000 {
|
||||||
compatible = "allwinner,sun8i-h3-spi";
|
compatible = "allwinner,sun8i-h3-spi";
|
||||||
reg = <0x01c68000 0x1000>;
|
reg = <0x01c68000 0x1000>;
|
||||||
|
|
|
@ -225,12 +225,6 @@ int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
|
||||||
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
|
int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
|
||||||
int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
|
int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
|
||||||
|
|
||||||
/* We do not have shadow page tables, hence the empty hooks */
|
|
||||||
static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
|
|
||||||
unsigned long address)
|
|
||||||
{
|
|
||||||
}
|
|
||||||
|
|
||||||
struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
|
struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
|
||||||
struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
|
struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
|
||||||
void kvm_arm_halt_guest(struct kvm *kvm);
|
void kvm_arm_halt_guest(struct kvm *kvm);
|
||||||
|
|
|
@ -8,7 +8,7 @@ ccflags-y := -I$(srctree)/$(src)/include \
|
||||||
# Common support
|
# Common support
|
||||||
obj-y := id.o io.o control.o devices.o fb.o timer.o pm.o \
|
obj-y := id.o io.o control.o devices.o fb.o timer.o pm.o \
|
||||||
common.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
|
common.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
|
||||||
omap_device.o omap-headsmp.o sram.o drm.o
|
omap_device.o omap-headsmp.o sram.o
|
||||||
|
|
||||||
hwmod-common = omap_hwmod.o omap_hwmod_reset.o \
|
hwmod-common = omap_hwmod.o omap_hwmod_reset.o \
|
||||||
omap_hwmod_common_data.o
|
omap_hwmod_common_data.o
|
||||||
|
|
|
@ -33,6 +33,7 @@ static void __init __maybe_unused omap_generic_init(void)
|
||||||
pdata_quirks_init(omap_dt_match_table);
|
pdata_quirks_init(omap_dt_match_table);
|
||||||
|
|
||||||
omapdss_init_of();
|
omapdss_init_of();
|
||||||
|
omap_soc_device_init();
|
||||||
}
|
}
|
||||||
|
|
||||||
#ifdef CONFIG_SOC_OMAP2420
|
#ifdef CONFIG_SOC_OMAP2420
|
||||||
|
|
|
@ -66,6 +66,7 @@
|
||||||
*/
|
*/
|
||||||
#define FRAMEDONE_IRQ_TIMEOUT 100
|
#define FRAMEDONE_IRQ_TIMEOUT 100
|
||||||
|
|
||||||
|
#if defined(CONFIG_FB_OMAP2)
|
||||||
static struct platform_device omap_display_device = {
|
static struct platform_device omap_display_device = {
|
||||||
.name = "omapdss",
|
.name = "omapdss",
|
||||||
.id = -1,
|
.id = -1,
|
||||||
|
@ -163,6 +164,65 @@ static enum omapdss_version __init omap_display_get_version(void)
|
||||||
return OMAPDSS_VER_UNKNOWN;
|
return OMAPDSS_VER_UNKNOWN;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
static int __init omapdss_init_fbdev(void)
|
||||||
|
{
|
||||||
|
static struct omap_dss_board_info board_data = {
|
||||||
|
.dsi_enable_pads = omap_dsi_enable_pads,
|
||||||
|
.dsi_disable_pads = omap_dsi_disable_pads,
|
||||||
|
.set_min_bus_tput = omap_dss_set_min_bus_tput,
|
||||||
|
};
|
||||||
|
struct device_node *node;
|
||||||
|
int r;
|
||||||
|
|
||||||
|
board_data.version = omap_display_get_version();
|
||||||
|
if (board_data.version == OMAPDSS_VER_UNKNOWN) {
|
||||||
|
pr_err("DSS not supported on this SoC\n");
|
||||||
|
return -ENODEV;
|
||||||
|
}
|
||||||
|
|
||||||
|
omap_display_device.dev.platform_data = &board_data;
|
||||||
|
|
||||||
|
r = platform_device_register(&omap_display_device);
|
||||||
|
if (r < 0) {
|
||||||
|
pr_err("Unable to register omapdss device\n");
|
||||||
|
return r;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* create vrfb device */
|
||||||
|
r = omap_init_vrfb();
|
||||||
|
if (r < 0) {
|
||||||
|
pr_err("Unable to register omapvrfb device\n");
|
||||||
|
return r;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* create FB device */
|
||||||
|
r = omap_init_fb();
|
||||||
|
if (r < 0) {
|
||||||
|
pr_err("Unable to register omapfb device\n");
|
||||||
|
return r;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* create V4L2 display device */
|
||||||
|
r = omap_init_vout();
|
||||||
|
if (r < 0) {
|
||||||
|
pr_err("Unable to register omap_vout device\n");
|
||||||
|
return r;
|
||||||
|
}
|
||||||
|
|
||||||
|
/* add DSI info for omap4 */
|
||||||
|
node = of_find_node_by_name(NULL, "omap4_padconf_global");
|
||||||
|
if (node)
|
||||||
|
omap4_dsi_mux_syscon = syscon_node_to_regmap(node);
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
#else
|
||||||
|
static inline int omapdss_init_fbdev(void)
|
||||||
|
{
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
#endif /* CONFIG_FB_OMAP2 */
|
||||||
|
|
||||||
static void dispc_disable_outputs(void)
|
static void dispc_disable_outputs(void)
|
||||||
{
|
{
|
||||||
u32 v, irq_mask = 0;
|
u32 v, irq_mask = 0;
|
||||||
|
@ -335,16 +395,9 @@ static struct device_node * __init omapdss_find_dss_of_node(void)
|
||||||
int __init omapdss_init_of(void)
|
int __init omapdss_init_of(void)
|
||||||
{
|
{
|
||||||
int r;
|
int r;
|
||||||
enum omapdss_version ver;
|
|
||||||
struct device_node *node;
|
struct device_node *node;
|
||||||
struct platform_device *pdev;
|
struct platform_device *pdev;
|
||||||
|
|
||||||
static struct omap_dss_board_info board_data = {
|
|
||||||
.dsi_enable_pads = omap_dsi_enable_pads,
|
|
||||||
.dsi_disable_pads = omap_dsi_disable_pads,
|
|
||||||
.set_min_bus_tput = omap_dss_set_min_bus_tput,
|
|
||||||
};
|
|
||||||
|
|
||||||
/* only create dss helper devices if dss is enabled in the .dts */
|
/* only create dss helper devices if dss is enabled in the .dts */
|
||||||
|
|
||||||
node = omapdss_find_dss_of_node();
|
node = omapdss_find_dss_of_node();
|
||||||
|
@ -354,13 +407,6 @@ int __init omapdss_init_of(void)
|
||||||
if (!of_device_is_available(node))
|
if (!of_device_is_available(node))
|
||||||
return 0;
|
return 0;
|
||||||
|
|
||||||
ver = omap_display_get_version();
|
|
||||||
|
|
||||||
if (ver == OMAPDSS_VER_UNKNOWN) {
|
|
||||||
pr_err("DSS not supported on this SoC\n");
|
|
||||||
return -ENODEV;
|
|
||||||
}
|
|
||||||
|
|
||||||
pdev = of_find_device_by_node(node);
|
pdev = of_find_device_by_node(node);
|
||||||
|
|
||||||
if (!pdev) {
|
if (!pdev) {
|
||||||
|
@ -374,48 +420,5 @@ int __init omapdss_init_of(void)
|
||||||
return r;
|
return r;
|
||||||
}
|
}
|
||||||
|
|
||||||
board_data.version = ver;
|
return omapdss_init_fbdev();
|
||||||
|
|
||||||
omap_display_device.dev.platform_data = &board_data;
|
|
||||||
|
|
||||||
r = platform_device_register(&omap_display_device);
|
|
||||||
if (r < 0) {
|
|
||||||
pr_err("Unable to register omapdss device\n");
|
|
||||||
return r;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* create DRM device */
|
|
||||||
r = omap_init_drm();
|
|
||||||
if (r < 0) {
|
|
||||||
pr_err("Unable to register omapdrm device\n");
|
|
||||||
return r;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* create vrfb device */
|
|
||||||
r = omap_init_vrfb();
|
|
||||||
if (r < 0) {
|
|
||||||
pr_err("Unable to register omapvrfb device\n");
|
|
||||||
return r;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* create FB device */
|
|
||||||
r = omap_init_fb();
|
|
||||||
if (r < 0) {
|
|
||||||
pr_err("Unable to register omapfb device\n");
|
|
||||||
return r;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* create V4L2 display device */
|
|
||||||
r = omap_init_vout();
|
|
||||||
if (r < 0) {
|
|
||||||
pr_err("Unable to register omap_vout device\n");
|
|
||||||
return r;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* add DSI info for omap4 */
|
|
||||||
node = of_find_node_by_name(NULL, "omap4_padconf_global");
|
|
||||||
if (node)
|
|
||||||
omap4_dsi_mux_syscon = syscon_node_to_regmap(node);
|
|
||||||
|
|
||||||
return 0;
|
|
||||||
}
|
}
|
||||||
|
|
|
@ -26,7 +26,6 @@ struct omap_dss_dispc_dev_attr {
|
||||||
bool has_framedonetv_irq;
|
bool has_framedonetv_irq;
|
||||||
};
|
};
|
||||||
|
|
||||||
int omap_init_drm(void);
|
|
||||||
int omap_init_vrfb(void);
|
int omap_init_vrfb(void);
|
||||||
int omap_init_fb(void);
|
int omap_init_fb(void);
|
||||||
int omap_init_vout(void);
|
int omap_init_vout(void);
|
||||||
|
|
|
@ -1,53 +0,0 @@
|
||||||
/*
|
|
||||||
* DRM/KMS device registration for TI OMAP platforms
|
|
||||||
*
|
|
||||||
* Copyright (C) 2012 Texas Instruments
|
|
||||||
* Author: Rob Clark <rob.clark@linaro.org>
|
|
||||||
*
|
|
||||||
* This program is free software; you can redistribute it and/or modify it
|
|
||||||
* under the terms of the GNU General Public License version 2 as published by
|
|
||||||
* the Free Software Foundation.
|
|
||||||
*
|
|
||||||
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
||||||
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
||||||
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
||||||
* more details.
|
|
||||||
*
|
|
||||||
* You should have received a copy of the GNU General Public License along with
|
|
||||||
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
||||||
*/
|
|
||||||
|
|
||||||
#include <linux/module.h>
|
|
||||||
#include <linux/kernel.h>
|
|
||||||
#include <linux/mm.h>
|
|
||||||
#include <linux/init.h>
|
|
||||||
#include <linux/platform_device.h>
|
|
||||||
#include <linux/dma-mapping.h>
|
|
||||||
#include <linux/platform_data/omap_drm.h>
|
|
||||||
|
|
||||||
#include "soc.h"
|
|
||||||
#include "display.h"
|
|
||||||
|
|
||||||
#if IS_ENABLED(CONFIG_DRM_OMAP)
|
|
||||||
|
|
||||||
static struct omap_drm_platform_data platform_data;
|
|
||||||
|
|
||||||
static struct platform_device omap_drm_device = {
|
|
||||||
.dev = {
|
|
||||||
.coherent_dma_mask = DMA_BIT_MASK(32),
|
|
||||||
.platform_data = &platform_data,
|
|
||||||
},
|
|
||||||
.name = "omapdrm",
|
|
||||||
.id = 0,
|
|
||||||
};
|
|
||||||
|
|
||||||
int __init omap_init_drm(void)
|
|
||||||
{
|
|
||||||
platform_data.omaprev = GET_OMAP_TYPE;
|
|
||||||
|
|
||||||
return platform_device_register(&omap_drm_device);
|
|
||||||
|
|
||||||
}
|
|
||||||
#else
|
|
||||||
int __init omap_init_drm(void) { return 0; }
|
|
||||||
#endif
|
|
|
@ -428,7 +428,6 @@ static void __init __maybe_unused omap_hwmod_init_postsetup(void)
|
||||||
static void __init __maybe_unused omap_common_late_init(void)
|
static void __init __maybe_unused omap_common_late_init(void)
|
||||||
{
|
{
|
||||||
omap2_common_pm_late_init();
|
omap2_common_pm_late_init();
|
||||||
omap_soc_device_init();
|
|
||||||
}
|
}
|
||||||
|
|
||||||
#ifdef CONFIG_SOC_OMAP2420
|
#ifdef CONFIG_SOC_OMAP2420
|
||||||
|
|
|
@ -51,7 +51,6 @@
|
||||||
compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
|
compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
serial1 = &uart1;
|
serial1 = &uart1;
|
||||||
};
|
};
|
||||||
|
@ -68,14 +67,6 @@
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&rgmii_pins>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&i2c1 {
|
&i2c1 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&i2c1_pins>;
|
pinctrl-0 = <&i2c1_pins>;
|
||||||
|
@ -86,13 +77,6 @@
|
||||||
bias-pull-up;
|
bias-pull-up;
|
||||||
};
|
};
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins>;
|
pinctrl-0 = <&mmc0_pins>;
|
||||||
|
|
|
@ -48,18 +48,3 @@
|
||||||
|
|
||||||
/* TODO: Camera, touchscreen, etc. */
|
/* TODO: Camera, touchscreen, etc. */
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&rgmii_pins>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
|
@ -51,7 +51,6 @@
|
||||||
compatible = "pine64,pine64", "allwinner,sun50i-a64";
|
compatible = "pine64,pine64", "allwinner,sun50i-a64";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
serial1 = &uart1;
|
serial1 = &uart1;
|
||||||
serial2 = &uart2;
|
serial2 = &uart2;
|
||||||
|
@ -79,15 +78,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&rmii_pins>;
|
|
||||||
phy-mode = "rmii";
|
|
||||||
phy-handle = <&ext_rmii_phy1>;
|
|
||||||
status = "okay";
|
|
||||||
|
|
||||||
};
|
|
||||||
|
|
||||||
&i2c1 {
|
&i2c1 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&i2c1_pins>;
|
pinctrl-0 = <&i2c1_pins>;
|
||||||
|
@ -98,13 +88,6 @@
|
||||||
bias-pull-up;
|
bias-pull-up;
|
||||||
};
|
};
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rmii_phy1: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins>;
|
pinctrl-0 = <&mmc0_pins>;
|
||||||
|
|
|
@ -53,7 +53,6 @@
|
||||||
"allwinner,sun50i-a64";
|
"allwinner,sun50i-a64";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -77,21 +76,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&rgmii_pins>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc2 {
|
&mmc2 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc2_pins>;
|
pinctrl-0 = <&mmc2_pins>;
|
||||||
|
|
|
@ -449,26 +449,6 @@
|
||||||
#size-cells = <0>;
|
#size-cells = <0>;
|
||||||
};
|
};
|
||||||
|
|
||||||
emac: ethernet@1c30000 {
|
|
||||||
compatible = "allwinner,sun50i-a64-emac";
|
|
||||||
syscon = <&syscon>;
|
|
||||||
reg = <0x01c30000 0x10000>;
|
|
||||||
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
|
|
||||||
interrupt-names = "macirq";
|
|
||||||
resets = <&ccu RST_BUS_EMAC>;
|
|
||||||
reset-names = "stmmaceth";
|
|
||||||
clocks = <&ccu CLK_BUS_EMAC>;
|
|
||||||
clock-names = "stmmaceth";
|
|
||||||
status = "disabled";
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
|
|
||||||
mdio: mdio {
|
|
||||||
#address-cells = <1>;
|
|
||||||
#size-cells = <0>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
gic: interrupt-controller@1c81000 {
|
gic: interrupt-controller@1c81000 {
|
||||||
compatible = "arm,gic-400";
|
compatible = "arm,gic-400";
|
||||||
reg = <0x01c81000 0x1000>,
|
reg = <0x01c81000 0x1000>,
|
||||||
|
|
|
@ -50,7 +50,6 @@
|
||||||
compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
|
compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -109,22 +108,6 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&emac_rgmii_pins>;
|
|
||||||
phy-supply = <®_gmac_3v3>;
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@7 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <7>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||||
|
|
|
@ -59,7 +59,6 @@
|
||||||
};
|
};
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -137,28 +136,12 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&emac_rgmii_pins>;
|
|
||||||
phy-supply = <®_gmac_3v3>;
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&ir {
|
&ir {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&ir_pins_a>;
|
pinctrl-0 = <&ir_pins_a>;
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||||
|
|
|
@ -54,7 +54,6 @@
|
||||||
compatible = "xunlong,orangepi-prime", "allwinner,sun50i-h5";
|
compatible = "xunlong,orangepi-prime", "allwinner,sun50i-h5";
|
||||||
|
|
||||||
aliases {
|
aliases {
|
||||||
ethernet0 = &emac;
|
|
||||||
serial0 = &uart0;
|
serial0 = &uart0;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@ -144,28 +143,12 @@
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&emac {
|
|
||||||
pinctrl-names = "default";
|
|
||||||
pinctrl-0 = <&emac_rgmii_pins>;
|
|
||||||
phy-supply = <®_gmac_3v3>;
|
|
||||||
phy-handle = <&ext_rgmii_phy>;
|
|
||||||
phy-mode = "rgmii";
|
|
||||||
status = "okay";
|
|
||||||
};
|
|
||||||
|
|
||||||
&ir {
|
&ir {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&ir_pins_a>;
|
pinctrl-0 = <&ir_pins_a>;
|
||||||
status = "okay";
|
status = "okay";
|
||||||
};
|
};
|
||||||
|
|
||||||
&mdio {
|
|
||||||
ext_rgmii_phy: ethernet-phy@1 {
|
|
||||||
compatible = "ethernet-phy-ieee802.3-c22";
|
|
||||||
reg = <1>;
|
|
||||||
};
|
|
||||||
};
|
|
||||||
|
|
||||||
&mmc0 {
|
&mmc0 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue