Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc

   - 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

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>;

   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>;

	};

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 */

	};

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

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.

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.