diff options
Diffstat (limited to 'Documentation/devicetree/bindings/arm')
-rw-r--r-- | Documentation/devicetree/bindings/arm/arm,scpi.txt | 2 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/cpus.txt | 18 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt | 38 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 16 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/l2c2x0.txt (renamed from Documentation/devicetree/bindings/arm/l2cc.txt) | 24 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/pmu.txt | 5 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/psci.txt | 25 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt | 16 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt | 30 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/arm/secure.txt | 53 |
10 files changed, 123 insertions, 104 deletions
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index 86302de67c2c..313dabdc14f9 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -63,7 +63,7 @@ Required properties: - compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno The rest of the properties should follow the generic mmio-sram description -found in ../../misc/sysram.txt +found in ../../sram/sram.txt Each sub-node represents the reserved area for SCPI. diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 3a07a87fef20..c352c11bd641 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -157,6 +157,7 @@ nodes to be present and contain the properties described below. "arm,cortex-a17" "arm,cortex-a53" "arm,cortex-a57" + "arm,cortex-a72" "arm,cortex-m0" "arm,cortex-m0+" "arm,cortex-m1" @@ -242,6 +243,23 @@ nodes to be present and contain the properties described below. Definition: Specifies the syscon node controlling the cpu core power domains. + - dynamic-power-coefficient + Usage: optional + Value type: <prop-encoded-array> + Definition: A u32 value that represents the running time dynamic + power coefficient in units of mW/MHz/uVolt^2. The + coefficient can either be calculated from power + measurements or derived by analysis. + + The dynamic power consumption of the CPU is + proportional to the square of the Voltage (V) and + the clock frequency (f). The coefficient is used to + calculate the dynamic power as below - + + Pdyn = dynamic-power-coefficient * V^2 * f + + where voltage is in uV, frequency is in MHz. + Example 1 (dual-cluster big.LITTLE system 32-bit): cpus { diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt deleted file mode 100644 index 4a0a4f70a0ce..000000000000 --- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt +++ /dev/null @@ -1,38 +0,0 @@ -Samsung Exynos SYSRAM for SMP bringup: ------------------------------------- - -Samsung SMP-capable Exynos SoCs use part of the SYSRAM for the bringup -of the secondary cores. Once the core gets powered up it executes the -code that is residing at some specific location of the SYSRAM. - -Therefore reserved section sub-nodes have to be added to the mmio-sram -declaration. These nodes are of two types depending upon secure or -non-secure execution environment. - -Required sub-node properties: -- compatible : depending upon boot mode, should be - "samsung,exynos4210-sysram" : for Secure SYSRAM - "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM - -The rest of the properties should follow the generic mmio-sram discription -found in ../../misc/sysram.txt - -Example: - - sysram@02020000 { - compatible = "mmio-sram"; - reg = <0x02020000 0x54000>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x02020000 0x54000>; - - smp-sysram@0 { - compatible = "samsung,exynos4210-sysram"; - reg = <0x0 0x1000>; - }; - - smp-sysram@53000 { - compatible = "samsung,exynos4210-sysram-ns"; - reg = <0x53000 0x1000>; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index 6ac7c000af22..e3ccab114006 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -187,6 +187,22 @@ Example: reg = <0xb0000000 0x10000>; }; +Hisilicon HiP05 PERISUB system controller + +Required properties: +- compatible : "hisilicon,hip05-perisubc", "syscon"; +- reg : Register address and size + +The HiP05 PERISUB system controller is shared by peripheral controllers in +HiP05 Soc to implement some basic configurations. The peripheral +controllers include mdio, ddr, iic, uart, timer and so on. + +Example: + /* for HiP05 perisub-ctrl-c system */ + peri_c_subctrl: syscon@80000000 { + compatible = "hisilicon,hip05-perisubc", "syscon"; + reg = <0x0 0x80000000 0x0 0x10000>; + }; ----------------------------------------------------------------------- Hisilicon CPU controller diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2c2x0.txt index 06c88a4d28ac..fe0398c5c77b 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt @@ -1,7 +1,8 @@ * ARM L2 Cache Controller -ARM cores often have a separate level 2 cache controller. There are various -implementations of the L2 cache controller with compatible programming models. +ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/ +PL310 and variants) based level 2 cache controller. All these various implementations +of the L2 cache controller have compatible programming models (Note 1). Some of the properties that are just prefixed "cache-*" are taken from section 3.7.3 of the ePAPR v1.1 specification which can be found at: https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf @@ -67,12 +68,17 @@ Optional properties: disable if zero. - arm,prefetch-offset : Override prefetch offset value. Valid values are 0-7, 15, 23, and 31. -- arm,shared-override : The default behavior of the pl310 cache controller with - respect to the shareable attribute is to transform "normal memory - non-cacheable transactions" into "cacheable no allocate" (for reads) or - "write through no write allocate" (for writes). +- arm,shared-override : The default behavior of the L220 or PL310 cache + controllers with respect to the shareable attribute is to transform "normal + memory non-cacheable transactions" into "cacheable no allocate" (for reads) + or "write through no write allocate" (for writes). On systems where this may cause DMA buffer corruption, this property must be specified to indicate that such transforms are precluded. +- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310). +- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310). +- arm,outer-sync-disable : disable the outer sync operation on the L2 cache. + Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that + will randomly hang unless outer sync operations are disabled. - prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1> (forcibly enable), property absent (retain settings set by firmware) - prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable), @@ -91,3 +97,9 @@ L2: cache-controller { cache-level = <2>; interrupts = <45>; }; + +Note 1: The description in this document doesn't apply to integrated L2 + cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These + integrated L2 controllers are assumed to be all preconfigured by + early secure boot code. Thus no need to deal with their configuration + in the kernel at all. diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 97ba45af04fc..56518839f52a 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -9,8 +9,9 @@ Required properties: - compatible : should be one of "apm,potenza-pmu" "arm,armv8-pmuv3" - "arm.cortex-a57-pmu" - "arm.cortex-a53-pmu" + "arm,cortex-a72-pmu" + "arm,cortex-a57-pmu" + "arm,cortex-a53-pmu" "arm,cortex-a17-pmu" "arm,cortex-a15-pmu" "arm,cortex-a12-pmu" diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt index a9adab84e2fe..a2c4f1d52492 100644 --- a/Documentation/devicetree/bindings/arm/psci.txt +++ b/Documentation/devicetree/bindings/arm/psci.txt @@ -23,17 +23,20 @@ Main node required properties: - compatible : should contain at least one of: - * "arm,psci" : for implementations complying to PSCI versions prior to - 0.2. For these cases function IDs must be provided. - - * "arm,psci-0.2" : for implementations complying to PSCI 0.2. Function - IDs are not required and should be ignored by an OS with PSCI 0.2 - support, but are permitted to be present for compatibility with - existing software when "arm,psci" is later in the compatible list. - - * "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is - backward compatible with PSCI 0.2 with minor specification updates, - as defined in the PSCI specification[2]. + * "arm,psci" : For implementations complying to PSCI versions prior + to 0.2. + For these cases function IDs must be provided. + + * "arm,psci-0.2" : For implementations complying to PSCI 0.2. + Function IDs are not required and should be ignored by + an OS with PSCI 0.2 support, but are permitted to be + present for compatibility with existing software when + "arm,psci" is later in the compatible list. + + * "arm,psci-1.0" : For implementations complying to PSCI 1.0. + PSCI 1.0 is backward compatible with PSCI 0.2 with + minor specification updates, as defined in the PSCI + specification[2]. - method : The method of calling the PSCI firmware. Permitted values are: diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt deleted file mode 100644 index 6b42fda306ff..000000000000 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt +++ /dev/null @@ -1,16 +0,0 @@ -Rockchip SRAM for pmu: ------------------------------- - -The sram of pmu is used to store the function of resume from maskrom(the 1st -level loader). This is a common use of the "pmu-sram" because it keeps power -even in low power states in the system. - -Required node properties: -- compatible : should be "rockchip,rk3288-pmu-sram" -- reg : physical base address and the size of the registers window - -Example: - sram@ff720000 { - compatible = "rockchip,rk3288-pmu-sram", "mmio-sram"; - reg = <0xff720000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt deleted file mode 100644 index d9416fb8db6f..000000000000 --- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt +++ /dev/null @@ -1,30 +0,0 @@ -Rockchip SRAM for smp bringup: ------------------------------- - -Rockchip's smp-capable SoCs use the first part of the sram for the bringup -of the cores. Once the core gets powered up it executes the code that is -residing at the very beginning of the sram. - -Therefore a reserved section sub-node has to be added to the mmio-sram -declaration. - -Required sub-node properties: -- compatible : should be "rockchip,rk3066-smp-sram" - -The rest of the properties should follow the generic mmio-sram discription -found in ../../misc/sram.txt - -Example: - - sram: sram@10080000 { - compatible = "mmio-sram"; - reg = <0x10080000 0x10000>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - smp-sram@10080000 { - compatible = "rockchip,rk3066-smp-sram"; - reg = <0x10080000 0x50>; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt new file mode 100644 index 000000000000..e31303fb233a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/secure.txt @@ -0,0 +1,53 @@ +* ARM Secure world bindings + +ARM CPUs with TrustZone support have two distinct address spaces, +"Normal" and "Secure". Most devicetree consumers (including the Linux +kernel) are not TrustZone aware and run entirely in either the Normal +world or the Secure world. However some devicetree consumers are +TrustZone aware and need to be able to determine whether devices are +visible only in the Secure address space, only in the Normal address +space, or visible in both. (One example of that situation would be a +virtual machine which boots Secure firmware and wants to tell the +firmware about the layout of the machine via devicetree.) + +The general principle of the naming scheme for Secure world bindings +is that any property that needs a different value in the Secure world +can be supported by prefixing the property name with "secure-". So for +instance "secure-foo" would override "foo". For property names with +a vendor prefix, the Secure variant of "vendor,foo" would be +"vendor,secure-foo". If there is no "secure-" property then the Secure +world value is the same as specified for the Normal world by the +non-prefixed property. However, only the properties listed below may +validly have "secure-" versions; this list will be enlarged on a +case-by-case basis. + +Defining the bindings in this way means that a device tree which has +been annotated to indicate the presence of Secure-only devices can +still be processed unmodified by existing Non-secure software (and in +particular by the kernel). + +Note that it is still valid for bindings intended for purely Secure +world consumers (like kernels that run entirely in Secure) to simply +describe the view of Secure world using the standard bindings. These +secure- bindings only need to be used where both the Secure and Normal +world views need to be described in a single device tree. + +Valid Secure world properties: + +- secure-status : specifies whether the device is present and usable + in the secure world. The combination of this with "status" allows + the various possible combinations of device visibility to be + specified. If "secure-status" is not specified it defaults to the + same value as "status"; if "status" is not specified either then + both default to "okay". This means the following combinations are + possible: + + /* Neither specified: default to visible in both S and NS */ + secure-status = "okay"; /* visible in both */ + status = "okay"; /* visible in both */ + status = "okay"; secure-status = "okay"; /* visible in both */ + secure-status = "disabled"; /* NS-only */ + status = "okay"; secure-status = "disabled"; /* NS-only */ + status = "disabled"; secure-status = "okay"; /* S-only */ + status = "disabled"; /* disabled in both */ + status = "disabled"; secure-status = "disabled"; /* disabled in both */ |