5 files changed, 341 insertions, 9 deletions

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index fc9ce6f1688c..6d21c0288e9e 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -54,8 +54,13 @@ PROPERTIES
    - compatible
       Usage: required
       Value type: <string>
-      Definition: Must include "fsl,sec-v4.0". Also includes SEC
-           ERA versions (optional) with which the device is compatible.
+      Definition: Must include "fsl,sec-v4.0"
+
+   - fsl,sec-era
+      Usage: optional
+      Value type: <u32>
+      Definition: A standard property. Define the 'ERA' of the SEC
+          device.
 
    - #address-cells
        Usage: required
@@ -107,7 +112,8 @@ PROPERTIES
 
 EXAMPLE
         crypto@300000 {
-                compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
+                compatible = "fsl,sec-v4.0";
+                fsl,sec-era = <0x2>;
                 #address-cells = <1>;
                 #size-cells = <1>;
                 reg = <0x300000 0x10000>;
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
index 9e7a2417dac5..7f150b5012cc 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
@@ -17,9 +17,20 @@ Recommended properties:
    contains a functioning "reset control register" (i.e. the board
    is wired to reset upon setting the HRESET_REQ bit in this register).
 
-Example:
+ - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
+   registers, for those SOCs that have a PAMU device.
+
+Examples:
         global-utilities@e0000 {        /* global utilities block */
                 compatible = "fsl,mpc8548-guts";
                 reg = <e0000 1000>;
                 fsl,has-rstcr;
         };
+
+        guts: global-utilities@e0000 {
+                compatible = "fsl,qoriq-device-config-1.0";
+                reg = <0xe0000 0xe00>;
+                fsl,has-rstcr;
+                #sleep-cells = <1>;
+                fsl,liodn-bits = <12>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
new file mode 100644
index 000000000000..1f5e329f756c
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
@@ -0,0 +1,140 @@
+Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding
+
+DESCRIPTION
+
+The PAMU is an I/O MMU that provides device-to-memory access control and
+address translation capabilities.
+
+Required properties:
+
+- compatible    : <string>
+                  First entry is a version-specific string, such as
+                  "fsl,pamu-v1.0".  The second is "fsl,pamu".
+- ranges        : <prop-encoded-array>
+                  A standard property. Utilized to describe the memory mapped
+                  I/O space utilized by the controller.  The size should
+                  be set to the total size of the register space of all
+                  physically present PAMU controllers.  For example, for
+                  PAMU v1.0, on an SOC that has five PAMU devices, the size
+                  is 0x5000.
+- interrupts    : <prop-encoded-array>
+                  Interrupt mappings.  The first tuple is the normal PAMU
+                  interrupt, used for reporting access violations.  The second
+                  is for PAMU hardware errors, such as PAMU operation errors
+                  and ECC errors.
+- #address-cells: <u32>
+                  A standard property.
+- #size-cells   : <u32>
+                  A standard property.
+
+Optional properties:
+- reg           : <prop-encoded-array>
+                  A standard property.   It represents the CCSR registers of
+                  all child PAMUs combined.  Include it to provide support
+                  for legacy drivers.
+- interrupt-parent : <phandle>
+                  Phandle to interrupt controller
+
+Child nodes:
+
+Each child node represents one PAMU controller.  Each SOC device that is
+connected to a specific PAMU device should have a "fsl,pamu-phandle" property
+that links to the corresponding specific child PAMU controller.
+
+- reg           : <prop-encoded-array>
+                  A standard property.  Specifies the physical address and
+                  length (relative to the parent 'ranges' property) of this
+                  PAMU controller's configuration registers.  The size should
+                  be set to the size of this PAMU controllers's register space.
+                  For PAMU v1.0, this size is 0x1000.
+- fsl,primary-cache-geometry
+                : <prop-encoded-array>
+                  Two cells that specify the geometry of the primary PAMU
+                  cache.  The first is the number of cache lines, and the
+                  second is the number of "ways".  For direct-mapped caches,
+                  specify a value of 1.
+- fsl,secondary-cache-geometry
+                : <prop-encoded-array>
+                  Two cells that specify the geometry of the secondary PAMU
+                  cache.  The first is the number of cache lines, and the
+                  second is the number of "ways".  For direct-mapped caches,
+                  specify a value of 1.
+
+Device nodes:
+
+Devices that have LIODNs need to specify links to the parent PAMU controller
+(the actual PAMU controller that this device is connected to) and a pointer to
+the LIODN register, if applicable.
+
+- fsl,iommu-parent
+                : <phandle>
+                Phandle to the single, specific PAMU controller node to which
+                this device is connect.  The PAMU topology is represented in
+                the device tree to assist code that dynamically determines the
+                best LIODN values to minimize PAMU cache thrashing.
+
+- fsl,liodn-reg : <prop-encoded-array>
+                  Two cells that specify the location of the LIODN register
+                  for this device.  Required for devices that have a single
+                  LIODN.  The first cell is a phandle to a node that contains
+                  the registers where the LIODN is to be set.  The second is
+                  the offset from the first "reg" resource of the node where
+                  the specific LIODN register is located.
+
+
+Example:
+
+        iommu@20000 {
+                compatible = "fsl,pamu-v1.0", "fsl,pamu";
+                reg = <0x20000 0x5000>;
+                ranges = <0 0x20000 0x5000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                interrupts = <
+                        24 2 0 0
+                        16 2 1 30>;
+
+                pamu0: pamu@0 {
+                        reg = <0 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+
+                pamu1: pamu@1000 {
+                        reg = <0x1000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+
+                pamu2: pamu@2000 {
+                        reg = <0x2000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+
+                pamu3: pamu@3000 {
+                        reg = <0x3000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+
+                pamu4: pamu@4000 {
+                        reg = <0x4000 0x1000>;
+                        fsl,primary-cache-geometry = <32 1>;
+                        fsl,secondary-cache-geometry = <128 2>;
+                };
+        };
+
+        guts: global-utilities@e0000 {
+                compatible = "fsl,qoriq-device-config-1.0";
+                reg = <0xe0000 0xe00>;
+                fsl,has-rstcr;
+                #sleep-cells = <1>;
+                fsl,liodn-bits = <12>;
+        };
+
+/include/ "qoriq-dma-0.dtsi"
+        dma@100300 {
+                fsl,iommu-parent = <&pamu0>;
+                fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
+        };
diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt
index ffa4183fdb8b..ae09df8722c8 100644
--- a/Documentation/powerpc/cpu_features.txt
+++ b/Documentation/powerpc/cpu_features.txt
@@ -11,10 +11,10 @@ split instruction and data caches, and if the CPU supports the DOZE and NAP
 sleep modes.
 
 Detection of the feature set is simple. A list of processors can be found in
-arch/ppc/kernel/cputable.c. The PVR register is masked and compared with each
-value in the list. If a match is found, the cpu_features of cur_cpu_spec is
-assigned to the feature bitmask for this processor and a __setup_cpu function
-is called.
+arch/powerpc/kernel/cputable.c. The PVR register is masked and compared with
+each value in the list. If a match is found, the cpu_features of cur_cpu_spec
+is assigned to the feature bitmask for this processor and a __setup_cpu
+function is called.
 
 C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
 particular feature bit. This is done in quite a few places, for example
@@ -51,6 +51,6 @@ should be used in the majority of cases.
 
 The END_FTR_SECTION macros are implemented by storing information about this
 code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
-(arch/ppc/kernel/misc.S) is invoked, it will iterate over the records in
+(arch/powerpc/kernel/misc.S) is invoked, it will iterate over the records in
 __ftr_fixup, and if the required feature is not present it will loop writing
 nop's from each BEGIN_FTR_SECTION to END_FTR_SECTION.
diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt
new file mode 100644
index 000000000000..c907be41d60f
--- /dev/null
+++ b/Documentation/powerpc/transactional_memory.txt
@@ -0,0 +1,175 @@
+Transactional Memory support
+============================
+
+POWER kernel support for this feature is currently limited to supporting
+its use by user programs.  It is not currently used by the kernel itself.
+
+This file aims to sum up how it is supported by Linux and what behaviour you
+can expect from your user programs.
+
+
+Basic overview
+==============
+
+Hardware Transactional Memory is supported on POWER8 processors, and is a
+feature that enables a different form of atomic memory access.  Several new
+instructions are presented to delimit transactions; transactions are
+guaranteed to either complete atomically or roll back and undo any partial
+changes.
+
+A simple transaction looks like this:
+
+begin_move_money:
+  tbegin
+  beq   abort_handler
+
+  ld    r4, SAVINGS_ACCT(r3)
+  ld    r5, CURRENT_ACCT(r3)
+  subi  r5, r5, 1
+  addi  r4, r4, 1
+  std   r4, SAVINGS_ACCT(r3)
+  std   r5, CURRENT_ACCT(r3)
+
+  tend
+
+  b     continue
+
+abort_handler:
+  ... test for odd failures ...
+
+  /* Retry the transaction if it failed because it conflicted with
+   * someone else: */
+  b     begin_move_money
+
+
+The 'tbegin' instruction denotes the start point, and 'tend' the end point.
+Between these points the processor is in 'Transactional' state; any memory
+references will complete in one go if there are no conflicts with other
+transactional or non-transactional accesses within the system.  In this
+example, the transaction completes as though it were normal straight-line code
+IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
+atomic move of money from the current account to the savings account has been
+performed.  Even though the normal ld/std instructions are used (note no
+lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
+updated, or neither will be updated.
+
+If, in the meantime, there is a conflict with the locations accessed by the
+transaction, the transaction will be aborted by the CPU.  Register and memory
+state will roll back to that at the 'tbegin', and control will continue from
+'tbegin+4'.  The branch to abort_handler will be taken this second time; the
+abort handler can check the cause of the failure, and retry.
+
+Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
+and a few other status/flag regs; see the ISA for details.
+
+Causes of transaction aborts
+============================
+
+- Conflicts with cache lines used by other processors
+- Signals
+- Context switches
+- See the ISA for full documentation of everything that will abort transactions.
+
+
+Syscalls
+========
+
+Performing syscalls from within transaction is not recommended, and can lead
+to unpredictable results.
+
+Syscalls do not by design abort transactions, but beware: The kernel code will
+not be running in transactional state.  The effect of syscalls will always
+remain visible, but depending on the call they may abort your transaction as a
+side-effect, read soon-to-be-aborted transactional data that should not remain
+invisible, etc.  If you constantly retry a transaction that constantly aborts
+itself by calling a syscall, you'll have a livelock & make no progress.
+
+Simple syscalls (e.g. sigprocmask()) "could" be OK.  Even things like write()
+from, say, printf() should be OK as long as the kernel does not access any
+memory that was accessed transactionally.
+
+Consider any syscalls that happen to work as debug-only -- not recommended for
+production use.  Best to queue them up till after the transaction is over.
+
+
+Signals
+=======
+
+Delivery of signals (both sync and async) during transactions provides a second
+thread state (ucontext/mcontext) to represent the second transactional register
+state.  Signal delivery 'treclaim's to capture both register states, so signals
+abort transactions.  The usual ucontext_t passed to the signal handler
+represents the checkpointed/original register state; the signal appears to have
+arisen at 'tbegin+4'.
+
+If the sighandler ucontext has uc_link set, a second ucontext has been
+delivered.  For future compatibility the MSR.TS field should be checked to
+determine the transactional state -- if so, the second ucontext in uc->uc_link
+represents the active transactional registers at the point of the signal.
+
+For 64-bit processes, uc->uc_mcontext.regs->msr is a full 64-bit MSR and its TS
+field shows the transactional mode.
+
+For 32-bit processes, the mcontext's MSR register is only 32 bits; the top 32
+bits are stored in the MSR of the second ucontext, i.e. in
+uc->uc_link->uc_mcontext.regs->msr.  The top word contains the transactional
+state TS.
+
+However, basic signal handlers don't need to be aware of transactions
+and simply returning from the handler will deal with things correctly:
+
+Transaction-aware signal handlers can read the transactional register state
+from the second ucontext.  This will be necessary for crash handlers to
+determine, for example, the address of the instruction causing the SIGSEGV.
+
+Example signal handler:
+
+    void crash_handler(int sig, siginfo_t *si, void *uc)
+    {
+      ucontext_t *ucp = uc;
+      ucontext_t *transactional_ucp = ucp->uc_link;
+
+      if (ucp_link) {
+        u64 msr = ucp->uc_mcontext.regs->msr;
+        /* May have transactional ucontext! */
+#ifndef __powerpc64__
+        msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
+#endif
+        if (MSR_TM_ACTIVE(msr)) {
+           /* Yes, we crashed during a transaction.  Oops. */
+   fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
+                           "crashy instruction was at 0x%llx\n",
+                           ucp->uc_mcontext.regs->nip,
+                           transactional_ucp->uc_mcontext.regs->nip);
+        }
+      }
+
+      fix_the_problem(ucp->dar);
+    }
+
+
+Failure cause codes used by kernel
+==================================
+
+These are defined in <asm/reg.h>, and distinguish different reasons why the
+kernel aborted a transaction:
+
+ TM_CAUSE_RESCHED       Thread was rescheduled.
+ TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.
+ TM_CAUSE_SYSCALL       Currently unused; future syscalls that must abort
+                        transactions for consistency will use this.
+ TM_CAUSE_SIGNAL        Signal delivered.
+ TM_CAUSE_MISC          Currently unused.
+
+These can be checked by the user program's abort handler as TEXASR[0:7].
+
+
+GDB
+===
+
+GDB and ptrace are not currently TM-aware.  If one stops during a transaction,
+it looks like the transaction has just started (the checkpointed state is
+presented).  The transaction cannot then be continued and will take the failure
+handler route.  Furthermore, the transactional 2nd register state will be
+inaccessible.  GDB can currently be used on programs using TM, but not sensibly
+in parts within transactions.