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
Ingo Molnar
commit
edc2988c54
|
|
@ -22,6 +22,8 @@ ifeq ($(HAVE_SPHINX),0)
|
|||
|
||||
.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.)
|
||||
@echo
|
||||
@./scripts/sphinx-pre-install
|
||||
@echo " SKIP Sphinx $@ target."
|
||||
|
||||
else # HAVE_SPHINX
|
||||
|
|
@ -95,16 +97,6 @@ endif # HAVE_SPHINX
|
|||
# The following targets are independent of HAVE_SPHINX, and the rules should
|
||||
# work or silently pass without Sphinx.
|
||||
|
||||
# no-ops for the Sphinx toolchain
|
||||
sgmldocs:
|
||||
@:
|
||||
psdocs:
|
||||
@:
|
||||
mandocs:
|
||||
@:
|
||||
installmandocs:
|
||||
@:
|
||||
|
||||
cleandocs:
|
||||
$(Q)rm -rf $(BUILDDIR)
|
||||
$(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 */
|
||||
|
||||
__raw_writel(virt_to_phys(exynos4_secondary_startup),
|
||||
__raw_writel(__pa_symbol(exynos4_secondary_startup),
|
||||
CPU1_BOOT_REG);
|
||||
|
||||
/* Call Exynos specific smc call */
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ from load_config import loadConfig
|
|||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# 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
|
||||
# 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:
|
||||
latex_elements['preamble'] += '\\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry}'
|
||||
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
|
||||
# (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
|
||||
flexible-arrays
|
||||
librs
|
||||
genalloc
|
||||
|
||||
Interfaces for kernel debugging
|
||||
===============================
|
||||
|
|
|
|||
|
|
@ -31,11 +31,13 @@ Setup
|
|||
CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
|
||||
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,
|
||||
-append, -initrd command line switches. This is generally only useful if
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -348,6 +348,15 @@ default behavior is always set to 0.
|
|||
- ``echo 1 > /sys/module/debug_core/parameters/kgdbreboot``
|
||||
- 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
|
||||
=========
|
||||
|
||||
|
|
@ -358,7 +367,7 @@ This is a quick example of how to use kdb.
|
|||
|
||||
1. Configure kgdboc at boot using kernel parameters::
|
||||
|
||||
console=ttyS0,115200 kgdboc=ttyS0,115200
|
||||
console=ttyS0,115200 kgdboc=ttyS0,115200 nokaslr
|
||||
|
||||
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.
|
||||
- port: contains an endpoint node which is connected to the endpoint in the mic
|
||||
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:
|
||||
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:
|
||||
|
||||
- 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-io-width: See dw_hdmi.txt. Shall be 4.
|
||||
- interrupts: HDMI interrupt number
|
||||
|
|
@ -30,7 +32,8 @@ Optional properties
|
|||
I2C master controller.
|
||||
- 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 "grf", power for grf io.
|
||||
- clock-names: May contain "vpll", external clock for some hdmi phy.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,12 @@ Required properties:
|
|||
- compatible: value should be one of the following
|
||||
"rockchip,rk3036-vop";
|
||||
"rockchip,rk3288-vop";
|
||||
"rockchip,rk3368-vop";
|
||||
"rockchip,rk3366-vop";
|
||||
"rockchip,rk3399-vop-big";
|
||||
"rockchip,rk3399-vop-lit";
|
||||
"rockchip,rk3228-vop";
|
||||
"rockchip,rk3328-vop";
|
||||
|
||||
- interrupts: should contain a list of all VOP IP block interrupts in the
|
||||
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
|
||||
|
||||
- ltdc: lcd-tft display controller host
|
||||
must be a sub-node of st-display-subsystem
|
||||
Required properties:
|
||||
- compatible: "st,stm32-ltdc"
|
||||
- reg: Physical base address of the IP registers and length of memory mapped region.
|
||||
|
|
@ -13,8 +12,40 @@
|
|||
Required nodes:
|
||||
- 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 {
|
||||
|
|
@ -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
|
||||
that are going to be documented below:
|
||||
|
||||
For the input port of all components up to the TCON in the display
|
||||
pipeline, if there are multiple components, the local endpoint IDs
|
||||
must correspond to the index of the upstream block. For example, if
|
||||
the remote endpoint is Frontend 1, then the local endpoint ID must
|
||||
be 1.
|
||||
For all connections between components up to the TCONs in the display
|
||||
pipeline, when there are multiple components of the same type at the
|
||||
same depth, the local endpoint ID must be the same as the remote
|
||||
component's index. For example, if the remote endpoint is Frontend 1,
|
||||
then the local endpoint ID must be 1.
|
||||
|
||||
Conversely, for the output ports of the same group, the remote endpoint
|
||||
ID must be the index of the local hardware block. If the local backend
|
||||
is backend 1, then the remote endpoint ID must be 1.
|
||||
Frontend 0 [0] ------- [0] Backend 0 [0] ------- [0] TCON 0
|
||||
[1] -- -- [1] [1] -- -- [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
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -11,6 +11,8 @@ Required properties for pwm-tacho node:
|
|||
|
||||
- #size-cells : should be 1.
|
||||
|
||||
- #cooling-cells: should be 2.
|
||||
|
||||
- reg : address and length of the register set for the device.
|
||||
|
||||
- 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
|
||||
representing a fan. If there are 8 fans each fan can have one PWM port and
|
||||
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:
|
||||
- reg : should specify PWM source port.
|
||||
integer value in the range 0 to 7 with 0 indicating PWM port A and
|
||||
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.
|
||||
integer value in the range 0 through 15, with 0 indicating
|
||||
Fan tach channel 0 and 15 indicating Fan tach channel 15.
|
||||
|
|
@ -50,6 +57,7 @@ pwm_tacho_fixed_clk: fixedclk {
|
|||
pwm_tacho: pwmtachocontroller@1e786000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
#cooling-cells = <2>;
|
||||
reg = <0x1E786000 0x1000>;
|
||||
compatible = "aspeed,ast2500-pwm-tacho";
|
||||
clocks = <&pwm_tacho_fixed_clk>;
|
||||
|
|
@ -58,6 +66,7 @@ pwm_tacho: pwmtachocontroller@1e786000 {
|
|||
|
||||
fan@0 {
|
||||
reg = <0x00>;
|
||||
cooling-levels = /bits/ 8 <125 151 177 203 229 255>;
|
||||
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
|
||||
parade Parade Technologies Inc.
|
||||
pericom Pericom Technology Inc.
|
||||
pervasive Pervasive Displays, Inc.
|
||||
phytec PHYTEC Messtechnik GmbH
|
||||
picochip Picochip Ltd
|
||||
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
|
||||
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
|
||||
============
|
||||
|
||||
|
|
@ -118,7 +222,7 @@ Here are some specific guidelines for the kernel documentation:
|
|||
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:
|
||||
|
||||
.. code-block:: rst
|
||||
|
|
@ -229,6 +333,7 @@ Rendered as:
|
|||
|
||||
- column 3
|
||||
|
||||
.. _sphinx_kfigure:
|
||||
|
||||
Figures & Images
|
||||
================
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Driver Basics
|
|||
Driver Entry and Exit points
|
||||
----------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/init.h
|
||||
.. kernel-doc:: include/linux/module.h
|
||||
:internal:
|
||||
|
||||
Driver device table
|
||||
|
|
@ -103,9 +103,6 @@ Kernel utility functions
|
|||
.. kernel-doc:: kernel/panic.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: kernel/sys.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: kernel/rcu/tree.c
|
||||
:export:
|
||||
|
||||
|
|
|
|||
|
|
@ -139,9 +139,6 @@ DMA Fences
|
|||
Seqno Hardware Fences
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: drivers/dma-buf/seqno-fence.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/linux/seqno-fence.h
|
||||
:internal:
|
||||
|
||||
|
|
|
|||
|
|
@ -47,4 +47,3 @@ used by one consumer at a time.
|
|||
|
||||
.. kernel-doc:: drivers/pwm/core.c
|
||||
: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
|
||||
attached device.
|
||||
|
||||
.. kernel-doc:: arch/s390/include/asm/cmb.h
|
||||
.. kernel-doc:: arch/s390/include/uapi/asm/cmb.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/s390/cio/cmf.c
|
||||
|
|
|
|||
|
|
@ -224,14 +224,6 @@ mid to lowlevel SCSI driver interface
|
|||
.. kernel-doc:: drivers/scsi/hosts.c
|
||||
:export:
|
||||
|
||||
drivers/scsi/constants.c
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
mid to lowlevel SCSI driver interface
|
||||
|
||||
.. kernel-doc:: drivers/scsi/constants.c
|
||||
:export:
|
||||
|
||||
Transport classes
|
||||
-----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@
|
|||
| mn10300: | ok |
|
||||
| nios2: | ok |
|
||||
| openrisc: | ok |
|
||||
| parisc: | TODO |
|
||||
| parisc: | ok |
|
||||
| powerpc: | ok |
|
||||
| s390: | ok |
|
||||
| score: | TODO |
|
||||
|
|
|
|||
|
|
@ -829,9 +829,7 @@ struct address_space_operations {
|
|||
swap_activate: Called when swapon is used on a file to allocate
|
||||
space if necessary and pin the block lookup information in
|
||||
memory. A return value of zero indicates success,
|
||||
in which case this file can be used to back swapspace. The
|
||||
swapspace operations will be proxied to this address space's
|
||||
->swap_{out,in} methods.
|
||||
in which case this file can be used to back swapspace.
|
||||
|
||||
swap_deactivate: Called during swapoff on files where swap_activate
|
||||
was successful.
|
||||
|
|
|
|||
|
|
@ -201,6 +201,8 @@ drivers.
|
|||
Open/Close, File Operations and IOCTLs
|
||||
======================================
|
||||
|
||||
.. _drm_driver_fops:
|
||||
|
||||
File Operations
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -296,3 +296,12 @@ Auxiliary Modeset Helpers
|
|||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
|
||||
: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
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: include/drm/drm_color_mgmt.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
|
||||
:export:
|
||||
|
||||
|
|
@ -554,60 +551,8 @@ various modules/drivers.
|
|||
Vertical Blanking
|
||||
=================
|
||||
|
||||
Vertical blanking plays a major role in graphics rendering. To achieve
|
||||
tear-free display, users must synchronize page flips and/or rendering to
|
||||
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.
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
|
||||
:doc: vblank handling
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
free the GEM object and all associated resources.
|
||||
|
||||
|
|
@ -492,7 +492,7 @@ DRM Sync Objects
|
|||
:doc: Overview
|
||||
|
||||
.. kernel-doc:: include/drm/drm_syncobj.h
|
||||
:export:
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
|
||||
: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
|
||||
cannot support render nodes.
|
||||
|
||||
.. _drm_driver_ioctl:
|
||||
|
||||
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
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||
: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
|
||||
----------------
|
||||
|
|
@ -477,4 +481,16 @@ specific details than found in the more high-level sections.
|
|||
.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
|
||||
: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
|
||||
__drm_atomic_helper_crtc_duplicate_state().
|
||||
|
||||
- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_
|
||||
prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this
|
||||
- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_
|
||||
prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this
|
||||
is a function useful to implement the fb->dirty function.
|
||||
|
||||
- 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
|
||||
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:
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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: -
|
||||
Datasheet:
|
||||
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>
|
||||
|
||||
|
|
@ -37,8 +42,8 @@ Description
|
|||
-----------
|
||||
|
||||
This driver supports hardware monitoring for National Semiconductor / TI LM25056,
|
||||
LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and
|
||||
Protection ICs.
|
||||
LM25063, LM25066, LM5064, and LM5066/LM5066I Power Management, Monitoring,
|
||||
Control, and Protection ICs.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
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`` 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.
|
||||
|
||||
mousedev
|
||||
|
|
|
|||
|
|
@ -12,7 +12,6 @@ Linux Joystick support
|
|||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:numbered:
|
||||
|
||||
joystick
|
||||
joystick-api
|
||||
|
|
|
|||
|
|
@ -297,9 +297,9 @@ more details, with real examples.
|
|||
ccflags-y specifies options for compiling with $(CC).
|
||||
|
||||
Example:
|
||||
# drivers/acpi/Makefile
|
||||
ccflags-y := -Os
|
||||
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
||||
# drivers/acpi/acpica/Makefile
|
||||
ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA
|
||||
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
||||
|
||||
This variable is necessary because the top Makefile owns the
|
||||
variable $(KBUILD_CFLAGS) and uses it for compilation flags for 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
|
||||
the waiter on the process's stack (local variable). This
|
||||
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
|
||||
place the task in the waiter_list of a mutex as well as the
|
||||
pi_list of a mutex owner task (described below).
|
||||
the task is blocked on. It also has rbtree node structures to
|
||||
place the task in the waiters rbtree of a mutex as well as the
|
||||
pi_waiters rbtree of a mutex owner task (described below).
|
||||
|
||||
waiter is sometimes used in reference to the task that is waiting
|
||||
on a mutex. This is the same as waiter->task.
|
||||
|
|
@ -179,53 +179,34 @@ again.
|
|||
|
|
||||
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
|
||||
-----
|
||||
|
||||
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
|
||||
Mutex Waiters Tree
|
||||
-----------------
|
||||
|
||||
Every mutex keeps track of all the waiters that are blocked on itself. The mutex
|
||||
has a plist to store these waiters by priority. This list is protected 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
|
||||
interrupt context, the wait_lock can be taken without disabling interrupts.
|
||||
Every mutex keeps track of all the waiters that are blocked on itself. The
|
||||
mutex has a rbtree to store these waiters by priority. This tree is protected
|
||||
by a spin lock that is located in the struct of the mutex. This lock is called
|
||||
wait_lock.
|
||||
|
||||
|
||||
Task PI List
|
||||
Task PI Tree
|
||||
------------
|
||||
|
||||
To keep track of the PI chains, each process has its own PI list. This is
|
||||
a list 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
|
||||
To keep track of the PI chains, each process has its own PI rbtree. This is
|
||||
a tree of all top waiters of the mutexes that are owned by the process.
|
||||
Note that this tree only holds the top waiters and not all waiters that are
|
||||
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
|
||||
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
|
||||
pi_list. This list is protected by a spin lock also in the task structure,
|
||||
This tree is stored in the task structure of a process as a rbtree called
|
||||
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
|
||||
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
|
||||
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
|
||||
not true, the rtmutex.c code will be broken!), this allows for the two
|
||||
least significant bits to be used as flags. This part is also described
|
||||
in Documentation/rt-mutex.txt, but will also be briefly described here.
|
||||
|
||||
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.
|
||||
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 least
|
||||
significant bit to be used as a flag. Bit 0 is used as the "Has Waiters"
|
||||
flag. It's set whenever there are waiters on a mutex.
|
||||
|
||||
See Documentation/locking/rt-mutex.txt for further details.
|
||||
|
||||
cmpxchg Tricks
|
||||
--------------
|
||||
|
|
@ -359,40 +337,31 @@ Priority adjustments
|
|||
--------------------
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
to already be taken), rt_mutex_getprio, and rt_mutex_setprio.
|
||||
The functions implementing the task adjustments are rt_mutex_adjust_prio
|
||||
and rt_mutex_setprio. rt_mutex_setprio is only used in rt_mutex_adjust_prio.
|
||||
|
||||
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
|
||||
task's own normal priority, or if a process of a higher priority is waiting on
|
||||
a mutex owned by the task, then that higher priority should be returned.
|
||||
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: For the "prio" field in task_struct, the lower the number, the
|
||||
higher the priority. A "prio" of 5 is of higher priority than a
|
||||
"prio" of 10.)
|
||||
|
||||
(Note: if looking at the code, you will notice that the lower number of
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
by the task, so we only need to compare the priority of that top pi waiter
|
||||
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
|
||||
(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
|
||||
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
|
||||
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
|
||||
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
|
||||
with the new priorities, and that this task may not be in the proper locations
|
||||
in the pi_lists and wait_lists that the task is blocked on. This function
|
||||
should be at, but the rbtree nodes of the task's waiter have not been updated
|
||||
with the new priorities, and this task may not be in the proper locations
|
||||
in the pi_waiters and waiters trees that the task is blocked on. This function
|
||||
solves all that.
|
||||
|
||||
A loop is entered, where task is the owner to be checked for PI changes that
|
||||
was passed by parameter (for the first iteration). The pi_lock of this task is
|
||||
taken to prevent any more changes to the pi_list of the task. This also
|
||||
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.
|
||||
|
||||
The main operation of this function is summarized by Thomas Gleixner in
|
||||
rtmutex.c. See the 'Chain walk basics and protection scope' comment for further
|
||||
details.
|
||||
|
||||
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
|
||||
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
|
||||
we go about the slow path (rt_mutex_slowlock).
|
||||
If there is contention on the lock, we go about the slow path
|
||||
(rt_mutex_slowlock).
|
||||
|
||||
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
|
||||
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 owner.
|
||||
the task on the waiters tree of the mutex, and if need be, the pi_waiters
|
||||
tree of the owner.
|
||||
|
||||
The wait_lock of the mutex is taken since the slow path of unlocking the
|
||||
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
|
||||
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
|
||||
be false, because if the mutex has no owner, there are no waiters and
|
||||
the current task also won't have any waiters. But we don't have the lock
|
||||
yet, so we assume we are going to be a waiter. The reason for this is to
|
||||
play nice for those architectures that do have CMPXCHG. By setting this flag
|
||||
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.
|
||||
the "Has Waiters" flag of the mutex's owner field. By setting this flag
|
||||
now, the current owner of the mutex being contended for 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 current owner to synchronize with this code.
|
||||
|
||||
Now that we know that we can't have any races with the owner releasing the
|
||||
mutex, we check to see if we can take the ownership. This is done if the
|
||||
mutex doesn't have a owner, or if we can steal the mutex from a pending
|
||||
owner. Let's look at the situations we have here.
|
||||
The lock is taken if the following are true:
|
||||
1) The lock has no owner
|
||||
2) The current task is the highest priority against all other
|
||||
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
|
||||
"Pending Owner" is set. The first check is to see if the owner isn't the
|
||||
current task. This is because this function is also used for the pending
|
||||
owner to grab the mutex. When a pending owner wakes up, it checks to see
|
||||
if it can take the mutex, and this is done if the owner is already set to
|
||||
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.
|
||||
If the lock is not taken by try_to_take_rt_mutex(), then the
|
||||
task_blocks_on_rt_mutex() function is called. This will add the task to
|
||||
the lock's waiter tree and propagate the pi chain of the lock as well
|
||||
as the lock's owner's pi_waiters tree. This is described in the next
|
||||
section.
|
||||
|
||||
Task blocks on mutex
|
||||
--------------------
|
||||
|
||||
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
|
||||
to the mutex. The plist nodes are initialized to the processes current
|
||||
priority.
|
||||
to the mutex. The rbtree node of waiter are initialized to the processes
|
||||
current priority.
|
||||
|
||||
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
|
||||
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,
|
||||
and add the current process to that list. Since the pi_list of the owner
|
||||
add the waiter to the task waiter tree. If the current process is the
|
||||
highest priority process currently waiting on this mutex, then we remove the
|
||||
previous top waiter process (if it exists) from the pi_waiters 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
|
||||
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
|
||||
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
|
||||
---------------------
|
||||
|
||||
The schedule can then wake up for a few reasons.
|
||||
1) we were given pending ownership of the mutex.
|
||||
2) we received a signal and was TASK_INTERRUPTIBLE
|
||||
3) we had a timeout and was TASK_INTERRUPTIBLE
|
||||
The task can then wake up for a couple of reasons:
|
||||
1) The previous lock owner released the lock, and the task now is top_waiter
|
||||
2) we received a signal or timeout
|
||||
|
||||
In any of these cases, we continue the loop and once again try to grab the
|
||||
ownership of the mutex. If we succeed, we exit the loop, otherwise we continue
|
||||
and on signal and timeout, will exit the loop, or if we had the mutex stolen
|
||||
we just simply add ourselves back on the lists and go back to sleep.
|
||||
In both cases, the task will try again to acquire the lock. If it
|
||||
does, then it will take itself off the waiters tree and set itself back
|
||||
to the TASK_RUNNING state.
|
||||
|
||||
Note: For various reasons, because of timeout and signals, the steal mutex
|
||||
algorithm needs to be careful. This is because the current process is
|
||||
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.
|
||||
In first case, if the lock was acquired by another task before this task
|
||||
could get the lock, then it will go back to sleep and wait to be woken again.
|
||||
|
||||
Failed to get mutex on Timeout or Signal
|
||||
----------------------------------------
|
||||
|
||||
If a timeout or signal occurred, the waiter's "task" field would not be
|
||||
NULL and the task needs to be taken off the wait_list of the mutex and perhaps
|
||||
pi_list of the owner. If this process was a high priority process, then
|
||||
the rt_mutex_adjust_prio_chain needs to be executed again on the owner,
|
||||
but this time it will be lowering the priorities.
|
||||
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
|
||||
take the lock again, if it succeeds, then the task will return with the
|
||||
lock held, otherwise it will return with -EINTR if the task was woken
|
||||
by a signal, or -ETIMEDOUT if it timed out.
|
||||
|
||||
|
||||
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
|
||||
needed.
|
||||
|
||||
If there are waiters, then we need to wake one up and give that waiter
|
||||
pending ownership.
|
||||
If there are waiters, then we need to wake one up.
|
||||
|
||||
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
|
||||
as well as the pi_list of the current owner. The task field of the new
|
||||
pending owner's waiter structure is set to NULL, and the owner field of the
|
||||
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.
|
||||
waiter of the lock is found and removed from the waiters tree of the mutex
|
||||
as well as the pi_waiters tree of the current owner. The "Has Waiters" bit is
|
||||
marked to prevent lower priority tasks from stealing the lock.
|
||||
|
||||
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>
|
||||
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
|
||||
-------
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
got a signal), the priority of the owner task is readjusted. [The
|
||||
priority enqueueing is handled by "plists", see include/linux/plist.h
|
||||
for more details.]
|
||||
got a signal), the priority of the owner task is readjusted. The
|
||||
priority enqueueing is handled by "pi_waiters".
|
||||
|
||||
RT-mutexes are optimized for fastpath operations and have no internal
|
||||
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
|
||||
structure:
|
||||
|
||||
rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1
|
||||
are used to keep track of the "owner is pending" and "rtmutex has
|
||||
waiters" state.
|
||||
lock->owner holds the task_struct pointer of the owner. Bit 0 is used to
|
||||
keep track of the "lock has waiters" state.
|
||||
|
||||
owner bit1 bit0
|
||||
NULL 0 0 mutex is free (fast acquire possible)
|
||||
NULL 0 1 invalid state
|
||||
NULL 1 0 Transitional state*
|
||||
NULL 1 1 invalid state
|
||||
taskpointer 0 0 mutex is held (fast release possible)
|
||||
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
|
||||
owner bit0
|
||||
NULL 0 lock is free (fast acquire possible)
|
||||
NULL 1 lock is free and has waiters and the top waiter
|
||||
is going to take the lock*
|
||||
taskpointer 0 lock is held (fast release possible)
|
||||
taskpointer 1 lock is held and has waiters**
|
||||
|
||||
Pending-ownership handling is a performance optimization:
|
||||
pending-ownership is assigned to the first (highest priority) waiter of
|
||||
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 fast atomic compare exchange based acquire and release is only
|
||||
possible when bit 0 of lock->owner is 0.
|
||||
|
||||
The pending-ownership optimization is especially important for the
|
||||
uninterrupted workflow of high-prio tasks which repeatedly
|
||||
takes/releases locks that have lower-prio waiters. Without this
|
||||
optimization the higher-prio thread would ping-pong to the lower-prio
|
||||
task [because at unlock time we always assign a new owner].
|
||||
(*) It also can be a transitional state when grabbing the lock
|
||||
with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
|
||||
we need to set the bit0 before looking at the lock, and the owner may be
|
||||
NULL in this small time, hence this can be a transitional state.
|
||||
|
||||
(*) The "mutex has waiters" bit gets set to take the lock. If the lock
|
||||
doesn't already have an owner, this bit is quickly cleared if there are
|
||||
no waiters. So this is a transitional state to synchronize with looking
|
||||
at the owner field of the mutex and the mutex owner releasing the lock.
|
||||
(**) There is a small time when bit 0 is set but there are no
|
||||
waiters. This can happen when grabbing the lock in the slow path.
|
||||
To prevent a cmpxchg of the owner releasing the lock, we need to
|
||||
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::
|
||||
:maxdepth: 1
|
||||
:numbered:
|
||||
|
||||
cec-func-open
|
||||
cec-func-close
|
||||
|
|
|
|||
|
|
@ -84,17 +84,17 @@ Device drivers API
|
|||
==================
|
||||
|
||||
The include/net/mac802154.h defines following functions:
|
||||
- struct ieee802154_dev *ieee802154_alloc_device
|
||||
(size_t priv_size, struct ieee802154_ops *ops):
|
||||
allocation of IEEE 802.15.4 compatible device
|
||||
- struct ieee802154_hw *
|
||||
ieee802154_alloc_hw(size_t priv_data_len, const struct ieee802154_ops *ops):
|
||||
allocation of IEEE 802.15.4 compatible hardware device
|
||||
|
||||
- void ieee802154_free_device(struct ieee802154_dev *dev):
|
||||
freeing allocated device
|
||||
- void ieee802154_free_hw(struct ieee802154_hw *hw):
|
||||
freeing allocated hardware device
|
||||
|
||||
- int ieee802154_register_device(struct ieee802154_dev *dev):
|
||||
register PHY in the system
|
||||
- int ieee802154_register_hw(struct ieee802154_hw *hw):
|
||||
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
|
||||
|
||||
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
|
||||
=====================================
|
||||
|
||||
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.
|
||||
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:
|
||||
Jesper Juhl, August 2005
|
||||
|
||||
Last update:
|
||||
2016-09-14
|
||||
|
||||
.. note::
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
|
||||
|
||||
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
|
||||
=======================================
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ mcelog 0.6 mcelog --version
|
|||
iptables 1.4.2 iptables -V
|
||||
openssl & libcrypto 1.0.0 openssl 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
|
||||
|
|
@ -309,18 +309,8 @@ Kernel documentation
|
|||
Sphinx
|
||||
------
|
||||
|
||||
The ReST markups currently used by the Documentation/ files are meant to be
|
||||
built with ``Sphinx`` version 1.2 or upper. If you're desiring to build
|
||||
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).
|
||||
|
||||
Please see :ref:`sphinx_install` in ``Documentation/doc-guide/sphinx.rst``
|
||||
for details about Sphinx requirements.
|
||||
|
||||
Getting updated software
|
||||
========================
|
||||
|
|
|
|||
|
|
@ -166,12 +166,12 @@ Trees
|
|||
- The queues of patches, for both completed versions and in progress
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -16,17 +16,7 @@ The key service can be configured on by enabling:
|
|||
|
||||
This document has the following sections:
|
||||
|
||||
- Key overview
|
||||
- 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
|
||||
.. contents:: :local:
|
||||
|
||||
|
||||
Key Overview
|
||||
|
|
@ -443,7 +433,7 @@ The main syscalls are:
|
|||
/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.
|
||||
|
||||
See also Documentation/security/keys-request-key.txt.
|
||||
See also Documentation/security/keys/request-key.rst.
|
||||
|
||||
|
||||
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
|
||||
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::
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Key Request Service
|
|||
===================
|
||||
|
||||
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 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
|
||||
in order to use encrypted keys to mount an eCryptfs filesystem. More details
|
||||
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 {
|
||||
|
||||
/* content column
|
||||
|
|
@ -56,6 +67,12 @@
|
|||
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 */
|
||||
|
||||
code, .rst-content tt, .rst-content code {
|
||||
|
|
|
|||
|
|
@ -27,6 +27,7 @@
|
|||
# Please make sure this works on both python2 and python3.
|
||||
#
|
||||
|
||||
import codecs
|
||||
import os
|
||||
import subprocess
|
||||
import sys
|
||||
|
|
@ -88,13 +89,10 @@ class KernelDocDirective(Directive):
|
|||
try:
|
||||
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()
|
||||
|
||||
# python2 needs conversion to unicode.
|
||||
# python3 with universal_newlines=True returns strings.
|
||||
if sys.version_info.major < 3:
|
||||
out, err = unicode(out, 'utf-8'), unicode(err, 'utf-8')
|
||||
out, err = codecs.decode(out, 'utf-8'), codecs.decode(err, 'utf-8')
|
||||
|
||||
if p.returncode != 0:
|
||||
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和手册
|
||||
页等不同格式的文档：
|
||||
make pdfdocs
|
||||
make psdocs
|
||||
make htmldocs
|
||||
make mandocs
|
||||
|
||||
|
||||
如何成为内核开发者
|
||||
|
|
|
|||
23
MAINTAINERS
23
MAINTAINERS
|
|
@ -4359,6 +4359,12 @@ S: Maintained
|
|||
F: drivers/gpu/drm/qxl/
|
||||
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
|
||||
S: Orphan / Obsolete
|
||||
F: drivers/gpu/drm/r128/
|
||||
|
|
@ -4374,6 +4380,12 @@ S: Orphan / Obsolete
|
|||
F: drivers/gpu/drm/sis/
|
||||
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
|
||||
S: Orphan / Obsolete
|
||||
F: drivers/gpu/drm/tdfx/
|
||||
|
|
@ -4622,6 +4634,14 @@ F: drivers/gpu/drm/panel/
|
|||
F: include/drm/drm_panel.h
|
||||
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
|
||||
M: Alexey Klimov <klimov.linux@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
|
|
@ -6744,8 +6764,9 @@ S: Supported
|
|||
F: drivers/scsi/isci/
|
||||
|
||||
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: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
||||
M: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
||||
L: intel-gfx@lists.freedesktop.org
|
||||
W: https://01.org/linuxgraphics/
|
||||
B: https://01.org/linuxgraphics/documentation/how-report-bugs
|
||||
|
|
|
|||
4
Makefile
4
Makefile
|
|
@ -1,7 +1,7 @@
|
|||
VERSION = 4
|
||||
PATCHLEVEL = 13
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc6
|
||||
EXTRAVERSION =
|
||||
NAME = Fearless Coyote
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -1468,7 +1468,7 @@ $(help-board-dirs): help-%:
|
|||
|
||||
# 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)
|
||||
$(DOC_TARGETS): scripts_basic FORCE
|
||||
$(Q)$(MAKE) $(build)=Documentation $@
|
||||
|
|
|
|||
|
|
@ -299,6 +299,7 @@ static inline void __iomem * ioremap_nocache(unsigned long offset,
|
|||
return ioremap(offset, size);
|
||||
}
|
||||
|
||||
#define ioremap_wc ioremap_nocache
|
||||
#define ioremap_uc ioremap_nocache
|
||||
|
||||
static inline void iounmap(volatile void __iomem *addr)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
#ifndef _ALPHA_TYPES_H
|
||||
#define _ALPHA_TYPES_H
|
||||
|
||||
#include <asm-generic/int-ll64.h>
|
||||
#include <uapi/asm/types.h>
|
||||
|
||||
#endif /* _ALPHA_TYPES_H */
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
#include <uapi/asm/unistd.h>
|
||||
|
||||
#define NR_SYSCALLS 514
|
||||
#define NR_SYSCALLS 523
|
||||
|
||||
#define __ARCH_WANT_OLD_READDIR
|
||||
#define __ARCH_WANT_STAT64
|
||||
|
|
|
|||
|
|
@ -9,8 +9,18 @@
|
|||
* 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>
|
||||
#else
|
||||
#include <asm-generic/int-ll64.h>
|
||||
#endif
|
||||
|
||||
#endif /* _UAPI_ALPHA_TYPES_H */
|
||||
|
|
|
|||
|
|
@ -475,5 +475,19 @@
|
|||
#define __NR_getrandom 511
|
||||
#define __NR_memfd_create 512
|
||||
#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 */
|
||||
|
|
|
|||
|
|
@ -351,7 +351,7 @@ marvel_init_io7(struct io7 *io7)
|
|||
}
|
||||
}
|
||||
|
||||
void
|
||||
void __init
|
||||
marvel_io7_present(gct6_node *node)
|
||||
{
|
||||
int pe;
|
||||
|
|
@ -369,6 +369,7 @@ marvel_io7_present(gct6_node *node)
|
|||
static void __init
|
||||
marvel_find_console_vga_hose(void)
|
||||
{
|
||||
#ifdef CONFIG_VGA_HOSE
|
||||
u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset);
|
||||
|
||||
if (pu64[7] == 3) { /* TERM_TYPE == graphics */
|
||||
|
|
@ -402,9 +403,10 @@ marvel_find_console_vga_hose(void)
|
|||
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 },
|
||||
{ 0, 0, NULL }
|
||||
};
|
||||
|
|
|
|||
|
|
@ -461,6 +461,7 @@ titan_ioremap(unsigned long addr, unsigned long size)
|
|||
unsigned long *ptes;
|
||||
unsigned long pfn;
|
||||
|
||||
#ifdef CONFIG_VGA_HOSE
|
||||
/*
|
||||
* Adjust the address and hose, if necessary.
|
||||
*/
|
||||
|
|
@ -468,6 +469,7 @@ titan_ioremap(unsigned long addr, unsigned long size)
|
|||
h = pci_vga_hose->index;
|
||||
addr += pci_vga_hose->mem_space->start;
|
||||
}
|
||||
#endif
|
||||
|
||||
/*
|
||||
* Find the hose.
|
||||
|
|
|
|||
|
|
@ -181,6 +181,9 @@ apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
|
|||
switch (r_type) {
|
||||
case R_ALPHA_NONE:
|
||||
break;
|
||||
case R_ALPHA_REFLONG:
|
||||
*(u32 *)location = value;
|
||||
break;
|
||||
case R_ALPHA_REFQUAD:
|
||||
/* BUG() can produce misaligned relocations. */
|
||||
((u32 *)location)[0] = value;
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ wait_boot_cpu_to_stop(int cpuid)
|
|||
/*
|
||||
* Where secondaries begin a life of C.
|
||||
*/
|
||||
void
|
||||
void __init
|
||||
smp_callin(void)
|
||||
{
|
||||
int cpuid = hard_smp_processor_id();
|
||||
|
|
|
|||
|
|
@ -532,6 +532,15 @@ sys_call_table:
|
|||
.quad sys_getrandom
|
||||
.quad sys_memfd_create
|
||||
.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
|
||||
.type sys_call_table, @object
|
||||
|
|
|
|||
|
|
@ -20,12 +20,8 @@ lib-y = __divqu.o __remqu.o __divlu.o __remlu.o \
|
|||
checksum.o \
|
||||
csum_partial_copy.o \
|
||||
$(ev67-y)strlen.o \
|
||||
$(ev67-y)strcat.o \
|
||||
strcpy.o \
|
||||
$(ev67-y)strncat.o \
|
||||
strncpy.o \
|
||||
$(ev6-y)stxcpy.o \
|
||||
$(ev6-y)stxncpy.o \
|
||||
stycpy.o \
|
||||
styncpy.o \
|
||||
$(ev67-y)strchr.o \
|
||||
$(ev67-y)strrchr.o \
|
||||
$(ev6-y)memchr.o \
|
||||
|
|
@ -49,3 +45,17 @@ AFLAGS___remlu.o = -DREM -DINTSIZE
|
|||
$(addprefix $(obj)/,__divqu.o __remqu.o __divlu.o __remlu.o): \
|
||||
$(src)/$(ev6-y)divide.S FORCE
|
||||
$(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
|
||||
__copy_user:
|
||||
.prologue 0
|
||||
and $18,$18,$0
|
||||
mov $18,$0
|
||||
and $16,7,$3
|
||||
beq $0,$35
|
||||
beq $3,$36
|
||||
|
|
|
|||
|
|
@ -45,9 +45,10 @@
|
|||
# Pipeline info: Slotting & Comments
|
||||
__copy_user:
|
||||
.prologue 0
|
||||
andq $18, $18, $0
|
||||
subq $18, 32, $1 # .. E .. .. : Is this going to be a small copy?
|
||||
beq $0, $zerolength # U .. .. .. : U L U L
|
||||
mov $18, $0 # .. .. .. E
|
||||
subq $18, 32, $1 # .. .. E. .. : Is this going to be a small copy?
|
||||
nop # .. E .. ..
|
||||
beq $18, $zerolength # U .. .. .. : U L U L
|
||||
|
||||
and $16,7,$3 # .. .. .. E : is leading dest misalignment
|
||||
ble $1, $onebyteloop # .. .. U .. : 1st branch : small amount of data
|
||||
|
|
|
|||
|
|
@ -75,13 +75,20 @@ void arc_init_IRQ(void)
|
|||
* Set a default priority for all available interrupts to prevent
|
||||
* switching of register banks if Fast IRQ and multiple register banks
|
||||
* 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.
|
||||
*/
|
||||
for (i = NR_EXCEPTIONS; i < irq_bcr.irqs + NR_EXCEPTIONS; i++) {
|
||||
write_aux_reg(AUX_IRQ_SELECT, i);
|
||||
write_aux_reg(AUX_IRQ_PRIORITY, ARCV2_IRQ_DEF_PRIO);
|
||||
write_aux_reg(AUX_IRQ_ENABLE, 0);
|
||||
|
||||
/*
|
||||
* 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);
|
||||
}
|
||||
|
||||
/* setup status32, don't enable intr yet as kernel doesn't want */
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
*/
|
||||
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) */
|
||||
level_mask |= IS_ENABLED(CONFIG_ARC_COMPACT_IRQ_LEVELS) << TIMER0_IRQ;
|
||||
|
|
|
|||
|
|
@ -56,8 +56,6 @@
|
|||
|
||||
aliases {
|
||||
serial0 = &uart0;
|
||||
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
|
||||
ethernet0 = &emac;
|
||||
ethernet1 = &xr819;
|
||||
};
|
||||
|
||||
|
|
@ -104,13 +102,6 @@
|
|||
status = "okay";
|
||||
};
|
||||
|
||||
&emac {
|
||||
phy-handle = <&int_mii_phy>;
|
||||
phy-mode = "mii";
|
||||
allwinner,leds-active-low;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc0_pins_a>;
|
||||
|
|
|
|||
|
|
@ -52,7 +52,6 @@
|
|||
compatible = "sinovoip,bpi-m2-plus", "allwinner,sun8i-h3";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
serial1 = &uart1;
|
||||
};
|
||||
|
|
@ -115,30 +114,12 @@
|
|||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ir_pins_a>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&mdio {
|
||||
ext_rgmii_phy: ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||
|
|
|
|||
|
|
@ -46,10 +46,3 @@
|
|||
model = "FriendlyARM NanoPi NEO";
|
||||
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 {
|
||||
serial0 = &uart0;
|
||||
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
|
||||
ethernet0 = &emac;
|
||||
ethernet1 = &rtl8189;
|
||||
};
|
||||
|
||||
|
|
@ -118,13 +117,6 @@
|
|||
status = "okay";
|
||||
};
|
||||
|
||||
&emac {
|
||||
phy-handle = <&int_mii_phy>;
|
||||
phy-mode = "mii";
|
||||
allwinner,leds-active-low;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&ir {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ir_pins_a>;
|
||||
|
|
|
|||
|
|
@ -52,7 +52,6 @@
|
|||
compatible = "xunlong,orangepi-one", "allwinner,sun8i-h3";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
};
|
||||
|
||||
|
|
@ -98,13 +97,6 @@
|
|||
status = "okay";
|
||||
};
|
||||
|
||||
&emac {
|
||||
phy-handle = <&int_mii_phy>;
|
||||
phy-mode = "mii";
|
||||
allwinner,leds-active-low;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc1_pins_a>;
|
||||
|
|
|
|||
|
|
@ -52,7 +52,6 @@
|
|||
compatible = "xunlong,orangepi-pc", "allwinner,sun8i-h3";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
};
|
||||
|
||||
|
|
@ -114,13 +113,6 @@
|
|||
status = "okay";
|
||||
};
|
||||
|
||||
&emac {
|
||||
phy-handle = <&int_mii_phy>;
|
||||
phy-mode = "mii";
|
||||
allwinner,leds-active-low;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&ir {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ir_pins_a>;
|
||||
|
|
|
|||
|
|
@ -47,10 +47,6 @@
|
|||
model = "Xunlong Orange Pi Plus / Plus 2";
|
||||
compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
};
|
||||
|
||||
reg_gmac_3v3: gmac-3v3 {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "gmac-3v3";
|
||||
|
|
@ -78,24 +74,6 @@
|
|||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc2_8bit_pins>;
|
||||
|
|
|
|||
|
|
@ -61,19 +61,3 @@
|
|||
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>;
|
||||
};
|
||||
|
||||
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 {
|
||||
compatible = "allwinner,sun8i-h3-spi";
|
||||
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_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 __percpu **kvm_get_running_vcpus(void);
|
||||
void kvm_arm_halt_guest(struct kvm *kvm);
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ ccflags-y := -I$(srctree)/$(src)/include \
|
|||
# Common support
|
||||
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 \
|
||||
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 \
|
||||
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);
|
||||
|
||||
omapdss_init_of();
|
||||
omap_soc_device_init();
|
||||
}
|
||||
|
||||
#ifdef CONFIG_SOC_OMAP2420
|
||||
|
|
|
|||
|
|
@ -66,6 +66,7 @@
|
|||
*/
|
||||
#define FRAMEDONE_IRQ_TIMEOUT 100
|
||||
|
||||
#if defined(CONFIG_FB_OMAP2)
|
||||
static struct platform_device omap_display_device = {
|
||||
.name = "omapdss",
|
||||
.id = -1,
|
||||
|
|
@ -163,6 +164,65 @@ static enum omapdss_version __init omap_display_get_version(void)
|
|||
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)
|
||||
{
|
||||
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 r;
|
||||
enum omapdss_version ver;
|
||||
struct device_node *node;
|
||||
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 */
|
||||
|
||||
node = omapdss_find_dss_of_node();
|
||||
|
|
@ -354,13 +407,6 @@ int __init omapdss_init_of(void)
|
|||
if (!of_device_is_available(node))
|
||||
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);
|
||||
|
||||
if (!pdev) {
|
||||
|
|
@ -374,48 +420,5 @@ int __init omapdss_init_of(void)
|
|||
return r;
|
||||
}
|
||||
|
||||
board_data.version = ver;
|
||||
|
||||
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;
|
||||
return omapdss_init_fbdev();
|
||||
}
|
||||
|
|
|
|||
|
|
@ -26,7 +26,6 @@ struct omap_dss_dispc_dev_attr {
|
|||
bool has_framedonetv_irq;
|
||||
};
|
||||
|
||||
int omap_init_drm(void);
|
||||
int omap_init_vrfb(void);
|
||||
int omap_init_fb(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)
|
||||
{
|
||||
omap2_common_pm_late_init();
|
||||
omap_soc_device_init();
|
||||
}
|
||||
|
||||
#ifdef CONFIG_SOC_OMAP2420
|
||||
|
|
|
|||
|
|
@ -51,7 +51,6 @@
|
|||
compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&i2c1_pins>;
|
||||
|
|
@ -86,13 +77,6 @@
|
|||
bias-pull-up;
|
||||
};
|
||||
|
||||
&mdio {
|
||||
ext_rgmii_phy: ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc0_pins>;
|
||||
|
|
|
|||
|
|
@ -48,18 +48,3 @@
|
|||
|
||||
/* 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";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
serial1 = &uart1;
|
||||
serial2 = &uart2;
|
||||
|
|
@ -79,15 +78,6 @@
|
|||
status = "okay";
|
||||
};
|
||||
|
||||
&emac {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&rmii_pins>;
|
||||
phy-mode = "rmii";
|
||||
phy-handle = <&ext_rmii_phy1>;
|
||||
status = "okay";
|
||||
|
||||
};
|
||||
|
||||
&i2c1 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&i2c1_pins>;
|
||||
|
|
@ -98,13 +88,6 @@
|
|||
bias-pull-up;
|
||||
};
|
||||
|
||||
&mdio {
|
||||
ext_rmii_phy1: ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc0_pins>;
|
||||
|
|
|
|||
|
|
@ -53,7 +53,6 @@
|
|||
"allwinner,sun50i-a64";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
};
|
||||
|
||||
|
|
@ -77,21 +76,6 @@
|
|||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc2_pins>;
|
||||
|
|
|
|||
|
|
@ -449,26 +449,6 @@
|
|||
#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 {
|
||||
compatible = "arm,gic-400";
|
||||
reg = <0x01c81000 0x1000>,
|
||||
|
|
|
|||
|
|
@ -50,7 +50,6 @@
|
|||
compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
};
|
||||
|
||||
|
|
@ -109,22 +108,6 @@
|
|||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||
|
|
|
|||
|
|
@ -59,7 +59,6 @@
|
|||
};
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
};
|
||||
|
||||
|
|
@ -137,28 +136,12 @@
|
|||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ir_pins_a>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&mdio {
|
||||
ext_rgmii_phy: ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
|
||||
|
|
|
|||
|
|
@ -54,7 +54,6 @@
|
|||
compatible = "xunlong,orangepi-prime", "allwinner,sun50i-h5";
|
||||
|
||||
aliases {
|
||||
ethernet0 = &emac;
|
||||
serial0 = &uart0;
|
||||
};
|
||||
|
||||
|
|
@ -144,28 +143,12 @@
|
|||
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 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ir_pins_a>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&mdio {
|
||||
ext_rgmii_phy: ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-ieee802.3-c22";
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
&mmc0 {
|
||||
pinctrl-names = "default";
|
||||
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