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 'x86/trampoline' into x86/urgent
x86/trampoline contains an urgent commit which is necessarily on a newer baseline. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This commit is contained in:
H. Peter Anvin
@@ -0,0 +1,15 @@
|
||||
What: /sys/bus/i2c/devices/.../output_hvled[n]
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the controlling backlight device for high-voltage current
|
||||
sink HVLED[n] (n = 1, 2) (0, 1).
|
||||
|
||||
What: /sys/bus/i2c/devices/.../output_lvled[n]
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the controlling led device for low-voltage current sink
|
||||
LVLED[n] (n = 1..5) (0..3).
|
||||
@@ -0,0 +1,48 @@
|
||||
What: /sys/class/backlight/<backlight>/als_channel
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Get the ALS output channel used as input in
|
||||
ALS-current-control mode (0, 1), where
|
||||
|
||||
0 - out_current0 (backlight 0)
|
||||
1 - out_current1 (backlight 1)
|
||||
|
||||
What: /sys/class/backlight/<backlight>/als_en
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Enable ALS-current-control mode (0, 1).
|
||||
|
||||
What: /sys/class/backlight/<backlight>/id
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Get the id of this backlight (0, 1).
|
||||
|
||||
What: /sys/class/backlight/<backlight>/linear
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the brightness-mapping mode (0, 1), where
|
||||
|
||||
0 - exponential mode
|
||||
1 - linear mode
|
||||
|
||||
What: /sys/class/backlight/<backlight>/pwm
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the PWM-input control mask (5 bits), where
|
||||
|
||||
bit 5 - PWM-input enabled in Zone 4
|
||||
bit 4 - PWM-input enabled in Zone 3
|
||||
bit 3 - PWM-input enabled in Zone 2
|
||||
bit 2 - PWM-input enabled in Zone 1
|
||||
bit 1 - PWM-input enabled in Zone 0
|
||||
bit 0 - PWM-input enabled
|
||||
@@ -0,0 +1,65 @@
|
||||
What: /sys/class/leds/<led>/als_channel
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the ALS output channel to use as input in
|
||||
ALS-current-control mode (1, 2), where
|
||||
|
||||
1 - out_current1
|
||||
2 - out_current2
|
||||
|
||||
What: /sys/class/leds/<led>/als_en
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Enable ALS-current-control mode (0, 1).
|
||||
|
||||
What: /sys/class/leds/<led>/falltime
|
||||
What: /sys/class/leds/<led>/risetime
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the pattern generator fall and rise times (0..7), where
|
||||
|
||||
0 - 2048 us
|
||||
1 - 262 ms
|
||||
2 - 524 ms
|
||||
3 - 1.049 s
|
||||
4 - 2.097 s
|
||||
5 - 4.194 s
|
||||
6 - 8.389 s
|
||||
7 - 16.78 s
|
||||
|
||||
What: /sys/class/leds/<led>/id
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Get the id of this led (0..3).
|
||||
|
||||
What: /sys/class/leds/<led>/linear
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the brightness-mapping mode (0, 1), where
|
||||
|
||||
0 - exponential mode
|
||||
1 - linear mode
|
||||
|
||||
What: /sys/class/leds/<led>/pwm
|
||||
Date: April 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Johan Hovold <jhovold@gmail.com>
|
||||
Description:
|
||||
Set the PWM-input control mask (5 bits), where
|
||||
|
||||
bit 5 - PWM-input enabled in Zone 4
|
||||
bit 4 - PWM-input enabled in Zone 3
|
||||
bit 3 - PWM-input enabled in Zone 2
|
||||
bit 2 - PWM-input enabled in Zone 1
|
||||
bit 1 - PWM-input enabled in Zone 0
|
||||
bit 0 - PWM-input enabled
|
||||
@@ -150,7 +150,8 @@ be able to justify all violations that remain in your patch.
|
||||
|
||||
Look through the MAINTAINERS file and the source code, and determine
|
||||
if your change applies to a specific subsystem of the kernel, with
|
||||
an assigned maintainer. If so, e-mail that person.
|
||||
an assigned maintainer. If so, e-mail that person. The script
|
||||
scripts/get_maintainer.pl can be very useful at this step.
|
||||
|
||||
If no maintainer is listed, or the maintainer does not respond, send
|
||||
your patch to the primary Linux kernel developer's mailing list,
|
||||
|
||||
@@ -8,9 +8,8 @@ Introduction
|
||||
weblink : http://www.st.com/spear
|
||||
|
||||
The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are
|
||||
supported by the 'spear' platform of ARM Linux. Currently SPEAr300,
|
||||
SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Support for the SPEAr13XX
|
||||
series is in progress.
|
||||
supported by the 'spear' platform of ARM Linux. Currently SPEAr1310,
|
||||
SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported.
|
||||
|
||||
Hierarchy in SPEAr is as follows:
|
||||
|
||||
@@ -26,33 +25,36 @@ Introduction
|
||||
- SPEAr600 (SOC)
|
||||
- SPEAr600 Evaluation Board
|
||||
- SPEAr13XX (13XX SOC series, based on ARM CORTEXA9)
|
||||
- SPEAr1300 (SOC)
|
||||
- SPEAr1310 (SOC)
|
||||
- SPEAr1310 Evaluation Board
|
||||
- SPEAr1340 (SOC)
|
||||
- SPEAr1340 Evaluation Board
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
A generic configuration is provided for each machine, and can be used as the
|
||||
default by
|
||||
make spear600_defconfig
|
||||
make spear300_defconfig
|
||||
make spear310_defconfig
|
||||
make spear320_defconfig
|
||||
make spear13xx_defconfig
|
||||
make spear3xx_defconfig
|
||||
make spear6xx_defconfig
|
||||
|
||||
Layout
|
||||
------
|
||||
|
||||
The common files for multiple machine families (SPEAr3XX, SPEAr6XX and
|
||||
SPEAr13XX) are located in the platform code contained in arch/arm/plat-spear
|
||||
The common files for multiple machine families (SPEAr3xx, SPEAr6xx and
|
||||
SPEAr13xx) are located in the platform code contained in arch/arm/plat-spear
|
||||
with headers in plat/.
|
||||
|
||||
Each machine series have a directory with name arch/arm/mach-spear followed by
|
||||
series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx.
|
||||
|
||||
Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c and for
|
||||
spear6xx is mach-spear6xx/spear6xx.c. mach-spear* also contain soc/machine
|
||||
specific files, like spear300.c, spear310.c, spear320.c and spear600.c.
|
||||
mach-spear* doesn't contains board specific files as they fully support
|
||||
Flattened Device Tree.
|
||||
Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c, for
|
||||
spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is
|
||||
mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific
|
||||
files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and
|
||||
spear600.c. mach-spear* doesn't contains board specific files as they fully
|
||||
support Flattened Device Tree.
|
||||
|
||||
|
||||
Document Author
|
||||
|
||||
@@ -184,12 +184,14 @@ behind this approach is that a cgroup that aggressively uses a shared
|
||||
page will eventually get charged for it (once it is uncharged from
|
||||
the cgroup that brought it in -- this will happen on memory pressure).
|
||||
|
||||
But see section 8.2: when moving a task to another cgroup, its pages may
|
||||
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
|
||||
|
||||
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
|
||||
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
|
||||
be backed into memory in force, charges for pages are accounted against the
|
||||
caller of swapoff rather than the users of shmem.
|
||||
|
||||
|
||||
2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP)
|
||||
|
||||
Swap Extension allows you to record charge for swap. A swapped-in page is
|
||||
@@ -374,14 +376,15 @@ cgroup might have some charge associated with it, even though all
|
||||
tasks have migrated away from it. (because we charge against pages, not
|
||||
against tasks.)
|
||||
|
||||
Such charges are freed or moved to their parent. At moving, both of RSS
|
||||
and CACHES are moved to parent.
|
||||
rmdir() may return -EBUSY if freeing/moving fails. See 5.1 also.
|
||||
We move the stats to root (if use_hierarchy==0) or parent (if
|
||||
use_hierarchy==1), and no change on the charge except uncharging
|
||||
from the child.
|
||||
|
||||
Charges recorded in swap information is not updated at removal of cgroup.
|
||||
Recorded information is discarded and a cgroup which uses swap (swapcache)
|
||||
will be charged as a new owner of it.
|
||||
|
||||
About use_hierarchy, see Section 6.
|
||||
|
||||
5. Misc. interfaces.
|
||||
|
||||
@@ -394,13 +397,15 @@ will be charged as a new owner of it.
|
||||
|
||||
Almost all pages tracked by this memory cgroup will be unmapped and freed.
|
||||
Some pages cannot be freed because they are locked or in-use. Such pages are
|
||||
moved to parent and this cgroup will be empty. This may return -EBUSY if
|
||||
VM is too busy to free/move all pages immediately.
|
||||
moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this
|
||||
cgroup will be empty.
|
||||
|
||||
Typical use case of this interface is that calling this before rmdir().
|
||||
Because rmdir() moves all pages to parent, some out-of-use page caches can be
|
||||
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||
|
||||
About use_hierarchy, see Section 6.
|
||||
|
||||
5.2 stat file
|
||||
|
||||
memory.stat file includes following statistics
|
||||
@@ -430,17 +435,10 @@ hierarchical_memory_limit - # of bytes of memory limit with regard to hierarchy
|
||||
hierarchical_memsw_limit - # of bytes of memory+swap limit with regard to
|
||||
hierarchy under which memory cgroup is.
|
||||
|
||||
total_cache - sum of all children's "cache"
|
||||
total_rss - sum of all children's "rss"
|
||||
total_mapped_file - sum of all children's "cache"
|
||||
total_pgpgin - sum of all children's "pgpgin"
|
||||
total_pgpgout - sum of all children's "pgpgout"
|
||||
total_swap - sum of all children's "swap"
|
||||
total_inactive_anon - sum of all children's "inactive_anon"
|
||||
total_active_anon - sum of all children's "active_anon"
|
||||
total_inactive_file - sum of all children's "inactive_file"
|
||||
total_active_file - sum of all children's "active_file"
|
||||
total_unevictable - sum of all children's "unevictable"
|
||||
total_<counter> - # hierarchical version of <counter>, which in
|
||||
addition to the cgroup's own value includes the
|
||||
sum of all hierarchical children's values of
|
||||
<counter>, i.e. total_cache
|
||||
|
||||
# The following additional stats are dependent on CONFIG_DEBUG_VM.
|
||||
|
||||
@@ -622,8 +620,7 @@ memory cgroup.
|
||||
bit | what type of charges would be moved ?
|
||||
-----+------------------------------------------------------------------------
|
||||
0 | A charge of an anonymous page(or swap of it) used by the target task.
|
||||
| Those pages and swaps must be used only by the target task. You must
|
||||
| enable Swap Extension(see 2.4) to enable move of swap charges.
|
||||
| You must enable Swap Extension(see 2.4) to enable move of swap charges.
|
||||
-----+------------------------------------------------------------------------
|
||||
1 | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory)
|
||||
| and swaps of tmpfs file) mmapped by the target task. Unlike the case of
|
||||
@@ -636,8 +633,6 @@ memory cgroup.
|
||||
|
||||
8.3 TODO
|
||||
|
||||
- Implement madvise(2) to let users decide the vma to be moved or not to be
|
||||
moved.
|
||||
- All of moving charge operations are done under cgroup_mutex. It's not good
|
||||
behavior to hold the mutex too long, so we may need some trick.
|
||||
|
||||
|
||||
@@ -92,6 +92,14 @@ to work with it.
|
||||
|
||||
The _locked routines imply that the res_counter->lock is taken.
|
||||
|
||||
f. void res_counter_uncharge_until
|
||||
(struct res_counter *rc, struct res_counter *top,
|
||||
unsinged long val)
|
||||
|
||||
Almost same as res_cunter_uncharge() but propagation of uncharge
|
||||
stops when rc == top. This is useful when kill a res_coutner in
|
||||
child cgroup.
|
||||
|
||||
2.1 Other accounting routines
|
||||
|
||||
There are more routines that may help you with common needs, like
|
||||
|
||||
+31
-31
@@ -1,38 +1,34 @@
|
||||
Linux 2.4 on the CRIS architecture
|
||||
==================================
|
||||
$Id: README,v 1.7 2001/04/19 12:38:32 bjornw Exp $
|
||||
Linux on the CRIS architecture
|
||||
==============================
|
||||
|
||||
This is a port of Linux 2.4 to Axis Communications ETRAX 100LX embedded
|
||||
network CPU. For more information about CRIS and ETRAX please see further
|
||||
below.
|
||||
This is a port of Linux to Axis Communications ETRAX 100LX,
|
||||
ETRAX FS and ARTPEC-3 embedded network CPUs.
|
||||
|
||||
For more information about CRIS and ETRAX please see further below.
|
||||
|
||||
In order to compile this you need a version of gcc with support for the
|
||||
ETRAX chip family. Please see this link for more information on how to
|
||||
ETRAX chip family. Please see this link for more information on how to
|
||||
download the compiler and other tools useful when building and booting
|
||||
software for the ETRAX platform:
|
||||
|
||||
http://developer.axis.com/doc/software/devboard_lx/install-howto.html
|
||||
|
||||
<more specific information should come in this document later>
|
||||
http://developer.axis.com/wiki/doku.php?id=axis:install-howto-2_20
|
||||
|
||||
What is CRIS ?
|
||||
--------------
|
||||
|
||||
CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU
|
||||
architecture in Axis Communication AB's range of embedded network CPU's,
|
||||
called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for
|
||||
'Linux' because the chip was designed to be a good host for the Linux
|
||||
operating system.
|
||||
called ETRAX.
|
||||
|
||||
The ETRAX 100LX chip
|
||||
--------------------
|
||||
|
||||
For reference, please see the press-release:
|
||||
For reference, please see the following link:
|
||||
|
||||
http://www.axis.com/news/us/001101_etrax.htm
|
||||
http://www.axis.com/products/dev_etrax_100lx/index.htm
|
||||
|
||||
The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad
|
||||
range of built-in interfaces, all with modern scatter/gather DMA.
|
||||
The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad
|
||||
range of built-in interfaces, all with modern scatter/gather DMA.
|
||||
|
||||
Memory interfaces:
|
||||
|
||||
@@ -51,20 +47,28 @@ I/O interfaces:
|
||||
* SCSI
|
||||
* two parallel-ports
|
||||
* two generic 8-bit ports
|
||||
|
||||
(not all interfaces are available at the same time due to chip pin
|
||||
|
||||
(not all interfaces are available at the same time due to chip pin
|
||||
multiplexing)
|
||||
|
||||
The previous version of the ETRAX, the ETRAX 100, sits in almost all of
|
||||
Axis shipping thin-servers like the Axis 2100 web camera or the ETRAX 100
|
||||
developer-board. It lacks an MMU so the Linux we run on that is a version
|
||||
of uClinux (Linux 2.0 without MM-support) ported to the CRIS architecture.
|
||||
The new Linux 2.4 port has full MM and needs a CPU with an MMU, so it will
|
||||
not run on the ETRAX 100.
|
||||
ETRAX 100LX is CRISv10 architecture.
|
||||
|
||||
A version of the Axis developer-board with ETRAX 100LX (running Linux
|
||||
2.4) is now available. For more information please see developer.axis.com.
|
||||
|
||||
The ETRAX FS and ARTPEC-3 chips
|
||||
-------------------------------
|
||||
|
||||
The ETRAX FS is a 200MHz 32-bit RISC processor with on-chip 16kB
|
||||
I-cache and 16kB D-cache and with a wide range of device interfaces
|
||||
including multiple high speed serial ports and an integrated USB 1.1 PHY.
|
||||
|
||||
The ARTPEC-3 is a variant of the ETRAX FS with additional IO-units
|
||||
used by the Axis Communications network cameras.
|
||||
|
||||
See below link for more information:
|
||||
|
||||
http://www.axis.com/products/dev_etrax_fs/index.htm
|
||||
|
||||
ETRAX FS and ARTPEC-3 are both CRISv32 architectures.
|
||||
|
||||
Bootlog
|
||||
-------
|
||||
@@ -182,10 +186,6 @@ SwapFree: 0 kB
|
||||
-rwxr-xr-x 1 342 100 16252 Jan 01 00:00 telnetd
|
||||
|
||||
|
||||
(All programs are statically linked to the libc at this point - we have not ported the
|
||||
shared libraries yet)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1,14 @@
|
||||
Freescale i.MX Platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
|
||||
i.MX23 Evaluation Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx23-evk", "fsl,imx23";
|
||||
|
||||
i.MX28 Evaluation Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx28-evk", "fsl,imx28";
|
||||
|
||||
i.MX51 Babbage Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx51-babbage", "fsl,imx51";
|
||||
@@ -29,6 +37,10 @@ i.MX6 Quad SABRE Lite Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
|
||||
|
||||
i.MX6 Quad SABRE Smart Device Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
|
||||
|
||||
Generic i.MX boards
|
||||
-------------------
|
||||
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
* Samsung Exynos Interrupt Combiner Controller
|
||||
|
||||
Samsung's Exynos4 architecture includes a interrupt combiner controller which
|
||||
can combine interrupt sources as a group and provide a single interrupt request
|
||||
for the group. The interrupt request from each group are connected to a parent
|
||||
interrupt controller, such as GIC in case of Exynos4210.
|
||||
|
||||
The interrupt combiner controller consists of multiple combiners. Upto eight
|
||||
interrupt sources can be connected to a combiner. The combiner outputs one
|
||||
combined interrupt for its eight interrupt sources. The combined interrupt
|
||||
is usually connected to a parent interrupt controller.
|
||||
|
||||
A single node in the device tree is used to describe the interrupt combiner
|
||||
controller module (which includes multiple combiners). A combiner in the
|
||||
interrupt controller module shares config/control registers with other
|
||||
combiners. For example, a 32-bit interrupt enable/disable config register
|
||||
can accommodate upto 4 interrupt combiners (with each combiner supporting
|
||||
upto 8 interrupt sources).
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "samsung,exynos4210-combiner".
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: should be <2>. The meaning of the cells are
|
||||
* First Cell: Combiner Group Number.
|
||||
* Second Cell: Interrupt number within the group.
|
||||
- reg: Base address and size of interrupt combiner registers.
|
||||
- interrupts: The list of interrupts generated by the combiners which are then
|
||||
connected to a parent interrupt controller. The format of the interrupt
|
||||
specifier depends in the interrupt parent controller.
|
||||
|
||||
Optional properties:
|
||||
- samsung,combiner-nr: The number of interrupt combiners supported. If this
|
||||
property is not specified, the default number of combiners is assumed
|
||||
to be 16.
|
||||
- interrupt-parent: pHandle of the parent interrupt controller, if not
|
||||
inherited from the parent node.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
The following is a an example from the Exynos4210 SoC dtsi file.
|
||||
|
||||
combiner:interrupt-controller@10440000 {
|
||||
compatible = "samsung,exynos4210-combiner";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
reg = <0x10440000 0x1000>;
|
||||
interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
|
||||
<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
|
||||
<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
|
||||
<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
|
||||
};
|
||||
@@ -0,0 +1,18 @@
|
||||
* SPEAr ARM Timer
|
||||
|
||||
** Timer node required properties:
|
||||
|
||||
- compatible : Should be:
|
||||
"st,spear-timer"
|
||||
- reg: Address range of the timer registers
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupt: Should contain the timer interrupt number
|
||||
|
||||
Example:
|
||||
|
||||
timer@f0000000 {
|
||||
compatible = "st,spear-timer";
|
||||
reg = <0xf0000000 0x400>;
|
||||
interrupts = <2>;
|
||||
};
|
||||
@@ -2,25 +2,25 @@ ST SPEAr Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the ST SPEAr600 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "st,spear600";
|
||||
|
||||
Boards with the ST SPEAr300 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "st,spear300";
|
||||
|
||||
Boards with the ST SPEAr310 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "st,spear310";
|
||||
|
||||
Boards with the ST SPEAr320 SoC shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "st,spear320";
|
||||
|
||||
Boards with the ST SPEAr1310 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear1310";
|
||||
|
||||
Boards with the ST SPEAr1340 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear1340";
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
NVIDIA Tegra AHB
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
|
||||
Example:
|
||||
ahb: ahb@6000c004 {
|
||||
compatible = "nvidia,tegra20-ahb";
|
||||
reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */
|
||||
};
|
||||
@@ -0,0 +1,19 @@
|
||||
* Freescale MXS DMA
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx"
|
||||
- reg : Should contain registers location and length
|
||||
|
||||
Supported chips:
|
||||
imx23, imx28.
|
||||
|
||||
Examples:
|
||||
dma-apbh@80004000 {
|
||||
compatible = "fsl,imx28-dma-apbh";
|
||||
reg = <0x80004000 2000>;
|
||||
};
|
||||
|
||||
dma-apbx@80024000 {
|
||||
compatible = "fsl,imx28-dma-apbx";
|
||||
reg = <0x80024000 2000>;
|
||||
};
|
||||
@@ -0,0 +1,17 @@
|
||||
* Synopsys Designware DMA Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "snps,dma-spear1340"
|
||||
- reg: Address range of the DMAC registers
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller
|
||||
that services interrupts for this device
|
||||
- interrupt: Should contain the DMAC interrupt number
|
||||
|
||||
Example:
|
||||
|
||||
dma@fc000000 {
|
||||
compatible = "snps,dma-spear1340";
|
||||
reg = <0xfc000000 0x1000>;
|
||||
interrupt-parent = <&vic1>;
|
||||
interrupts = <12>;
|
||||
};
|
||||
@@ -0,0 +1,38 @@
|
||||
Lantiq SoC External Bus memory mapped GPIO controller
|
||||
|
||||
By attaching hardware latches to the EBU it is possible to create output
|
||||
only gpios. This driver configures a special memory address, which when
|
||||
written to outputs 16 bit to the latches.
|
||||
|
||||
The node describing the memory mapped GPIOs needs to be a child of the node
|
||||
describing the "lantiq,localbus".
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "lantiq,gpio-mm-lantiq"
|
||||
- reg : Address and length of the register set for the device
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
|
||||
Optional properties:
|
||||
- lantiq,shadow : The default value that we shall assume as already set on the
|
||||
shift register cascade.
|
||||
|
||||
Example:
|
||||
|
||||
localbus@0 {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0 0x0 0x3ffffff /* addrsel0 */
|
||||
1 0 0x4000000 0x4000010>; /* addsel1 */
|
||||
compatible = "lantiq,localbus", "simple-bus";
|
||||
|
||||
gpio_mm0: gpio@4000000 {
|
||||
compatible = "lantiq,gpio-mm";
|
||||
reg = <1 0x0 0x10>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
lantiq,shadow = <0x77f>
|
||||
};
|
||||
}
|
||||
@@ -0,0 +1,87 @@
|
||||
* Freescale MXS GPIO controller
|
||||
|
||||
The Freescale MXS GPIO controller is part of MXS PIN controller. The
|
||||
GPIOs are organized in port/bank. Each port consists of 32 GPIOs.
|
||||
|
||||
As the GPIO controller is embedded in the PIN controller and all the
|
||||
GPIO ports share the same IO space with PIN controller, the GPIO node
|
||||
will be represented as sub-nodes of MXS pinctrl node.
|
||||
|
||||
Required properties for GPIO node:
|
||||
- compatible : Should be "fsl,<soc>-gpio". The supported SoCs include
|
||||
imx23 and imx28.
|
||||
- interrupts : Should be the port interrupt shared by all 32 pins.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
- interrupt-controller: Marks the device node as an interrupt controller.
|
||||
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
|
||||
The second cell bits[3:0] is used to specify trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
|
||||
Note: Each GPIO port should have an alias correctly numbered in "aliases"
|
||||
node.
|
||||
|
||||
Examples:
|
||||
|
||||
aliases {
|
||||
gpio0 = &gpio0;
|
||||
gpio1 = &gpio1;
|
||||
gpio2 = &gpio2;
|
||||
gpio3 = &gpio3;
|
||||
gpio4 = &gpio4;
|
||||
};
|
||||
|
||||
pinctrl@80018000 {
|
||||
compatible = "fsl,imx28-pinctrl", "simple-bus";
|
||||
reg = <0x80018000 2000>;
|
||||
|
||||
gpio0: gpio@0 {
|
||||
compatible = "fsl,imx28-gpio";
|
||||
interrupts = <127>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
gpio1: gpio@1 {
|
||||
compatible = "fsl,imx28-gpio";
|
||||
interrupts = <126>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
gpio2: gpio@2 {
|
||||
compatible = "fsl,imx28-gpio";
|
||||
interrupts = <125>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
gpio3: gpio@3 {
|
||||
compatible = "fsl,imx28-gpio";
|
||||
interrupts = <124>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
gpio4: gpio@4 {
|
||||
compatible = "fsl,imx28-gpio";
|
||||
interrupts = <123>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,42 @@
|
||||
Lantiq SoC Serial To Parallel (STP) GPIO controller
|
||||
|
||||
The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a
|
||||
peripheral controller used to drive external shift register cascades. At most
|
||||
3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem
|
||||
to drive the 2 LSBs of the cascade automatically.
|
||||
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "lantiq,gpio-stp-xway"
|
||||
- reg : Address and length of the register set for the device
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
|
||||
Optional properties:
|
||||
- lantiq,shadow : The default value that we shall assume as already set on the
|
||||
shift register cascade.
|
||||
- lantiq,groups : Set the 3 bit mask to select which of the 3 groups are enabled
|
||||
in the shift register cascade.
|
||||
- lantiq,dsl : The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit
|
||||
property can enable this feature.
|
||||
- lantiq,phy1 : The gphy1 core can control 3 bits of the gpio cascade.
|
||||
- lantiq,phy2 : The gphy2 core can control 3 bits of the gpio cascade.
|
||||
- lantiq,rising : use rising instead of falling edge for the shift register
|
||||
|
||||
Example:
|
||||
|
||||
gpio1: stp@E100BB0 {
|
||||
compatible = "lantiq,gpio-stp-xway";
|
||||
reg = <0xE100BB0 0x40>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
|
||||
lantiq,shadow = <0xffff>;
|
||||
lantiq,groups = <0x7>;
|
||||
lantiq,dsl = <0x3>;
|
||||
lantiq,phy1 = <0x7>;
|
||||
lantiq,phy2 = <0x7>;
|
||||
/* lantiq,rising; */
|
||||
};
|
||||
@@ -0,0 +1,16 @@
|
||||
* Freescale MXS Inter IC (I2C) Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,<chip>-i2c"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain ERROR and DMA interrupts
|
||||
|
||||
Examples:
|
||||
|
||||
i2c0: i2c@80058000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "fsl,imx28-i2c";
|
||||
reg = <0x80058000 2000>;
|
||||
interrupts = <111 68>;
|
||||
};
|
||||
@@ -0,0 +1,60 @@
|
||||
Common i2c bus multiplexer/switch properties.
|
||||
|
||||
An i2c bus multiplexer/switch will have several child busses that are
|
||||
numbered uniquely in a device dependent manner. The nodes for an i2c bus
|
||||
multiplexer/switch will have one child node for each child
|
||||
bus.
|
||||
|
||||
Required properties:
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
|
||||
Required properties for child nodes:
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
- reg : The sub-bus number.
|
||||
|
||||
Optional properties for child nodes:
|
||||
- Other properties specific to the multiplexer/switch hardware.
|
||||
- Child nodes conforming to i2c bus binding
|
||||
|
||||
|
||||
Example :
|
||||
|
||||
/*
|
||||
An NXP pca9548 8 channel I2C multiplexer at address 0x70
|
||||
with two NXP pca8574 GPIO expanders attached, one each to
|
||||
ports 3 and 4.
|
||||
*/
|
||||
|
||||
mux@70 {
|
||||
compatible = "nxp,pca9548";
|
||||
reg = <0x70>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
i2c@3 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <3>;
|
||||
|
||||
gpio1: gpio@38 {
|
||||
compatible = "nxp,pca8574";
|
||||
reg = <0x38>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
};
|
||||
};
|
||||
i2c@4 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <4>;
|
||||
|
||||
gpio2: gpio@38 {
|
||||
compatible = "nxp,pca8574";
|
||||
reg = <0x38>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
};
|
||||
};
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user