Merge branch 'ux500/dt' into next/dt2

* ux500/dt:
  ARM: ux500: Provide local timer support for Device Tree
  ARM: ux500: Enable PL022 SSP Controller in Device Tree
  ARM: ux500: Enable PL310 Level 2 Cache Controller in Device Tree
  ARM: ux500: Enable PL011 AMBA UART Controller for Device Tree
  ARM: ux500: Enable Cortex-A9 GIC (Generic Interrupt Controller) in Device Tree
  ARM: ux500: db8500: list most devices in the snowball device tree
  ARM: ux500: split dts file for snowball into generic part
  ARM: ux500: combine the board init functions for DT boot
  ARM: ux500: Initial Device Tree support for Snowball
  ARM: ux500: CONFIG: Enable Device Tree support for future endeavours
  ARM: ux500: fix compilation after local timer rework

(adds dependency on localtimer branch, irqdomain branch and ux500/soc
branch)

Conflicts:
	arch/arm/mach-ux500/devices-common.c

This adds patches from Lee Jones, Niklas Hernaeus and myself to provide
initial device tree support on the ux500 platform. The pull request from
Lee contained some other changes, so I rebased the patches on top of
the branches that are actually dependencies for this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

4 files changed, 122 insertions, 19 deletions

diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc
new file mode 100644
index 000000000000..6d9cc253f2b2
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@@ -0,0 +1,58 @@
+What:           /sys/devices/socX
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                The /sys/devices/ directory contains a sub-directory for each
+                System-on-Chip (SoC) device on a running platform. Information
+                regarding each SoC can be obtained by reading sysfs files. This
+                functionality is only available if implemented by the platform.
+
+                The directory created for each SoC will also house information
+                about devices which are commonly contained in /sys/devices/platform.
+                It has been agreed that if an SoC device exists, its supported
+                devices would be better suited to appear as children of that SoC.
+
+What:           /sys/devices/socX/machine
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute common to all SoCs. Contains the SoC machine
+                name (e.g. Ux500).
+
+What:           /sys/devices/socX/family
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute common to all SoCs. Contains SoC family name
+                (e.g. DB8500).
+
+What:           /sys/devices/socX/soc_id
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute supported by most SoCs. In the case of
+                ST-Ericsson's chips this contains the SoC serial number.
+
+What:           /sys/devices/socX/revision
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute supported by most SoCs. Contains the SoC's
+                manufacturing revision number.
+
+What:           /sys/devices/socX/process
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                Read-only attribute supported ST-Ericsson's silicon. Contains the
+                the process by which the silicon chip was manufactured.
+
+What:           /sys/bus/soc
+Date:           January 2012
+contact:        Lee Jones <lee.jones@linaro.org>
+Description:
+                The /sys/bus/soc/ directory contains the usual sub-folders
+                expected under most buses. /sys/bus/soc/devices is of particular
+                interest, as it contains a symlink for each SoC device found on
+                the system. Each symlink points back into the aforementioned
+                /sys/devices/socX devices.
diff --git a/Documentation/devicetree/bindings/arm/twd.txt b/Documentation/devicetree/bindings/arm/twd.txt
new file mode 100644
index 000000000000..75b8610939fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/twd.txt
@@ -0,0 +1,48 @@
+* ARM Timer Watchdog
+
+ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
+Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
+and watchdog.
+
+The TWD is usually attached to a GIC to deliver its two per-processor
+interrupts.
+
+** Timer node required properties:
+
+- compatible : Should be one of:
+        "arm,cortex-a9-twd-timer"
+        "arm,cortex-a5-twd-timer"
+        "arm,arm11mp-twd-timer"
+
+- interrupts : One interrupt to each core
+
+- reg : Specify the base address and the size of the TWD timer
+        register window.
+
+Example:
+
+        twd-timer@2c000600 {
+                compatible = "arm,arm11mp-twd-timer"";
+                reg = <0x2c000600 0x20>;
+                interrupts = <1 13 0xf01>;
+        };
+
+** Watchdog node properties:
+
+- compatible : Should be one of:
+        "arm,cortex-a9-twd-wdt"
+        "arm,cortex-a5-twd-wdt"
+        "arm,arm11mp-twd-wdt"
+
+- interrupts : One interrupt to each core
+
+- reg : Specify the base address and the size of the TWD watchdog
+        register window.
+
+Example:
+
+        twd-watchdog@2c000620 {
+                compatible = "arm,arm11mp-twd-wdt";
+                reg = <0x2c000620 0x20>;
+                interrupts = <1 14 0xf01>;
+        };
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index f959909d7154..74e6c7782678 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -12,7 +12,7 @@ dynamically enabled per-callsite.
 Dynamic debug has even more useful features:
 
  * Simple query language allows turning on and off debugging statements by
-   matching any combination of:
+   matching any combination of 0 or 1 of:
 
    - source filename
    - function name
@@ -79,31 +79,24 @@ Command Language Reference
 ==========================
 
 At the lexical level, a command comprises a sequence of words separated
-by whitespace characters.  Note that newlines are treated as word
-separators and do *not* end a command or allow multiple commands to
-be done together.  So these are all equivalent:
+by spaces or tabs.  So these are all equivalent:
 
 nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' >
                                 <debugfs>/dynamic_debug/control
 nullarbor:~ # echo -c '  file   svcsock.c     line  1603 +p  ' >
                                 <debugfs>/dynamic_debug/control
-nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' >
-                                <debugfs>/dynamic_debug/control
 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
                                 <debugfs>/dynamic_debug/control
 
-Commands are bounded by a write() system call.  If you want to do
-multiple commands you need to do a separate "echo" for each, like:
+Command submissions are bounded by a write() system call.
+Multiple commands can be written together, separated by ';' or '\n'.
 
-nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\
-> echo 'file svcsock.c line 1563 +p' > /proc/dprintk
+  ~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \
+     > <debugfs>/dynamic_debug/control
 
-or even like:
+If your query set is big, you can batch them too:
 
-nullarbor:~ # (
-> echo 'file svcsock.c line 1603 +p' ;\
-> echo 'file svcsock.c line 1563 +p' ;\
-> ) > /proc/dprintk
+  ~# cat query-batch-file > <debugfs>/dynamic_debug/control
 
 At the syntactical level, a command comprises a sequence of match
 specifications, followed by a flags change specification.
@@ -144,11 +137,12 @@ func
     func svc_tcp_accept
 
 file
-    The given string is compared against either the full
-    pathname or the basename of the source file of each
-    callsite.  Examples:
+    The given string is compared against either the full pathname, the
+    src-root relative pathname, or the basename of the source file of
+    each callsite.  Examples:
 
     file svcsock.c
+    file kernel/freezer.c
     file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
 
 module
diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt
index 6872c91bce35..4e2575873187 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -14,7 +14,10 @@ Debugfs is typically mounted with a command like:
 
     mount -t debugfs none /sys/kernel/debug
 
-(Or an equivalent /etc/fstab line). 
+(Or an equivalent /etc/fstab line).
+The debugfs root directory is accessible by anyone by default. To
+restrict access to the tree the "uid", "gid" and "mode" mount
+options can be used.
 
 Note that the debugfs API is exported GPL-only to modules.