You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'linus' into locking/core, to fix up conflicts
Conflicts: mm/page_alloc.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
+2
-10
@@ -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
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user