diff options
Diffstat (limited to 'Documentation')
45 files changed, 876 insertions, 472 deletions
diff --git a/Documentation/Makefile b/Documentation/Makefile index 6883a1b9b351..bc0548201755 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,4 +1,4 @@ -subdir-y := accounting arm auxdisplay blackfin connector \ +subdir-y := accounting auxdisplay blackfin connector \ filesystems filesystems ia64 laptops mic misc-devices \ networking pcmcia prctl ptp spi timers vDSO video4linux \ watchdog diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index 8edb9007844e..dea011c8d7c7 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -10,8 +10,6 @@ IXP4xx - Intel IXP4xx Network processor. Makefile - Build sourcefiles as part of the Documentation-build for arm -msm/ - - MSM specific documentation Netwinder - Netwinder specific documentation Porting diff --git a/Documentation/arm/Makefile b/Documentation/arm/Makefile deleted file mode 100644 index 732c77050cff..000000000000 --- a/Documentation/arm/Makefile +++ /dev/null @@ -1 +0,0 @@ -subdir-y := SH-Mobile diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README index 17453794fca5..18a775d10172 100644 --- a/Documentation/arm/Marvell/README +++ b/Documentation/arm/Marvell/README @@ -96,6 +96,11 @@ EBU Armada family 88F6820 88F6828 + Armada 390/398 Flavors: + 88F6920 + 88F6928 + Product infos: http://www.marvell.com/embedded-processors/armada-39x/ + Armada XP Flavors: MV78230 MV78260 diff --git a/Documentation/arm/SH-Mobile/Makefile b/Documentation/arm/SH-Mobile/Makefile deleted file mode 100644 index bca8a7ef6bbe..000000000000 --- a/Documentation/arm/SH-Mobile/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# List of programs to build -hostprogs-y := vrl4 - -# Tell kbuild to always build the programs -always := $(hostprogs-y) - -HOSTCFLAGS_vrl4.o += -I$(objtree)/usr/include -I$(srctree)/tools/include diff --git a/Documentation/arm/SH-Mobile/vrl4.c b/Documentation/arm/SH-Mobile/vrl4.c deleted file mode 100644 index f4cd8ad4e720..000000000000 --- a/Documentation/arm/SH-Mobile/vrl4.c +++ /dev/null @@ -1,170 +0,0 @@ -/* - * vrl4 format generator - * - * Copyright (C) 2010 Simon Horman - * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - */ - -/* - * usage: vrl4 < zImage > out - * dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1 - * - * Reads a zImage from stdin and writes a vrl4 image to stdout. - * In practice this means writing a padded vrl4 header to stdout followed - * by the zImage. - * - * The padding places the zImage at ALIGN bytes into the output. - * The vrl4 uses ALIGN + START_BASE as the start_address. - * This is where the mask ROM will jump to after verifying the header. - * - * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN. - * That is, the mask ROM will load the padded header (ALIGN bytes) - * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image, - * whichever is smaller. - * - * The zImage is not modified in any way. - */ - -#define _BSD_SOURCE -#include <endian.h> -#include <unistd.h> -#include <stdint.h> -#include <stdio.h> -#include <errno.h> -#include <tools/endian.h> - -struct hdr { - uint32_t magic1; - uint32_t reserved1; - uint32_t magic2; - uint32_t reserved2; - uint16_t copy_size; - uint16_t boot_options; - uint32_t reserved3; - uint32_t start_address; - uint32_t reserved4; - uint32_t reserved5; - char reserved6[308]; -}; - -#define DECLARE_HDR(h) \ - struct hdr (h) = { \ - .magic1 = htole32(0xea000000), \ - .reserved1 = htole32(0x56), \ - .magic2 = htole32(0xe59ff008), \ - .reserved3 = htole16(0x1) } - -/* Align to 512 bytes, the MMCIF sector size */ -#define ALIGN_BITS 9 -#define ALIGN (1 << ALIGN_BITS) - -#define START_BASE 0xe55b0000 - -/* - * With an alignment of 512 the header uses the first sector. - * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM. - * So there are 127 sectors left for the boot programme. But in practice - * Only a small portion of a zImage is needed, 16 sectors should be more - * than enough. - * - * Note that this sets how much of the zImage is copied by the mask ROM. - * The entire zImage is present after the header and is loaded - * by the code in the boot program (which is the first portion of the zImage). - */ -#define MAX_BOOT_PROG_LEN (16 * 512) - -#define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1)) - -static ssize_t do_read(int fd, void *buf, size_t count) -{ - size_t offset = 0; - ssize_t l; - - while (offset < count) { - l = read(fd, buf + offset, count - offset); - if (!l) - break; - if (l < 0) { - if (errno == EAGAIN || errno == EWOULDBLOCK) - continue; - perror("read"); - return -1; - } - offset += l; - } - - return offset; -} - -static ssize_t do_write(int fd, const void *buf, size_t count) -{ - size_t offset = 0; - ssize_t l; - - while (offset < count) { - l = write(fd, buf + offset, count - offset); - if (l < 0) { - if (errno == EAGAIN || errno == EWOULDBLOCK) - continue; - perror("write"); - return -1; - } - offset += l; - } - - return offset; -} - -static ssize_t write_zero(int fd, size_t len) -{ - size_t i = len; - - while (i--) { - const char x = 0; - if (do_write(fd, &x, 1) < 0) - return -1; - } - - return len; -} - -int main(void) -{ - DECLARE_HDR(hdr); - char boot_program[MAX_BOOT_PROG_LEN]; - size_t aligned_hdr_len, alligned_prog_len; - ssize_t prog_len; - - prog_len = do_read(0, boot_program, sizeof(boot_program)); - if (prog_len <= 0) - return -1; - - aligned_hdr_len = ROUND_UP(sizeof(hdr)); - hdr.start_address = htole32(START_BASE + aligned_hdr_len); - alligned_prog_len = ROUND_UP(prog_len); - hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len); - - if (do_write(1, &hdr, sizeof(hdr)) < 0) - return -1; - if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0) - return -1; - - if (do_write(1, boot_program, prog_len) < 0) - return 1; - - /* Write out the rest of the kernel */ - while (1) { - prog_len = do_read(0, boot_program, sizeof(boot_program)); - if (prog_len < 0) - return 1; - if (prog_len == 0) - break; - if (do_write(1, boot_program, prog_len) < 0) - return 1; - } - - return 0; -} diff --git a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt deleted file mode 100644 index efff8ae2713d..000000000000 --- a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt +++ /dev/null @@ -1,29 +0,0 @@ -ROM-able zImage boot from MMC ------------------------------ - -An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and -SuperH Mobile ARM will to boot directly from the MMCIF hardware block. - -This is achieved by the mask ROM loading the first portion of the image into -MERAM and then jumping to it. This portion contains loader code which -copies the entire image to SDRAM and jumps to it. From there the zImage -boot code proceeds as normal, uncompressing the image into its final -location and then jumping to it. - -This code has been tested on an AP4EB board using the developer 1A eMMC -boot mode which is configured using the following jumper settings. -The board used for testing required a patched mask ROM in order for -this mode to function. - - 8 7 6 5 4 3 2 1 - x|x|x|x|x| |x| -S4 -+-+-+-+-+-+-+- - | | | | |x| |x on - -The zImage must be written to the MMC card at sector 1 (512 bytes) in -vrl4 format. A utility vrl4 is supplied to accomplish this. - -e.g. - vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1 - -A dual-voltage MMC 4.0 card was used for testing. diff --git a/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt b/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt deleted file mode 100644 index 441959846e1a..000000000000 --- a/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt +++ /dev/null @@ -1,42 +0,0 @@ -ROM-able zImage boot from eSD ------------------------------ - -An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and -SuperH Mobile ARM will to boot directly from the SDHI hardware block. - -This is achieved by the mask ROM loading the first portion of the image into -MERAM and then jumping to it. This portion contains loader code which -copies the entire image to SDRAM and jumps to it. From there the zImage -boot code proceeds as normal, uncompressing the image into its final -location and then jumping to it. - -This code has been tested on an mackerel board using the developer 1A eSD -boot mode which is configured using the following jumper settings. - - 8 7 6 5 4 3 2 1 - x|x|x|x| |x|x| -S4 -+-+-+-+-+-+-+- - | | | |x| | |x on - -The eSD card needs to be present in SDHI slot 1 (CN7). -As such S1 and S33 also need to be configured as per -the notes in arch/arm/mach-shmobile/board-mackerel.c. - -A partial zImage must be written to physical partition #1 (boot) -of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to -accomplish this. - -e.g. - vrl4 < zImage | dd of=/dev/sdX bs=512 count=17 - -A full copy of _the same_ zImage should be written to physical partition #1 -(boot) of the eSD at sector 0. This should _not_ be in vrl4 format. - - vrl4 < zImage | dd of=/dev/sdX bs=512 - -Note: The commands above assume that the physical partition has been -switched. No such facility currently exists in the Linux Kernel. - -Physical partitions are described in the eSD specification. At the time of -writing they are not the same as partitions that are typically configured -using fdisk and visible through /proc/partitions diff --git a/Documentation/arm/msm/gpiomux.txt b/Documentation/arm/msm/gpiomux.txt deleted file mode 100644 index 67a81620adf6..000000000000 --- a/Documentation/arm/msm/gpiomux.txt +++ /dev/null @@ -1,176 +0,0 @@ -This document provides an overview of the msm_gpiomux interface, which -is used to provide gpio pin multiplexing and configuration on mach-msm -targets. - -History -======= - -The first-generation API for gpio configuration & multiplexing on msm -is the function gpio_tlmm_config(). This function has a few notable -shortcomings, which led to its deprecation and replacement by gpiomux: - -The 'disable' parameter: Setting the second parameter to -gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral -processor in charge of the subsystem to perform a look-up into a -low-power table and apply the low-power/sleep setting for the pin. -As the msm family evolved this became problematic. Not all pins -have sleep settings, not all peripheral processors will accept requests -to apply said sleep settings, and not all msm targets have their gpio -subsystems managed by a peripheral processor. In order to get consistent -behavior on all targets, drivers are forced to ignore this parameter, -rendering it useless. - -The 'direction' flag: for all mux-settings other than raw-gpio (0), -the output-enable bit of a gpio is hard-wired to a known -input (usually VDD or ground). For those settings, the direction flag -is meaningless at best, and deceptive at worst. In addition, using the -direction flag to change output-enable (OE) directly can cause trouble in -gpiolib, which has no visibility into gpio direction changes made -in this way. Direction control in gpio mode should be made through gpiolib. - -Key Features of gpiomux -======================= - -- A consistent interface across all generations of msm. Drivers can expect -the same results on every target. -- gpiomux plays nicely with gpiolib. Functions that should belong to gpiolib -are left to gpiolib and not duplicated here. gpiomux is written with the -intent that gpio_chips will call gpiomux reference-counting methods -from their request() and free() hooks, providing full integration. -- Tabular configuration. Instead of having to call gpio_tlmm_config -hundreds of times, gpio configuration is placed in a single table. -- Per-gpio sleep. Each gpio is individually reference counted, allowing only -those lines which are in use to be put in high-power states. -- 0 means 'do nothing': all flags are designed so that the default memset-zero -equates to a sensible default of 'no configuration', preventing users -from having to provide hundreds of 'no-op' configs for unused or -unwanted lines. - -Usage -===== - -To use gpiomux, provide configuration information for relevant gpio lines -in the msm_gpiomux_configs table. Since a 0 equates to "unconfigured", -only those lines to be managed by gpiomux need to be specified. Here -is a completely fictional example: - -struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = { - [12] = { - .active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1, - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, - [34] = { - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, -}; - -To indicate that a gpio is in use, call msm_gpiomux_get() to increase -its reference count. To decrease the reference count, call msm_gpiomux_put(). - -The effect of this configuration is as follows: - -When the system boots, gpios 12 and 34 will be initialized with their -'suspended' configurations. All other gpios, which were left unconfigured, -will not be touched. - -When msm_gpiomux_get() is called on gpio 12 to raise its reference count -above 0, its active configuration will be applied. Since no other gpio -line has a valid active configuration, msm_gpiomux_get() will have no -effect on any other line. - -When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference -count to 0, their suspended configurations will be applied. -Since no other gpio line has a valid suspended configuration, no other -gpio line will be effected by msm_gpiomux_put(). Since gpio 34 has no valid -active configuration, this is effectively a no-op for gpio 34 as well, -with one small caveat, see the section "About Output-Enable Settings". - -All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but -they address some important issues. As unused entries (all those -except 12 and 34) are zero-filled, gpiomux needs a way to distinguish -the used fields from the unused. In addition, the all-zero pattern -is a valid configuration! Therefore, gpiomux defines an additional bit -which is used to indicate when a field is used. This has the pleasant -side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate -that a value should not be changed: - - msm_gpiomux_write(0, GPIOMUX_VALID, 0); - -replaces the active configuration of gpio 0 with an all-zero configuration, -but leaves the suspended configuration as it was. - -Static Configurations -===================== - -To install a static configuration, which is applied at boot and does -not change after that, install a configuration with a suspended component -but no active component, as in the previous example: - - [34] = { - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, - -The suspended setting is applied during boot, and the lack of any valid -active setting prevents any other setting from being applied at runtime. -If other subsystems attempting to access the line is a concern, one could -*really* anchor the configuration down by calling msm_gpiomux_get on the -line at initialization to move the line into active mode. With the line -held, it will never be re-suspended, and with no valid active configuration, -no new configurations will be applied. - -But then, if having other subsystems grabbing for the line is truly a concern, -it should be reserved with gpio_request instead, which carries an implicit -msm_gpiomux_get. - -gpiomux and gpiolib -=================== - -It is expected that msm gpio_chips will call msm_gpiomux_get() and -msm_gpiomux_put() from their request and free hooks, like this fictional -example: - -static int request(struct gpio_chip *chip, unsigned offset) -{ - return msm_gpiomux_get(chip->base + offset); -} - -static void free(struct gpio_chip *chip, unsigned offset) -{ - msm_gpiomux_put(chip->base + offset); -} - - ...somewhere in a gpio_chip declaration... - .request = request, - .free = free, - -This provides important functionality: -- It guarantees that a gpio line will have its 'active' config applied - when the line is requested, and will not be suspended while the line - remains requested; and -- It guarantees that gpio-direction settings from gpiolib behave sensibly. - See "About Output-Enable Settings." - -This mechanism allows for "auto-request" of gpiomux lines via gpiolib -when it is suitable. Drivers wishing more exact control are, of course, -free to also use msm_gpiomux_set and msm_gpiomux_get. - -About Output-Enable Settings -============================ - -Some msm targets do not have the ability to query the current gpio -configuration setting. This means that changes made to the output-enable -(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux. -Therefore, when gpiomux applies a configuration setting, any direction -settings which may have been applied by gpiolib are lost and the default -input settings are re-applied. - -For this reason, drivers should not assume that gpio direction settings -continue to hold if they free and then re-request a gpio. This seems like -common sense - after all, anybody could have obtained the line in the -meantime - but it needs saying. - -This also means that calls to msm_gpiomux_write will reset the OE bit, -which means that if the gpio line is held by a client of gpiolib and -msm_gpiomux_write is called, the direction setting has been lost and -gpiolib's internal state has been broken. -Release gpio lines before reconfiguring them. diff --git a/Documentation/devicetree/bindings/arm/al,alpine.txt b/Documentation/devicetree/bindings/arm/al,alpine.txt new file mode 100644 index 000000000000..f404a4f9b165 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/al,alpine.txt @@ -0,0 +1,88 @@ +Annapurna Labs Alpine Platform Device Tree Bindings +--------------------------------------------------------------- + +Boards in the Alpine family shall have the following properties: + +* Required root node properties: +compatible: must contain "al,alpine" + +* Example: + +/ { + model = "Annapurna Labs Alpine Dev Board"; + compatible = "al,alpine"; + + ... +} + +* CPU node: + +The Alpine platform includes cortex-a15 cores. +enable-method: must be "al,alpine-smp" to allow smp [1] + +Example: + +cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "al,alpine-smp"; + + cpu@0 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <0>; + }; + + cpu@1 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <1>; + }; + + cpu@2 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <2>; + }; + + cpu@3 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <3>; + }; +}; + + +* Alpine CPU resume registers + +The CPU resume register are used to define required resume address after +reset. + +Properties: +- compatible : Should contain "al,alpine-cpu-resume". +- reg : Offset and length of the register set for the device + +Example: + +cpu_resume { + compatible = "al,alpine-cpu-resume"; + reg = <0xfbff5ed0 0x30>; +}; + +* Alpine System-Fabric Service Registers + +The System-Fabric Service Registers allow various operation on CPU and +system fabric, like powering CPUs off. + +Properties: +- compatible : Should contain "al,alpine-sysfabric-service" and "syscon". +- reg : Offset and length of the register set for the device + +Example: + +nb_service { + compatible = "al,alpine-sysfabric-service", "syscon"; + reg = <0xfb070000 0x10000>; +}; + +[1] arm/cpu-enable-method/al,alpine-smp diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index 8fe815046140..973884a1bacf 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -8,3 +8,7 @@ Boards with the Amlogic Meson6 SoC shall have the following properties: Boards with the Amlogic Meson8 SoC shall have the following properties: Required root node property: compatible: "amlogic,meson8"; + +Board compatible values: + - "geniatech,atv1200" + - "minix,neo-x8" diff --git a/Documentation/devicetree/bindings/arm/armada-39x.txt b/Documentation/devicetree/bindings/arm/armada-39x.txt new file mode 100644 index 000000000000..53d4ff9ea8ad --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-39x.txt @@ -0,0 +1,20 @@ +Marvell Armada 39x Platforms Device Tree Bindings +------------------------------------------------- + +Boards with a SoC of the Marvell Armada 39x family shall have the +following property: + +Required root node property: + + - compatible: must contain "marvell,armada390" + +In addition, boards using the Marvell Armada 398 SoC shall have the +following property before the previous one: + +Required root node property: + +compatible: must contain "marvell,armada398" + +Example: + +compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada390"; diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt index ad319f84f560..2e99b5b57350 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt @@ -46,10 +46,12 @@ PIT Timer required properties: shared across all System Controller members. System Timer (ST) required properties: -- compatible: Should be "atmel,at91rm9200-st" +- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd" - reg: Should contain registers location and length - interrupts: Should contain interrupt for the ST which is the IRQ line shared across all System Controller members. +Its subnodes can be: +- watchdog: compatible should be "atmel,at91rm9200-wdt" TC/TCLIB Timer required properties: - compatible: Should be "atmel,<chip>-tcb". diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt index f28d82bbbc56..3c5c631328d3 100644 --- a/Documentation/devicetree/bindings/arm/cci.txt +++ b/Documentation/devicetree/bindings/arm/cci.txt @@ -94,8 +94,11 @@ specific to ARM. - compatible Usage: required Value type: <string> - Definition: must be "arm,cci-400-pmu" - + Definition: Must contain one of: + "arm,cci-400-pmu,r0" + "arm,cci-400-pmu,r1" + "arm,cci-400-pmu" - DEPRECATED, permitted only where OS has + secure acces to CCI registers - reg: Usage: required Value type: Integer cells. A register entry, expressed diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp b/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp new file mode 100644 index 000000000000..c2e0cc5e4cfd --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/al,alpine-smp @@ -0,0 +1,52 @@ +======================================================== +Secondary CPU enable-method "al,alpine-smp" binding +======================================================== + +This document describes the "al,alpine-smp" method for +enabling secondary CPUs. To apply to all CPUs, a single +"al,alpine-smp" enable method should be defined in the +"cpus" node. + +Enable method name: "al,alpine-smp" +Compatible machines: "al,alpine" +Compatible CPUs: "arm,cortex-a15" +Related properties: (none) + +Note: +This enable method requires valid nodes compatible with +"al,alpine-cpu-resume" and "al,alpine-nb-service"[1]. + +Example: + +cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "al,alpine-smp"; + + cpu@0 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <0>; + }; + + cpu@1 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <1>; + }; + + cpu@2 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <2>; + }; + + cpu@3 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + reg = <3>; + }; +}; + +-- +[1] arm/al,alpine.txt diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 8b9e0a95de31..6aa331d11c5e 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -192,6 +192,7 @@ nodes to be present and contain the properties described below. "brcm,brahma-b15" "marvell,armada-375-smp" "marvell,armada-380-smp" + "marvell,armada-390-smp" "marvell,armada-xp-smp" "qcom,gcc-msm8660" "qcom,kpss-acc-v1" diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 1e097037349c..5da38c5ed476 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -22,6 +22,9 @@ Optional Properties: - pclkN, clkN: Pairs of parent of input clock and input clock to the devices in this power domain. Maximum of 4 pairs (N = 0 to 3) are supported currently. + - asbN: Clocks required by asynchronous bridges (ASB) present in + the power domain. These clock should be enabled during power + domain on/off operations. - power-domains: phandle pointing to the parent power domain, for more details see Documentation/devicetree/bindings/power/power_domain.txt diff --git a/Documentation/devicetree/bindings/arm/geniatech.txt b/Documentation/devicetree/bindings/arm/geniatech.txt deleted file mode 100644 index 74ccba40b73b..000000000000 --- a/Documentation/devicetree/bindings/arm/geniatech.txt +++ /dev/null @@ -1,5 +0,0 @@ -Geniatech platforms device tree bindings -------------------------------------------- - -Geniatech ATV1200 - - compatible = "geniatech,atv1200" diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 1e0d21201d3a..2da059a4790c 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -18,6 +18,8 @@ Main node required properties: "arm,arm11mp-gic" "brcm,brahma-b15-gic" "arm,arm1176jzf-devchip-gic" + "qcom,msm-8660-qgic" + "qcom,msm-qgic2" - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an interrupt source. The type shall be a <u32> and the value shall be 3. diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt index 925ecbf6e7b7..4f40ff3fee4b 100644 --- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt +++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt @@ -42,6 +42,7 @@ board. Currently known boards are: "lacie,cloudbox" "lacie,inetspace_v2" "lacie,laplug" +"lacie,nas2big" "lacie,netspace_lite_v2" "lacie,netspace_max_v2" "lacie,netspace_mini_v2" diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt new file mode 100644 index 000000000000..06df04cc827a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt @@ -0,0 +1,84 @@ +QCOM Idle States for cpuidle driver + +ARM provides idle-state node to define the cpuidle states, as defined in [1]. +cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle +states. Idle states have different enter/exit latency and residency values. +The idle states supported by the QCOM SoC are defined as - + + * Standby + * Retention + * Standalone Power Collapse (Standalone PC or SPC) + * Power Collapse (PC) + +Standby: Standby does a little more in addition to architectural clock gating. +When the WFI instruction is executed the ARM core would gate its internal +clocks. In addition to gating the clocks, QCOM cpus use this instruction as a +trigger to execute the SPM state machine. The SPM state machine waits for the +interrupt to trigger the core back in to active. This triggers the cache +hierarchy to enter standby states, when all cpus are idle. An interrupt brings +the SPM state machine out of its wait, the next step is to ensure that the +cache hierarchy is also out of standby, and then the cpu is allowed to resume +execution. This state is defined as a generic ARM WFI state by the ARM cpuidle +driver and is not defined in the DT. The SPM state machine should be +configured to execute this state by default and after executing every other +state below. + +Retention: Retention is a low power state where the core is clock gated and +the memory and the registers associated with the core are retained. The +voltage may be reduced to the minimum value needed to keep the processor +registers active. The SPM should be configured to execute the retention +sequence and would wait for interrupt, before restoring the cpu to execution +state. Retention may have a slightly higher latency than Standby. + +Standalone PC: A cpu can power down and warmboot if there is a sufficient time +between the time it enters idle and the next known wake up. SPC mode is used +to indicate a core entering a power down state without consulting any other +cpu or the system resources. This helps save power only on that core. The SPM +sequence for this idle state is programmed to power down the supply to the +core, wait for the interrupt, restore power to the core, and ensure the +system state including cache hierarchy is ready before allowing core to +resume. Applying power and resetting the core causes the core to warmboot +back into Elevation Level (EL) which trampolines the control back to the +kernel. Entering a power down state for the cpu, needs to be done by trapping +into a EL. Failing to do so, would result in a crash enforced by the warm boot +code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to +be flushed in s/w, before powering down the core. + +Power Collapse: This state is similar to the SPC mode, but distinguishes +itself in that the cpu acknowledges and permits the SoC to enter deeper sleep +modes. In a hierarchical power domain SoC, this means L2 and other caches can +be flushed, system bus, clocks - lowered, and SoC main XO clock gated and +voltages reduced, provided all cpus enter this state. Since the span of low +power modes possible at this state is vast, the exit latency and the residency +of this low power mode would be considered high even though at a cpu level, +this essentially is cpu power down. The SPM in this state also may handshake +with the Resource power manager (RPM) processor in the SoC to indicate a +complete application processor subsystem shut down. + +The idle-state for QCOM SoCs are distinguished by the compatible property of +the idle-states device node. + +The devicetree representation of the idle state should be - + +Required properties: + +- compatible: Must be one of - + "qcom,idle-state-ret", + "qcom,idle-state-spc", + "qcom,idle-state-pc", + and "arm,idle-state". + +Other required and optional properties are specified in [1]. + +Example: + + idle-states { + CPU_SPC: spc { + compatible = "qcom,idle-state-spc", "arm,idle-state"; + entry-latency-us = <150>; + exit-latency-us = <200>; + min-residency-us = <2000>; + }; + }; + +[1]. Documentation/devicetree/bindings/arm/idle-states.txt diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt index 1505fb8e131a..ae4afc6dcfe0 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt @@ -2,22 +2,31 @@ SPM AVS Wrapper 2 (SAW2) The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable -micro-controller that transitions a piece of hardware (like a processor or +power-controller that transitions a piece of hardware (like a processor or subsystem) into and out of low power modes via a direct connection to the PMIC. It can also be wired up to interact with other processors in the system, notifying them when a low power state is entered or exited. +Multiple revisions of the SAW hardware are supported using these Device Nodes. +SAW2 revisions differ in the register offset and configuration data. Also, the +same revision of the SAW in different SoCs may have different configuration +data due the the differences in hardware capabilities. Hence the SoC name, the +version of the SAW hardware in that SoC and the distinction between cpu (big +or Little) or cache, may be needed to uniquely identify the SAW register +configuration and initialization data. The compatible string is used to +indicate this parameter. + PROPERTIES - compatible: Usage: required Value type: <string> - Definition: shall contain "qcom,saw2". A more specific value should be - one of: - "qcom,saw2-v1" - "qcom,saw2-v1.1" - "qcom,saw2-v2" - "qcom,saw2-v2.1" + Definition: Must have + "qcom,saw2" + A more specific value could be one of: + "qcom,apq8064-saw2-v1.1-cpu" + "qcom,msm8974-saw2-v2.1-cpu" + "qcom,apq8084-saw2-v2.1-cpu" - reg: Usage: required @@ -26,10 +35,23 @@ PROPERTIES the register region. An optional second element specifies the base address and size of the alias register region. +- regulator: + Usage: optional + Value type: boolean + Definition: Indicates that this SPM device acts as a regulator device + device for the core (CPU or Cache) the SPM is attached + to. -Example: +Example 1: - regulator@2099000 { + power-controller@2099000 { compatible = "qcom,saw2"; reg = <0x02099000 0x1000>, <0x02009000 0x1000>; + regulator; + }; + +Example 2: + saw0: power-controller@f9089000 { + compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2"; + reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/arm/omap/ctrl.txt b/Documentation/devicetree/bindings/arm/omap/ctrl.txt new file mode 100644 index 000000000000..3a4e5901ce31 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/ctrl.txt @@ -0,0 +1,79 @@ +OMAP Control Module bindings + +Control Module contains miscellaneous features under it based on SoC type. +Pincontrol is one common feature, and it has a specialized support +described in [1]. Typically some clock nodes are also under control module. +Syscon is used to share register level access to drivers external to +control module driver itself. + +See [2] for documentation about clock/clockdomain nodes. + +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +[2] Documentation/devicetree/bindings/clock/ti/* + +Required properties: +- compatible: Must be one of: + "ti,am3-scm" + "ti,am4-scm" + "ti,dm814-scrm" + "ti,dm816-scrm" + "ti,omap2-scm" + "ti,omap3-scm" + "ti,omap4-scm-core" + "ti,omap4-scm-padconf-core" + "ti,omap5-scm-core" + "ti,omap5-scm-padconf-core" + "ti,dra7-scm-core" +- reg: Contains Control Module register address range + (base address and length) + +Optional properties: +- clocks: clocks for this module +- clockdomains: clockdomains for this module + +Examples: + +scm: scm@2000 { + compatible = "ti,omap3-scm", "simple-bus"; + reg = <0x2000 0x2000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x2000 0x2000>; + + omap3_pmx_core: pinmux@30 { + compatible = "ti,omap3-padconf", + "pinctrl-single"; + reg = <0x30 0x230>; + #address-cells = <1>; + #size-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; + pinctrl-single,register-width = <16>; + pinctrl-single,function-mask = <0xff1f>; + }; + + scm_conf: scm_conf@270 { + compatible = "syscon"; + reg = <0x270 0x330>; + #address-cells = <1>; + #size-cells = <1>; + + scm_clocks: clocks { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + scm_clockdomains: clockdomains { + }; +} + +&scm_clocks { + mcbsp5_mux_fck: mcbsp5_mux_fck { + #clock-cells = <0>; + compatible = "ti,composite-mux-clock"; + clocks = <&core_96m_fck>, <&mcbsp_clks>; + ti,bit-shift = <4>; + reg = <0x02d8>; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/l4.txt b/Documentation/devicetree/bindings/arm/omap/l4.txt new file mode 100644 index 000000000000..b4f8a16e7e3b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/l4.txt @@ -0,0 +1,26 @@ +L4 interconnect bindings + +These bindings describe the OMAP SoCs L4 interconnect bus. + +Required properties: +- compatible : Should be "ti,omap2-l4" for OMAP2 family l4 core bus + Should be "ti,omap2-l4-wkup" for OMAP2 family l4 wkup bus + Should be "ti,omap3-l4-core" for OMAP3 family l4 core bus + Should be "ti,omap4-l4-cfg" for OMAP4 family l4 cfg bus + Should be "ti,omap4-l4-wkup" for OMAP4 family l4 wkup bus + Should be "ti,omap5-l4-cfg" for OMAP5 family l4 cfg bus + Should be "ti,omap5-l4-wkup" for OMAP5 family l4 wkup bus + Should be "ti,dra7-l4-cfg" for DRA7 family l4 cfg bus + Should be "ti,dra7-l4-wkup" for DRA7 family l4 wkup bus + Should be "ti,am3-l4-wkup" for AM33xx family l4 wkup bus + Should be "ti,am4-l4-wkup" for AM43xx family l4 wkup bus +- ranges : contains the IO map range for the bus + +Examples: + +l4: l4@48000000 { + compatible "ti,omap2-l4", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x48000000 0x100000>; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt b/Documentation/devicetree/bindings/arm/omap/prcm.txt index 79074dac684a..3eb6d7afff14 100644 --- a/Documentation/devicetree/bindings/arm/omap/prcm.txt +++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt @@ -10,14 +10,10 @@ documentation about the individual clock/clockdomain nodes. Required properties: - compatible: Must be one of: "ti,am3-prcm" - "ti,am3-scrm" "ti,am4-prcm" - "ti,am4-scrm" "ti,omap2-prcm" - "ti,omap2-scrm" "ti,omap3-prm" "ti,omap3-cm" - "ti,omap3-scrm" "ti,omap4-cm1" "ti,omap4-prm" "ti,omap4-cm2" @@ -29,6 +25,8 @@ Required properties: "ti,dra7-prm" "ti,dra7-cm-core-aon" "ti,dra7-cm-core" + "ti,dm814-prcm" + "ti,dm816-prcm" - reg: Contains PRCM module register address range (base address and length) - clocks: clocks for this module diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index 6809e4e51ed2..60d4a1e0a9b5 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -22,3 +22,7 @@ Rockchip platforms device tree bindings - compatible = "firefly,firefly-rk3288", "rockchip,rk3288"; or - compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288"; + +- ChipSPARK PopMetal-RK3288 board: + Required root node properties: + - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288"; diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 51147cb5c036..c4f19b2e7dd9 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -7,8 +7,6 @@ SoCs: compatible = "renesas,emev2" - RZ/A1H (R7S72100) compatible = "renesas,r7s72100" - - SH-Mobile AP4 (R8A73720/SH7372) - compatible = "renesas,sh7372" - SH-Mobile AG5 (R8A73A00/SH73A0) compatible = "renesas,sh73a0" - R-Mobile APE6 (R8A73A40) @@ -37,8 +35,6 @@ Boards: compatible = "renesas,alt", "renesas,r8a7794" - APE6-EVM compatible = "renesas,ape6evm", "renesas,r8a73a4" - - APE6-EVM - Reference Device Tree Implementation - compatible = "renesas,ape6evm-reference", "renesas,r8a73a4" - Atmark Techno Armadillo-800 EVA compatible = "renesas,armadillo800eva" - BOCK-W @@ -57,12 +53,8 @@ Boards: compatible = "renesas,kzm9d", "renesas,emev2" - Kyoto Microcomputer Co. KZM-A9-GT compatible = "renesas,kzm9g", "renesas,sh73a0" - - Kyoto Microcomputer Co. KZM-A9-GT - Reference Device Tree Implementation - compatible = "renesas,kzm9g-reference", "renesas,sh73a0" - Lager (RTP0RC7790SEB00010S) compatible = "renesas,lager", "renesas,r8a7790" - - Mackerel (R0P7372LC0016RL, AP4 EVM 2nd) - compatible = "renesas,mackerel" - Marzen compatible = "renesas,marzen", "renesas,r8a7779" diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt new file mode 100644 index 000000000000..ea670a5d7ee3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt @@ -0,0 +1,32 @@ +NVIDIA Tegra Activity Monitor + +The activity monitor block collects statistics about the behaviour of other +components in the system. This information can be used to derive the rate at +which the external memory needs to be clocked in order to serve all requests +from the monitored clients. + +Required properties: +- compatible: should be "nvidia,tegra<chip>-actmon" +- reg: offset and length of the register set for the device +- interrupts: standard interrupt property +- clocks: Must contain a phandle and clock specifier pair for each entry in +clock-names. See ../../clock/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - actmon + - emc +- resets: Must contain an entry for each entry in reset-names. See +../../reset/reset.txt for details. +- reset-names: Must include the following entries: + - actmon + +Example: + actmon@6000c800 { + compatible = "nvidia,tegra124-actmon"; + reg = <0x0 0x6000c800 0x0 0x400>; + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA124_CLK_ACTMON>, + <&tegra_car TEGRA124_CLK_EMC>; + clock-names = "actmon", "emc"; + resets = <&tegra_car 119>; + reset-names = "actmon"; + }; diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt index 63dd8051521c..18729f6fe1e5 100644 --- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt +++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt @@ -1,7 +1,8 @@ * OMAP OCP2SCP - ocp interface to scp interface properties: -- compatible : Should be "ti,omap-ocp2scp" +- compatible : Should be "ti,am437x-ocp2scp" for AM437x processor + Should be "ti,omap-ocp2scp" for all others - reg : Address and length of the register set for the device - #address-cells, #size-cells : Must be present if the device has sub-nodes - ranges : the child address space are mapped 1:1 onto the parent address space diff --git a/Documentation/devicetree/bindings/bus/renesas,bsc.txt b/Documentation/devicetree/bindings/bus/renesas,bsc.txt new file mode 100644 index 000000000000..90e947269437 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/renesas,bsc.txt @@ -0,0 +1,46 @@ +Renesas Bus State Controller (BSC) +================================== + +The Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus +Bridge", or "External Bus Interface") can be found in several Renesas ARM SoCs. +It provides an external bus for connecting multiple external devices to the +SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB. + +While the BSC is a fairly simple memory-mapped bus, it may be part of a PM +domain, and may have a gateable functional clock. +Before a device connected to the BSC can be accessed, the PM domain +containing the BSC must be powered on, and the functional clock +driving the BSC must be enabled. + +The bindings for the BSC extend the bindings for "simple-pm-bus". + + +Required properties + - compatible: Must contain an SoC-specific value, and "renesas,bsc" and + "simple-pm-bus" as fallbacks. + SoC-specific values can be: + "renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4) + "renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0) + - #address-cells, #size-cells, ranges: Must describe the mapping between + parent address and child address spaces. + - reg: Must contain the base address and length to access the bus controller. + +Optional properties: + - interrupts: Must contain a reference to the BSC interrupt, if available. + - clocks: Must contain a reference to the functional clock, if available. + - power-domains: Must contain a reference to the PM domain, if available. + + +Example: + + bsc: bus@fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", + "simple-pm-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x20000000>; + reg = <0xfec10000 0x400>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zb_clk>; + power-domains = <&pd_a4s>; + }; diff --git a/Documentation/devicetree/bindings/bus/simple-pm-bus.txt b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt new file mode 100644 index 000000000000..d032237512c2 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/simple-pm-bus.txt @@ -0,0 +1,44 @@ +Simple Power-Managed Bus +======================== + +A Simple Power-Managed Bus is a transparent bus that doesn't need a real +driver, as it's typically initialized by the boot loader. + +However, its bus controller is part of a PM domain, or under the control of a +functional clock. Hence, the bus controller's PM domain and/or clock must be +enabled for child devices connected to the bus (either on-SoC or externally) +to function. + +While "simple-pm-bus" follows the "simple-bus" set of properties, as specified +in ePAPR, it is not an extension of "simple-bus". + + +Required properties: + - compatible: Must contain at least "simple-pm-bus". + Must not contain "simple-bus". + It's recommended to let this be preceded by one or more + vendor-specific compatible values. + - #address-cells, #size-cells, ranges: Must describe the mapping between + parent address and child address spaces. + +Optional platform-specific properties for clock or PM domain control (at least +one of them is required): + - clocks: Must contain a reference to the functional clock(s), + - power-domains: Must contain a reference to the PM domain. +Please refer to the binding documentation for the clock and/or PM domain +providers for more details. + + +Example: + + bsc: bus@fec10000 { + compatible = "renesas,bsc-sh73a0", "renesas,bsc", + "simple-pm-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x20000000>; + reg = <0xfec10000 0x400>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&zb_clk>; + power-domains = <&pd_a4s>; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt new file mode 100644 index 000000000000..2f3747fdcf1c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt @@ -0,0 +1,25 @@ +* Renesas R8A7778 Clock Pulse Generator (CPG) + +The CPG generates core clocks for the R8A7778. It includes two PLLs and +several fixed ratio dividers + +Required Properties: + + - compatible: Must be "renesas,r8a7778-cpg-clocks" + - reg: Base address and length of the memory resource used by the CPG + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are + "plla", "pllb", "b", "out", "p", "s", and "s1". + + +Example +------- + + cpg_clocks: cpg_clocks@ffc80000 { + compatible = "renesas,r8a7778-cpg-clocks"; + reg = <0xffc80000 0x80>; + #clock-cells = <1>; + clocks = <&extal_clk>; + clock-output-names = "plla", "pllb", "b", + "out", "p", "s", "s1"; + }; diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 003bd77b4595..ad0c4ac916dd 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -77,6 +77,7 @@ nxp,pca9556 Octal SMBus and I2C registered interface nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset nxp,pcf8563 Real-time clock/calendar nxp,pcf85063 Tiny Real-Time Clock +oki,ml86v7667 OKI ML86V7667 video decoder ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus pericom,pt7c4338 Real-time Clock Module plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch diff --git a/Documentation/devicetree/bindings/media/ti,omap3isp.txt b/Documentation/devicetree/bindings/media/ti,omap3isp.txt new file mode 100644 index 000000000000..ac23de855641 --- /dev/null +++ b/Documentation/devicetree/bindings/media/ti,omap3isp.txt @@ -0,0 +1,71 @@ +OMAP 3 ISP Device Tree bindings +=============================== + +The DT definitions can be found in include/dt-bindings/media/omap3-isp.h. + +Required properties +=================== + +compatible : must contain "ti,omap3-isp" + +reg : the two registers sets (physical address and length) for the + ISP. The first set contains the core ISP registers up to + the end of the SBL block. The second set contains the + CSI PHYs and receivers registers. +interrupts : the ISP interrupt specifier +iommus : phandle and IOMMU specifier for the IOMMU that serves the ISP +syscon : the phandle and register offset to the Complex I/O or CSI-PHY + register +ti,phy-type : 0 -- OMAP3ISP_PHY_TYPE_COMPLEX_IO (e.g. 3430) + 1 -- OMAP3ISP_PHY_TYPE_CSIPHY (e.g. 3630) +#clock-cells : Must be 1 --- the ISP provides two external clocks, + cam_xclka and cam_xclkb, at indices 0 and 1, + respectively. Please find more information on common + clock bindings in ../clock/clock-bindings.txt. + +Port nodes (optional) +--------------------- + +More documentation on these bindings is available in +video-interfaces.txt in the same directory. + +reg : The interface: + 0 - parallel (CCDC) + 1 - CSIPHY1 -- CSI2C / CCP2B on 3630; + CSI1 -- CSIb on 3430 + 2 - CSIPHY2 -- CSI2A / CCP2B on 3630; + CSI2 -- CSIa on 3430 + +Optional properties +=================== + +vdd-csiphy1-supply : voltage supply of the CSI-2 PHY 1 +vdd-csiphy2-supply : voltage supply of the CSI-2 PHY 2 + +Endpoint nodes +-------------- + +lane-polarities : lane polarity (required on CSI-2) + 0 -- not inverted; 1 -- inverted +data-lanes : an array of data lanes from 1 to 3. The length can + be either 1 or 2. (required on CSI-2) +clock-lanes : the clock lane (from 1 to 3). (required on CSI-2) + + +Example +======= + + isp@480bc000 { + compatible = "ti,omap3-isp"; + reg = <0x480bc000 0x12fc + 0x480bd800 0x0600>; + interrupts = <24>; + iommus = <&mmu_isp>; + syscon = <&scm_conf 0x2f0>; + ti,phy-type = <OMAP3ISP_PHY_TYPE_CSIPHY>; + #clock-cells = <1>; + ports { + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt new file mode 100644 index 000000000000..e90519d566a3 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt @@ -0,0 +1,22 @@ +QCOM Top Control and Status Register + +Qualcomm devices have a set of registers that provide various control and status +functions for their peripherals. This node is intended to allow access to these +registers via syscon. + +Required properties: +- compatible: Should contain: + "qcom,tcsr-ipq8064", "syscon" for IPQ8064 + "qcom,tcsr-apq8064", "syscon" for APQ8064 + "qcom,tcsr-msm8660", "syscon" for MSM8660 + "qcom,tcsr-msm8960", "syscon" for MSM8960 + "qcom,tcsr-msm8974", "syscon" for MSM8974 + "qcom,tcsr-apq8084", "syscon" for APQ8084 + "qcom,tcsr-msm8916", "syscon" for MSM8916 +- reg: Address range for TCSR registers + +Example: + tcsr: syscon@1a400000 { + compatible = "qcom,tcsr-msm8960", "syscon"; + reg = <0x1a400000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt new file mode 100644 index 000000000000..2a3d90de18ee --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt @@ -0,0 +1,47 @@ +TI Wilink 6/7/8 (wl12xx/wl18xx) SDIO devices + +This node provides properties for controlling the wilink wireless device. The +node is expected to be specified as a child node to the SDIO controller that +connects the device to the system. + +Required properties: + - compatible: should be one of the following: + * "ti,wl1271" + * "ti,wl1273" + * "ti,wl1281" + * "ti,wl1283" + * "ti,wl1801" + * "ti,wl1805" + * "ti,wl1807" + * "ti,wl1831" + * "ti,wl1835" + * "ti,wl1837" + - interrupts : specifies attributes for the out-of-band interrupt. + +Optional properties: + - interrupt-parent : the phandle for the interrupt controller to which the + device interrupts are connected. + - ref-clock-frequency : ref clock frequency in Hz + - tcxo-clock-frequency : tcxo clock frequency in Hz + +Note: the *-clock-frequency properties assume internal clocks. In case of external +clock, new bindings (for parsing the clock nodes) have to be added. + +Example: + +&mmc3 { + status = "okay"; + vmmc-supply = <&wlan_en_reg>; + bus-width = <4>; + cap-power-off-card; + keep-power-in-suspend; + + #address-cells = <1>; + #size-cells = <0>; + wlcore: wlcore@2 { + compatible = "ti,wl1835"; + reg = <2>; + interrupt-parent = <&gpio0>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH>; + }; +}; diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt new file mode 100644 index 000000000000..65cc0345747d --- /dev/null +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt @@ -0,0 +1,59 @@ +Freescale i.MX General Power Controller +======================================= + +The i.MX6Q General Power Control (GPC) block contains DVFS load tracking +counters and Power Gating Control (PGC) for the CPU and PU (GPU/VPU) power +domains. + +Required properties: +- compatible: Should be "fsl,imx6q-gpc" or "fsl,imx6sl-gpc" +- reg: should be register base and length as documented in the + datasheet +- interrupts: Should contain GPC interrupt request 1 +- pu-supply: Link to the LDO regulator powering the PU power domain +- clocks: Clock phandles to devices in the PU power domain that need + to be enabled during domain power-up for reset propagation. +- #power-domain-cells: Should be 1, see below: + +The gpc node is a power-controller as documented by the generic power domain +bindings in Documentation/devicetree/bindings/power/power_domain.txt. + +Example: + + gpc: gpc@020dc000 { + compatible = "fsl,imx6q-gpc"; + reg = <0x020dc000 0x4000>; + interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>, + <0 90 IRQ_TYPE_LEVEL_HIGH>; + pu-supply = <®_pu>; + clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>, + <&clks IMX6QDL_CLK_GPU3D_SHADER>, + <&clks IMX6QDL_CLK_GPU2D_CORE>, + <&clks IMX6QDL_CLK_GPU2D_AXI>, + <&clks IMX6QDL_CLK_OPENVG_AXI>, + <&clks IMX6QDL_CLK_VPU_AXI>; + #power-domain-cells = <1>; + }; + + +Specifying power domain for IP modules +====================================== + +IP cores belonging to a power domain should contain a 'power-domains' property +that is a phandle pointing to the gpc device node and a DOMAIN_INDEX specifying +the power domain the device belongs to. + +Example of a device that is part of the PU power domain: + + vpu: vpu@02040000 { + reg = <0x02040000 0x3c000>; + /* ... */ + power-domains = <&gpc 1>; + /* ... */ + }; + +The following DOMAIN_INDEX values are valid for i.MX6Q: +ARM_DOMAIN 0 +PU_DOMAIN 1 +The following additional DOMAIN_INDEX value is valid for i.MX6SL: +DISPLAY_DOMAIN 2 diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt index cc3b1f0a9b1a..beda7d2efc30 100644 --- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt @@ -11,6 +11,7 @@ Required properties: - compatible: Should be "renesas,sysc-<soctype>", "renesas,sysc-rmobile" as fallback. Examples with soctypes are: + - "renesas,sysc-r8a73a4" (R-Mobile APE6) - "renesas,sysc-r8a7740" (R-Mobile A1) - "renesas,sysc-sh73a0" (SH-Mobile AG5) - reg: Two address start and address range blocks for the device: diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index a6391e70a8fd..90787aa2e648 100644 --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt @@ -1,9 +1,10 @@ * Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART) Required properties: -- compatible: Should be "atmel,<chip>-usart" +- compatible: Should be "atmel,<chip>-usart" or "atmel,<chip>-dbgu" The compatible <chip> indicated will be the first SoC to support an additional mode or an USART new feature. + For the dbgu UART, use "atmel,<chip>-dbgu", "atmel,<chip>-usart" - reg: Should contain registers location and length - interrupts: Should contain interrupt - clock-names: tuple listing input clock names. diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index 342eedd10050..54c2a155c783 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -4,7 +4,27 @@ Required properties: - compatible : should be "ti,omap2-uart" for OMAP2 controllers - compatible : should be "ti,omap3-uart" for OMAP3 controllers - compatible : should be "ti,omap4-uart" for OMAP4 controllers +- reg : address and length of the register space +- interrupts or interrupts-extended : Should contain the uart interrupt + specifier or both the interrupt + controller phandle and interrupt + specifier. - ti,hwmods : Must be "uart<n>", n being the instance number (1-based) Optional properties: - clock-frequency : frequency of the clock input to the UART +- dmas : DMA specifier, consisting of a phandle to the DMA controller + node and a DMA channel number. +- dma-names : "rx" for receive channel, "tx" for transmit channel. + +Example: + + uart4: serial@49042000 { + compatible = "ti,omap3-uart"; + reg = <0x49042000 0x400>; + interrupts = <80>; + dmas = <&sdma 81 &sdma 82>; + dma-names = "tx", "rx"; + ti,hwmods = "uart4"; + clock-frequency = <48000000>; + }; diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt new file mode 100644 index 000000000000..ddeb5b6a53c1 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -0,0 +1,58 @@ +MediaTek PMIC Wrapper Driver + +This document describes the binding for the MediaTek PMIC wrapper. + +On MediaTek SoCs the PMIC is connected via SPI. The SPI master interface +is not directly visible to the CPU, but only through the PMIC wrapper +inside the SoC. The communication between the SoC and the PMIC can +optionally be encrypted. Also a non standard Dual IO SPI mode can be +used to increase speed. + +IP Pairing + +on MT8135 the pins of some SoC internal peripherals can be on the PMIC. +The signals of these pins are routed over the SPI bus using the pwrap +bridge. In the binding description below the properties needed for bridging +are marked with "IP Pairing". These are optional on SoCs which do not support +IP Pairing + +Required properties in pwrap device node. +- compatible: + "mediatek,mt8135-pwrap" for MT8135 SoCs + "mediatek,mt8173-pwrap" for MT8173 SoCs +- interrupts: IRQ for pwrap in SOC +- reg-names: Must include the following entries: + "pwrap": Main registers base + "pwrap-bridge": bridge base (IP Pairing) +- reg: Must contain an entry for each entry in reg-names. +- reset-names: Must include the following entries: + "pwrap" + "pwrap-bridge" (IP Pairing) +- resets: Must contain an entry for each entry in reset-names. +- clock-names: Must include the following entries: + "spi": SPI bus clock + "wrap": Main module clock +- clocks: Must contain an entry for each entry in clock-names. + +Optional properities: +- pmic: Mediatek PMIC MFD is the child device of pwrap + See the following for child node definitions: + Documentation/devicetree/bindings/mfd/mt6397.txt + +Example: + pwrap: pwrap@1000f000 { + compatible = "mediatek,mt8135-pwrap"; + reg = <0 0x1000f000 0 0x1000>, + <0 0x11017000 0 0x1000>; + reg-names = "pwrap", "pwrap-bridge"; + interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>; + resets = <&infracfg MT8135_INFRA_PMIC_WRAP_RST>, + <&pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST>; + reset-names = "pwrap", "pwrap-bridge"; + clocks = <&clk26m>, <&clk26m>; + clock-names = "spi", "wrap"; + + pmic { + compatible = "mediatek,mt6397"; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt index 4ce24d425bf1..2f5ede39bea2 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt @@ -6,7 +6,8 @@ configuration settings. The mode setting will govern the input/output mode of the 4 GSBI IOs. Required properties: -- compatible: must contain "qcom,gsbi-v1.0.0" for APQ8064/IPQ8064 +- compatible: Should contain "qcom,gsbi-v1.0.0" +- cell-index: Should contain the GSBI index - reg: Address range for GSBI registers - clocks: required clock - clock-names: must contain "iface" entry @@ -16,6 +17,8 @@ Required properties: Optional properties: - qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. +- syscon-tcsr: indicates phandle of TCSR syscon node. Required if child uses + dma. Required properties if child node exists: - #address-cells: Must be 1 @@ -39,6 +42,7 @@ Example for APQ8064: gsbi4@16300000 { compatible = "qcom,gsbi-v1.0.0"; + cell-index = <4>; reg = <0x16300000 0x100>; clocks = <&gcc GSBI4_H_CLK>; clock-names = "iface"; @@ -48,22 +52,24 @@ Example for APQ8064: qcom,mode = <GSBI_PROT_I2C_UART>; qcom,crci = <GSBI_CRCI_QUP>; + syscon-tcsr = <&tcsr>; + /* child nodes go under here */ i2c_qup4: i2c@16380000 { - compatible = "qcom,i2c-qup-v1.1.1"; - reg = <0x16380000 0x1000>; - interrupts = <0 153 0>; + compatible = "qcom,i2c-qup-v1.1.1"; + reg = <0x16380000 0x1000>; + interrupts = <0 153 0>; - clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>; - clock-names = "core", "iface"; + clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>; + clock-names = "core", "iface"; - clock-frequency = <200000>; + clock-frequency = <200000>; - #address-cells = <1>; - #size-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; - }; + }; uart4: serial@16340000 { compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; @@ -76,3 +82,7 @@ Example for APQ8064: }; }; + tcsr: syscon@1a400000 { + compatible = "qcom,apq8064-tcsr", "syscon"; + reg = <0x1a400000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt index 1ab6bc8404d5..f6a715e4ef43 100644 --- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt +++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt @@ -4,9 +4,9 @@ Required properties: - compatible: "ti,omap-twl4030" - ti,model: Name of the sound card (for example "omap3beagle") - ti,mcbsp: phandle for the McBSP node -- ti,codec: phandle for the twl4030 audio node Optional properties: +- ti,codec: phandle for the twl4030 audio node - ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl - ti, jack-det-gpio: Jack detect GPIO - ti,audio-routing: List of connections between audio components. @@ -59,5 +59,4 @@ sound { ti,model = "omap3beagle"; ti,mcbsp = <&mcbsp2>; - ti,codec = <&twl_audio>; }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index aecec35594ee..83737a3403d7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -11,6 +11,7 @@ adapteva Adapteva, Inc. adh AD Holdings Plc. adi Analog Devices, Inc. aeroflexgaisler Aeroflex Gaisler AB +al Annapurna Labs allwinner Allwinner Technology Co., Ltd. alphascale AlphaScale Integrated Circuits Systems, Inc. altr Altera Corp. @@ -83,6 +84,7 @@ globalscale Globalscale Technologies, Inc. gmt Global Mixed-mode Technology, Inc. goodix Shenzhen Huiding Technology Co., Ltd. google Google, Inc. +grinn Grinn gumstix Gumstix, Inc. gw Gateworks Corporation hannstar HannStar Display Corporation @@ -118,6 +120,7 @@ merrii Merrii Technology Co., Ltd. micrel Micrel Inc. microchip Microchip Technology Inc. micron Micron Technology Inc. +minix MINIX Technology Ltd. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt index f059dd0b3d28..ecb8da063d07 100644 --- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt +++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt @@ -10,7 +10,9 @@ Required properties: "atmel,at91sam9g45es-lcdc" , "atmel,at91sam9rl-lcdc" , "atmel,at32ap-lcdc" -- reg : Should contain 1 register ranges(address and length) +- reg : Should contain 1 register ranges(address and length). + Can contain an additional register range(address and length) + for fixed framebuffer memory. Useful for dedicated memories. - interrupts : framebuffer controller interrupt - display: a phandle pointing to the display node @@ -38,6 +40,14 @@ Example: }; +Example for fixed framebuffer memory: + + fb0: fb@0x00500000 { + compatible = "atmel,at91sam9263-lcdc"; + reg = <0x00700000 0x1000 0x70000000 0x200000>; + [...] + }; + Atmel LCDC Display ----------------------------------------------------- Required properties (as per of_videomode_helper): |