Merge branch 'tracking-ll-last-minute-fixes' into merge-linux-linaro
diff --git a/Documentation/devicetree/bindings/arm/freescale.txt b/Documentation/devicetree/bindings/arm/freescale.txt
new file mode 100644
index 0000000..8c52102
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale.txt
@@ -0,0 +1,7 @@
+mx51 "Babbage" evalutation board
+Required root node properties:
+ - compatible = "fsl,mx51-babbage", "fsl,mx51";
+
+mx53 "Loco" evaluation board
+Required root node properties:
+ - compatible = "fsl,mx53-loco", "fsl,mx53";
diff --git a/Documentation/devicetree/bindings/arm/genesi.txt b/Documentation/devicetree/bindings/arm/genesi.txt
new file mode 100644
index 0000000..b353489
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/genesi.txt
@@ -0,0 +1,8 @@
+Genesi EfikaMX based on Freescale mx51
+Required root node properties:
+ - compatible = "genesi,efikamx", "fsl,mx51";
+
+Genesi EfikaMX Smartbook based on Freescale mx51
+Required root node properties:
+ - compatible = "genesi,efikasb", "fsl,mx51";
+
diff --git a/Documentation/devicetree/usage-model b/Documentation/devicetree/usage-model
new file mode 100644
index 0000000..45e03b8
--- /dev/null
+++ b/Documentation/devicetree/usage-model
@@ -0,0 +1,403 @@
+Linux and the Device Tree
+The Linux usage model for device tree data
+
+Author: Grant Likely <grant.likely@secretlab.ca>
+
+This article describes how Linux uses the device tree. An overview of
+the device tree data format can be found at the <a
+href="http://devicetree.org/Device_Tree_Usage">Device Tree Usage</a>
+page on <a href="http://devicetree.org">devicetree.org</a>.
+
+
+ All the cool architectures are using device tree. I want to
+ use device tree too!
+
+The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
+structure and language for describing hardware. More specifically, it
+is a description of hardware that is readable by an operating system
+so that the operating system doesn't need to hard code details of the
+machine.
+
+Structurally, the DT is a tree, or acyclic graph with named nodes, and
+nodes may have an arbitrary number of named properties encapsulating
+arbitrary data. A mechanism also exists to create arbitrary
+links from one node to another outside of the natural tree structure.
+
+Conceptually, a common set of usage conventions, called 'bindings',
+is defined for how data should appear in the tree to describe typical
+hardware characteristics including data busses, interrupt lines, GPIO
+connections, and peripheral devices.
+
+As much as possible, hardware is described using existing bindings to
+maximize use of existing support code, but since property and node
+names are simply text strings, it is easy to extend existing bindings
+or create new ones by defining new nodes and properties.
+
+<h2>History</h2>
+The DT was originally created by Open Firmware as part of the
+communication method for passing data from Open Firmware to a client
+program (like to an operating system). An operating system used the
+Device Tree to discover the topology of the hardware at runtime, and
+thereby support a majority of available hardware without hard coded
+information (assuming drivers were available for all devices).
+
+Since Open Firmware is commonly used on PowerPC and SPARC platforms,
+the Linux support for those architectures has for a long time used the
+Device Tree.
+
+In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
+and 64-bit support, the decision was made to require DT support on all
+powerpc platforms, regardless of whether or not they used Open
+Firmware. To do this, a DT representation called the Flattened Device
+Tree (FDT) was created which could be passed to the kernel as a binary
+blob without requiring a real Open Firmware implementation. U-Boot,
+kexec, and other bootloaders were modified to support both passing a
+Device Tree Binary (dtb) and to modify a dtb at boot time.
+
+Some time later, FDT infrastructure was generalized to be usable by
+all architectures. At the time of this writing, 6 mainlined
+architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1
+out of mainline (nios) have some level of DT support.
+
+<h2>Data Model</h2>
+If you haven't already read the
+href="http://devicetree.org/Device_Tree_Usage">Device Tree Usage</a>
+page, then go read it now. It's okay, I'll wait....
+
+<h3>High Level View</h3>
+The most important thing to understand is that the DT is simply a data
+structure that describes the hardware. There is nothing magical about
+it, and it doesn't magically make all hardware configuration problems
+go away. What it does do is provide a language for decoupling the
+hardware configuration from the board and device driver support in the
+Linux kernel (or any other operating system for that matter). Using
+it allows board and device support to become data driven; to make
+setup decisions based on data passed into the kernel instead of on
+per-machine hard coded selections.
+
+Ideally, data driven platform setup should result in less code
+duplication and make it easier to support a wide range of hardware
+with a single kernel image.
+
+Linux uses DT data for three major purposes:
+1) platform identification,
+2) runtime configuration, and
+3) device population.
+
+<h4>Platform Identification</h4>
+First and foremost, the kernel will use data in the DT to identify the
+specific machine. In a perfect world, the specific platform shouldn't
+matter to the kernel because all platform details would be described
+perfectly by the device tree in a consistent and reliable manner.
+Hardware is not perfect though, and so the kernel must identify the
+machine during early boot so that it has the opportunity to run
+machine-specific fixups.
+
+In the majority of cases, the machine identity is irrelevant, and the
+kernel will instead select setup code based on the machine's core
+CPU or SoC. On ARM for example, setup_arch() in
+arch/arm/kernel/setup.c will call setup_machine_fdt() in
+arch/arm/kernel/devicetree.c which searches through the machine_desc
+table and selects the machine_desc which best matches the device tree
+data. It determines the best match by looking at the 'compatible'
+property in the root device tree node, and comparing it with the
+dt_compat list in struct machine_desc.
+
+The 'compatible' property contains a sorted list of strings starting
+with the exact name of the machine, followed by an optional list of
+boards it is compatible with sorted from most compatible to least. For
+example, the root compatible properties for the TI BeagleBoard and its
+successor, the BeagleBoard xM board might look like:
+
+ compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
+ compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
+
+Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
+claims that it compatible with the OMAP 3450 SoC, and the omap3 family
+of SoCs in general. You'll notice that the list is sorted from most
+specific (exact board) to least specific (SoC family).
+
+Astute readers might point out that the Beagle xM could also claim
+compatibility with the original Beagle board. However, one should be
+cautioned about doing so at the board level since there is typically a
+high level of change from one board to another, even within the same
+product line, and it is hard to nail down exactly what is meant when one
+board claims to be compatible with another. For the top level, it is
+better to err on the side of caution and not claim one board is
+compatible with another. The notable exception would be when one
+board is a carrier for another, such as a CPU module attached to a
+carrier board.
+
+One more note on compatible values. Any string used in a compatible
+property must be documented as to what it indicates. Add
+documentation for compatible strings in Documentation/devicetree/bindings.
+
+Again on ARM, for each machine_desc, the kernel looks to see if
+any of the dt_compat list entries appear in the compatible property.
+If one does, then that machine_desc is a candidate for driving the
+machine. After searching the entire table of machine_descs,
+setup_machine_fdt() returns the 'most compatible' machine_desc based
+on which entry in the compatible property each machine_desc matches
+against. If no matching machine_desc is found, then it returns NULL.
+
+The reasoning behind this scheme is the observation that in the majority
+of cases, a single machine_desc can support a large number of boards
+if they all use the same SoC, or same family of SoCs. However,
+invariably there will be some exceptions where a specific board will
+require special setup code that is not useful in the generic case.
+Special cases could be handled by explicitly checking for the
+troublesome board(s) in generic setup code, but doing so very quickly
+becomes ugly and/or unmaintainable if it is more than just a couple of
+cases.
+
+Instead, the compatible list allows a generic machine_desc to provide
+support for a wide common set of boards by specifying "less
+compatible" value in the dt_compat list. In the example above,
+generic board support can claim compatibility with "ti,omap3" or
+"ti,omap3450". If a bug was discovered on the original beagleboard
+that required special workaround code during early boot, then a new
+machine_desc could be added which implements the workarounds and only
+matches on "ti,omap3-beagleboard".
+
+PowerPC uses a slightly different scheme where it calls the .probe()
+hook from each machine_desc, and the first one returning TRUE is used.
+However, this approach does not take into account the priority of the
+compatible list, and probably should be avoided for new architecture
+support.
+
+<h4>Runtime configuration</h4>
+In most cases, a DT will be the sole method of communicating data from
+firmware to the kernel, so also gets used to pass in runtime and
+configuration data like the kernel parameters string and the location
+of an initrd image.
+
+Most of this data is contained in the /chosen node, and when booting
+Linux it will look something like this:
+
+ chosen {
+ bootargs = "console=ttyS0,115200 loglevel=8";
+ initrd-start = <0xc8000000>;
+ initrd-end = <0xc8200000>;
+ };
+
+The bootargs property contains the kernel arguments, and the initrd-*
+properties define the address and size of an initrd blob. The
+chosen node may also optionally contain an arbitrary number of
+additional properties for platform-specific configuration data.
+
+During early boot, the architecture setup code calls of_scan_flat_dt()
+several times with different helper callbacks to parse device tree
+data before paging is setup. The of_scan_flat_dt() code scans through
+the device tree and uses the helpers to extract information required
+during early boot. Typically the early_init_dt_scan_chosen() helper
+is used to parse the chosen node including kernel parameters,
+early_init_dt_scan_root() to initialize the DT address space model,
+and early_init_dt_scan_memory() to determine the size and
+location of usable RAM.
+
+On ARM, the function setup_machine_fdt() is responsible for early
+scanning of the device tree after selecting the correct machine_desc
+that supports the board.
+
+<h4>Device population</h4>
+After the board has been identified, and after the early configuration data
+has been parsed, then kernel initialization can proceed in the normal
+way. At some point in this process, unflatten_device_tree() is called
+to convert the data into a more efficient runtime representation.
+This is also when machine-specific setup hooks will get called, like
+the machine_desc .init_early(), .init_irq() and .init_machine() hooks
+on ARM. The remainder of this section uses examples from the ARM
+implementation, but all architectures will do pretty much the same
+thing when using a DT.
+
+As can be guessed by the names, .init_early() is used for any machine-
+specific setup that needs to be executed early in the boot process,
+and .init_irq() is used to set up interrupt handling. Using a DT
+doesn't materially change the behaviour of either of these functions.
+If a DT is provided, then both .init_early() and .init_irq() are able
+to call any of the DT query functions (of_* in include/linux/of*.h) to
+get additional data about the platform.
+
+The most interesting hook in the DT context is .init_machine() which
+is primarily responsible for populating the Linux device model with
+data about the platform. Historically this has been implemented on
+embedded platforms by defining a set of static clock structures,
+platform_devices, and other data in the board support .c file, and
+registering it en-masse in .init_machine(). When DT is used, then
+instead of hard coding static devices for each platform, the list of
+devices can be obtained by parsing the DT, and allocating device
+structures dynamically.
+
+The simplest case is when .init_machine() is only responsible for
+registering a block of platform_devices. A platform_device is a concept
+used by Linux for memory or I/O mapped devices which cannot be detected
+by hardware, and for 'composite' or 'virtual' devices (more on those
+later). While there is no 'platform device' terminology for the DT,
+platform devices roughly correspond to device nodes at the root of the
+tree and children of simple memory mapped bus nodes.
+
+About now is a good time to lay out an example. Here is part of the
+device tree for the NVIDIA Tegra board.
+
+/{
+ compatible = "nvidia,harmony", "nvidia,tegra20";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ chosen { };
+ aliases { };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>;
+ };
+
+ soc {
+ compatible = "nvidia,tegra20-soc", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ intc: interrupt-controller@50041000 {
+ compatible = "nvidia,tegra20-gic";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >;
+ };
+
+ serial@70006300 {
+ compatible = "nvidia,tegra20-uart";
+ reg = <0x70006300 0x100>;
+ interrupts = <122>;
+ };
+
+ i2s-1: i2s@70002800 {
+ compatible = "nvidia,tegra20-i2s";
+ reg = <0x70002800 0x100>;
+ interrupts = <77>;
+ codec = <&wm8903>;
+ };
+
+ i2c@7000c000 {
+ compatible = "nvidia,tegra20-i2c";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x7000c000 0x100>;
+ interrupts = <70>;
+
+ wm8903: codec@1a {
+ compatible = "wlf,wm8903";
+ reg = <0x1a>;
+ interrupts = <347>;
+ };
+ };
+ };
+
+ sound {
+ compatible = "nvidia,harmony-sound";
+ i2s-controller = <&i2s-1>;
+ i2s-codec = <&wm8903>;
+ };
+};
+
+At .machine_init() time, Tegra board support code will need to look at
+this DT and decide which nodes to create platform_devices for.
+However, looking at the tree, it is not immediately obvious what kind
+of device each node represents, or even if a node represents a device
+at all. The /chosen, /aliases, and /memory nodes are informational
+nodes that don't describe devices (although arguably memory could be
+considered a device). The children of the /soc node are memory mapped
+devices, but the codec@1a is an i2c device, and the sound node
+represents not a device, but rather how other devices are connected
+together to create the audio subsystem. I know what each device is
+because I'm familiar with the board design, but how does the kernel
+know what to do with each node?
+
+The trick is that the kernel starts at the root of the tree and looks
+for nodes that have a 'compatible' property. First, it is generally
+assumed that any node with a 'compatible' property represents a device
+of some kind, and second, it can be assumed that any node at the root
+of the tree is either directly attached to the processor bus, or is a
+miscellaneous system device that cannot be described any other way.
+For each of these nodes, Linux allocates and registers a
+platform_device, which in turn may get bound to a platform_driver.
+
+Why is using a platform_device for these nodes a safe assumption?
+Well, for the way that Linux models devices, just about all bus_types
+assume that its devices are children of a bus controller. For
+example, each i2c_client is a child of an i2c_master. Each spi_device
+is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The
+same hierarchy is also found in the DT, where I2C device nodes only
+ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB,
+etc. The only devices which do not require a specific type of parent
+device are platform_devices (and amba_devices, but more on that
+later), which will happily live at the base of the Linux /sys/devices
+tree. Therefore, if a DT node is at the root of the tree, then it
+really probably is best registered as a platform_device.
+
+Linux board support code calls of_platform_populate(NULL, NULL, NULL)
+to kick off discovery of devices at the root of the tree. The
+parameters are all NULL because when starting from the root of the
+tree, there is no need to provide a starting node (the first NULL), a
+parent struct device (the last NULL), and we're not using a match
+table (yet). For a board that only needs to register devices,
+.init_machine() can be completely empty except for the
+of_platform_populate() call.
+
+In the Tegra example, this accounts for the /soc and /sound nodes, but
+what about the children of the SoC node? Shouldn't they be registered
+as platform devices too? For Linux DT support, the generic behaviour
+is for child devices to be registered by the parent's device driver at
+driver .probe() time. So, an i2c bus device driver will register a
+i2c_client for each child node, an SPI bus driver will register
+its spi_device children, and similarly for other bus_types.
+According to that model, a driver could be written that binds to the
+SoC node and simply registers platform_devices for each of its
+children. The board support code would allocate and register an SoC
+device, an SoC device driver would bind to the SoC device, and
+register platform_devices for /soc/interrupt-controller, /soc/serial,
+/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right? Although
+it is a lot of mucking about for just registering platform devices.
+
+It turns out that registering children of certain platform_devices as
+more platform_devices is a common pattern, and the device tree support
+code reflects that. The second argument to of_platform_populate() is
+an of_device_id table, and any node that matches an entry in that
+table will also get its child nodes registered. In the tegra case,
+the code can look something like this:
+
+static struct of_device_id harmony_bus_ids[] __initdata = {
+ { .compatible = "simple-bus", },
+ {}
+};
+
+static void __init harmony_init_machine(void)
+{
+ /* ... */
+ of_platform_populate(NULL, harmony_bus_ids, NULL);
+}
+
+"simple-bus" is defined in the ePAPR 1.0 specification as a property
+meaning a simple memory mapped bus, so the of_platform_populate() code
+could be written to just assume simple-bus compatible nodes will
+always be traversed. However, we pass it in as an argument so that
+board support code can always override the default behaviour.
+
+<h2>Appendix A: AMBA devices</h2>
+
+ARM Primecells are a certain kind of device attached to the ARM AMBA
+bus which include some support for hardware detection and power
+management. In Linux, struct amba_device and the amba_bus_type is
+used to represent Primecell devices. However, the fiddly bit is that
+not all devices on an AMBA bus are Primecells, and for Linux it is
+typical for both amba_device and platform_device instances to be
+siblings of the same bus segment.
+
+When using the DT, this creates problems for of_platform_populate()
+because it must decide whether to register each node as either a
+platform_device or an amba_device. This unfortunately complicates the
+device creation model a little bit, but the solution turns out not to
+be too invasive. If a node is compatible with "arm,amba-primecell", then
+of_platform_populate() will register it as an amba_device instead of a
+platform_device.
diff --git a/arch/arm/boot/dts/genesi-efikamx.dts b/arch/arm/boot/dts/genesi-efikamx.dts
new file mode 100644
index 0000000..e81ffcc
--- /dev/null
+++ b/arch/arm/boot/dts/genesi-efikamx.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Genesi EfikaMX nettop";
+ compatible = "genesi,efikamx", "fsl,mx51";
+
+ memory {
+ reg = <0x90000000 0x20000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/genesi-efikasb.dts b/arch/arm/boot/dts/genesi-efikasb.dts
new file mode 100644
index 0000000..9fda6ae
--- /dev/null
+++ b/arch/arm/boot/dts/genesi-efikasb.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Genesi Efika Smartbook";
+ compatible = "genesi,efikasb", "fsl,mx51";
+
+ memory {
+ reg = <0x90000000 0x20000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/isee-igep-v2.dts b/arch/arm/boot/dts/isee-igep-v2.dts
new file mode 100644
index 0000000..72caabb
--- /dev/null
+++ b/arch/arm/boot/dts/isee-igep-v2.dts
@@ -0,0 +1,7 @@
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "ISSE IGEPv2 Board";
+ compatible = "ISEE,igep-v2";
+};
diff --git a/arch/arm/boot/dts/isee-igep-v3.dts b/arch/arm/boot/dts/isee-igep-v3.dts
new file mode 100644
index 0000000..f40886f
--- /dev/null
+++ b/arch/arm/boot/dts/isee-igep-v3.dts
@@ -0,0 +1,7 @@
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "ISSE IGEPv3 Module";
+ compatible = "ISEE,igep-v3";
+};
diff --git a/arch/arm/boot/dts/mx51-babbage.dts b/arch/arm/boot/dts/mx51-babbage.dts
new file mode 100644
index 0000000..e5e9c89
--- /dev/null
+++ b/arch/arm/boot/dts/mx51-babbage.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Freescale i.MX51 Babbage";
+ compatible = "fsl,mx51-babbage", "fsl,mx51";
+
+ memory {
+ reg = <0x90000000 0x20000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/mx53-loco.dts b/arch/arm/boot/dts/mx53-loco.dts
new file mode 100644
index 0000000..8426c62
--- /dev/null
+++ b/arch/arm/boot/dts/mx53-loco.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Freescale i.MX53 LOCO";
+ compatible = "fsl,mx53-loco", "fsl,mx53";
+
+ memory {
+ reg = <0x70000000 0x40000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dts b/arch/arm/boot/dts/omap3-overo.dts
new file mode 100644
index 0000000..c61f011
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-overo.dts
@@ -0,0 +1,7 @@
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Gumstix Overo";
+ compatible = "gumstix,omap3-overo";
+};
diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index 42e5bf4..18361a9 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -458,6 +458,8 @@
TEST_UNSUPPORTED(".word 0xe1700090") /* Unallocated space */
#ifdef CONFIG_CPU_32v6K
TEST_UNSUPPORTED("ldrex r2, [sp]")
+#endif
+#if __LINUX_ARM_ARCH__ >= 7
TEST_UNSUPPORTED("strexd r0, r2, r3, [sp]")
TEST_UNSUPPORTED("ldrexd r2, r3, [sp]")
TEST_UNSUPPORTED("strexb r0, r2, [sp]")
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
index 05541cf..2e63463 100644
--- a/arch/arm/mach-imx/Makefile.boot
+++ b/arch/arm/mach-imx/Makefile.boot
@@ -30,10 +30,16 @@
params_phys-$(CONFIG_SOC_IMX51) := 0x90000100
initrd_phys-$(CONFIG_SOC_IMX51) := 0x90800000
+dtb-$(CONFIG_MACH_MX51_BABBAGE) += mx51-babbage.dtb
+dtb-$(CONFIG_MACH_MX51_EFIKAMX) += genesi-efikamx.dtb
+dtb-$(CONFIG_MACH_MX51_EFIKASB) += genesi-efikasb.dtb
+
zreladdr-$(CONFIG_SOC_IMX53) += 0x70008000
params_phys-$(CONFIG_SOC_IMX53) := 0x70000100
initrd_phys-$(CONFIG_SOC_IMX53) := 0x70800000
+dtb-$(CONFIG_MACH_MX53_LOCO) += mx53-loco.dtb
+
zreladdr-$(CONFIG_SOC_IMX6Q) += 0x10008000
params_phys-$(CONFIG_SOC_IMX6Q) := 0x10000100
initrd_phys-$(CONFIG_SOC_IMX6Q) := 0x10800000
diff --git a/arch/arm/mach-imx/mach-mx51_babbage.c b/arch/arm/mach-imx/mach-mx51_babbage.c
index 690c43d..45ead59 100644
--- a/arch/arm/mach-imx/mach-mx51_babbage.c
+++ b/arch/arm/mach-imx/mach-mx51_babbage.c
@@ -423,6 +423,11 @@
.init = mx51_babbage_timer_init,
};
+static const char *mx51_babbage_dt_match[] __initdata = {
+ "fsl,mx51-babbage",
+ NULL
+};
+
MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
/* Maintainer: Amit Kucheria <amit.kucheria@canonical.com> */
.atag_offset = 0x100,
@@ -434,4 +439,5 @@
.init_machine = mx51_babbage_init,
.init_late = imx51_init_late,
.restart = mxc_restart,
+ .dt_compat = mx51_babbage_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx51_efikamx.c b/arch/arm/mach-imx/mach-mx51_efikamx.c
index aa90409..17c191b 100644
--- a/arch/arm/mach-imx/mach-mx51_efikamx.c
+++ b/arch/arm/mach-imx/mach-mx51_efikamx.c
@@ -287,7 +287,13 @@
.init = mx51_efikamx_timer_init,
};
+static const char *mx51_efikamx_dt_match[] __initdata = {
+ "genesi,efikamx",
+ NULL
+};
+
MACHINE_START(MX51_EFIKAMX, "Genesi Efika MX (Smarttop)")
+ /* Maintainer: Amit Kucheria <amit.kucheria@linaro.org> */
.atag_offset = 0x100,
.map_io = mx51_map_io,
.init_early = imx51_init_early,
@@ -297,4 +303,5 @@
.init_machine = mx51_efikamx_init,
.init_late = mx51_efikamx_init_late,
.restart = mx51_efikamx_restart,
+ .dt_compat = mx51_efikamx_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx51_efikasb.c b/arch/arm/mach-imx/mach-mx51_efikasb.c
index 0abb214..767497e 100644
--- a/arch/arm/mach-imx/mach-mx51_efikasb.c
+++ b/arch/arm/mach-imx/mach-mx51_efikasb.c
@@ -283,6 +283,11 @@
.init = mx51_efikasb_timer_init,
};
+static const char *mx51_efikasb_dt_match[] __initdata = {
+ "genesi,efikasb",
+ NULL
+};
+
MACHINE_START(MX51_EFIKASB, "Genesi Efika MX (Smartbook)")
.atag_offset = 0x100,
.map_io = mx51_map_io,
@@ -293,4 +298,5 @@
.init_late = mx51_efikasb_init_late,
.timer = &mx51_efikasb_timer,
.restart = mxc_restart,
+ .dt_compat = mx51_efikasb_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-imx/mach-mx53_loco.c b/arch/arm/mach-imx/mach-mx53_loco.c
index 0e1c75f..360d8cf 100644
--- a/arch/arm/mach-imx/mach-mx53_loco.c
+++ b/arch/arm/mach-imx/mach-mx53_loco.c
@@ -309,6 +309,10 @@
.init = mx53_loco_timer_init,
};
+static const char *mx53_loco_dt_match[] __initdata = {
+ "fsl,mx53-loco",
+ NULL
+};
MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board")
.map_io = mx53_map_io,
.init_early = imx53_init_early,
@@ -317,4 +321,5 @@
.timer = &mx53_loco_timer,
.init_machine = mx53_loco_board_init,
.restart = mxc_restart,
+ .dt_compat = mx53_loco_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-omap2/Makefile.boot b/arch/arm/mach-omap2/Makefile.boot
index b03e562..eab4c41 100644
--- a/arch/arm/mach-omap2/Makefile.boot
+++ b/arch/arm/mach-omap2/Makefile.boot
@@ -1,3 +1,9 @@
zreladdr-y += 0x80008000
params_phys-y := 0x80000100
initrd_phys-y := 0x80800000
+
+dtb-$(CONFIG_MACH_OMAP3_BEAGLE) += omap3-beagle.dtb
+dtb-$(CONFIG_MACH_OMAP4_PANDA) += omap4-panda.dtb
+dtb-$(CONFIG_MACH_OVERO) += omap3-overo.dtb
+dtb-$(CONFIG_MACH_IGEP0020) += isee-igep-v2.dtb
+dtb-$(CONFIG_MACH_IGEP0030) += isee-igep-v3.dtb
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 50dcf41..bb273bc 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -642,6 +642,11 @@
}
}
+static const char *igep2_dt_compat[] = {
+ "ISEE,igep-v2",
+ NULL
+};
+
MACHINE_START(IGEP0020, "IGEP v2 board")
.atag_offset = 0x100,
.reserve = omap_reserve,
@@ -653,8 +658,14 @@
.init_late = omap35xx_init_late,
.timer = &omap3_timer,
.restart = omap_prcm_restart,
+ .dt_compat = igep2_dt_compat,
MACHINE_END
+static const char *igep3_dt_compat[] = {
+ "ISEE,igep-v3",
+ NULL
+};
+
MACHINE_START(IGEP0030, "IGEP OMAP3 module")
.atag_offset = 0x100,
.reserve = omap_reserve,
@@ -666,4 +677,5 @@
.init_late = omap35xx_init_late,
.timer = &omap3_timer,
.restart = omap_prcm_restart,
+ .dt_compat = &igep3_dt_compat,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 0ae87c4..41738a6 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -534,6 +534,11 @@
beagle_opp_init();
}
+static const char *omap3_beagle_dt_match[] = {
+ "ti,omap3-beagle",
+ NULL
+};
+
MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
.atag_offset = 0x100,
@@ -546,4 +551,5 @@
.init_late = omap3_init_late,
.timer = &omap3_secure_timer,
.restart = omap_prcm_restart,
+ .dt_compat = omap3_beagle_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index fe9d565..3f2d3bb 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -512,6 +512,11 @@
omap4_panda_display_init();
}
+static const char *omap4_panda_match[] = {
+ "ti,omap4-panda",
+ NULL,
+};
+
MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board")
/* Maintainer: David Anders - Texas Instruments Inc */
.atag_offset = 0x100,
@@ -524,4 +529,5 @@
.init_late = omap4430_init_late,
.timer = &omap4_timer,
.restart = omap_prcm_restart,
+ .dt_compat = omap4_panda_match,
MACHINE_END
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 85fc445..8fe7782 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -546,6 +546,11 @@
"OVERO_GPIO_USBH_CPEN\n");
}
+static const char *omap3_overo_dt_match[] = {
+ "gumstix,omap3-overo",
+ NULL
+};
+
MACHINE_START(OVERO, "Gumstix Overo")
.atag_offset = 0x100,
.reserve = omap_reserve,
@@ -557,4 +562,5 @@
.init_late = omap35xx_init_late,
.timer = &omap3_timer,
.restart = omap_prcm_restart,
+ .dt_compat = omap3_overo_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
index ff0a4b5..6910b31 100644
--- a/arch/arm/mach-versatile/Makefile.boot
+++ b/arch/arm/mach-versatile/Makefile.boot
@@ -2,3 +2,5 @@
params_phys-y := 0x00000100
initrd_phys-y := 0x00800000
+dtb-$(CONFIG_MACH_VERSATILE_DT) += versatile-pb.dtb
+dtb-$(CONFIG_MACH_VERSATILE_DT) += versatile-ab.dtb
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 343ad29..090f776 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -349,6 +349,7 @@
struct platform_device *dev;
const char *bus_id = NULL;
void *platform_data = NULL;
+ int id = -1;
int rc = 0;
/* Make sure it has a compatible property */
@@ -361,6 +362,7 @@
auxdata = of_dev_lookup(lookup, bus);
if (auxdata) {
bus_id = auxdata->name;
+ id = auxdata->id;
platform_data = auxdata->platform_data;
}
@@ -370,6 +372,11 @@
}
dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);
+
+ /* override the id if auxdata gives an id */
+ if (id != -1)
+ dev->id = id;
+
if (!dev || !of_match_node(matches, bus))
return 0;
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 4378bf7..a878ab1 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1003,6 +1003,12 @@
head->qh_next.qh = qh;
head->hw->hw_next = dma;
+ /*
+ * flush qh descriptor into memory immediately,
+ * see comments in qh_append_tds.
+ */
+ ehci_sync_mem();
+
qh_get(qh);
qh->xacterrs = 0;
qh->qh_state = QH_STATE_LINKED;
@@ -1090,6 +1096,18 @@
wmb ();
dummy->hw_token = token;
+ /*
+ * Writing to dma coherent buffer on ARM may
+ * be delayed to reach memory, so HC may not see
+ * hw_token of dummy qtd in time, which can cause
+ * the qtd transaction to be executed very late,
+ * and degrade performance a lot. ehci_sync_mem
+ * is added to flush 'token' immediatelly into
+ * memory, so that ehci can execute the transaction
+ * ASAP.
+ */
+ ehci_sync_mem();
+
urb->hcpriv = qh_get (qh);
}
}
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 2694ed6..b44c37d 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -748,6 +748,23 @@
#endif
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
/*-------------------------------------------------------------------------*/
#ifdef CONFIG_PCI
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index b47d204..57d555e 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -44,13 +44,18 @@
char *compatible;
resource_size_t phys_addr;
char *name;
+ int id;
void *platform_data;
};
/* Macro to simplify populating a lookup table */
#define OF_DEV_AUXDATA(_compat,_phys,_name,_pdata) \
{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
- .platform_data = _pdata }
+ .id = -1, .platform_data = _pdata }
+
+#define OF_DEV_AUXDATA_ID(_compat,_phys,_name,_id,_pdata) \
+ { .compatible = _compat, .phys_addr = _phys, .name = _name, \
+ .id = _id, .platform_data = _pdata }
/**
* of_platform_driver - Legacy of-aware driver for platform devices.
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index c95fdda..bb4c3a0 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -12,6 +12,43 @@
set -e
+# Attempt to find the correct Debian architecture
+forcearch=""
+debarch=""
+case "$UTS_MACHINE" in
+i386|ia64|alpha)
+ debarch="$UTS_MACHINE" ;;
+x86_64)
+ debarch=amd64 ;;
+sparc*)
+ debarch=sparc ;;
+s390*)
+ debarch=s390 ;;
+ppc*)
+ debarch=powerpc ;;
+parisc*)
+ debarch=hppa ;;
+mips*)
+ debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y .config && echo el) ;;
+arm*)
+ debarch=arm$(grep -q CONFIG_AEABI=y .config && echo el) ;;
+*)
+ echo "" >&2
+ echo "** ** ** WARNING ** ** **" >&2
+ echo "" >&2
+ echo "Your architecture doesn't have it's equivalent" >&2
+ echo "Debian userspace architecture defined!" >&2
+ echo "Falling back to using your current userspace instead!" >&2
+ echo "Please add support for $UTS_MACHINE to ${0} ..." >&2
+ echo "" >&2
+esac
+if [ -n "$KBUILD_DEBARCH" ] ; then
+ debarch="$KBUILD_DEBARCH"
+fi
+if [ -n "$debarch" ] ; then
+ forcearch="-DArchitecture=$debarch"
+fi
+
create_package() {
local pname="$1" pdir="$2"
@@ -25,42 +62,6 @@
chown -R root:root "$pdir"
chmod -R go-w "$pdir"
- # Attempt to find the correct Debian architecture
- local forcearch="" debarch=""
- case "$UTS_MACHINE" in
- i386|ia64|alpha)
- debarch="$UTS_MACHINE" ;;
- x86_64)
- debarch=amd64 ;;
- sparc*)
- debarch=sparc ;;
- s390*)
- debarch=s390 ;;
- ppc*)
- debarch=powerpc ;;
- parisc*)
- debarch=hppa ;;
- mips*)
- debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y .config && echo el) ;;
- arm*)
- debarch=arm$(grep -q CONFIG_AEABI=y .config && echo el) ;;
- *)
- echo "" >&2
- echo "** ** ** WARNING ** ** **" >&2
- echo "" >&2
- echo "Your architecture doesn't have it's equivalent" >&2
- echo "Debian userspace architecture defined!" >&2
- echo "Falling back to using your current userspace instead!" >&2
- echo "Please add support for $UTS_MACHINE to ${0} ..." >&2
- echo "" >&2
- esac
- if [ -n "$KBUILD_DEBARCH" ] ; then
- debarch="$KBUILD_DEBARCH"
- fi
- if [ -n "$debarch" ] ; then
- forcearch="-DArchitecture=$debarch"
- fi
-
# Create the package
dpkg-gencontrol -isp $forcearch -p$pname -P"$pdir"
dpkg --build "$pdir" ..
@@ -118,6 +119,11 @@
else
cp arch/$ARCH/boot/$KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
fi
+ # Copy device tree files if generated
+ stat arch/$ARCH/boot/*.dtb && {
+ mkdir -p "$tmpdir/boot/dt-$version"
+ cp arch/$ARCH/boot/*.dtb "$tmpdir/boot/dt-$version"
+ }
fi
if grep -q '^CONFIG_MODULES=y' .config ; then
@@ -252,15 +258,14 @@
(cd $objtree; tar -c -f - -T "$objtree/debian/hdrobjfiles") | (cd $destdir; tar -xf -)
ln -sf "/usr/src/linux-headers-$version" "$kernel_headers_dir/lib/modules/$version/build"
rm -f "$objtree/debian/hdrsrcfiles" "$objtree/debian/hdrobjfiles"
-arch=$(dpkg --print-architecture)
cat <<EOF >> debian/control
Package: $kernel_headers_packagename
Provides: linux-headers, linux-headers-2.6
-Architecture: $arch
-Description: Linux kernel headers for $KERNELRELEASE on $arch
- This package provides kernel header files for $KERNELRELEASE on $arch
+Architecture: $debarch
+Description: Linux kernel headers for $KERNELRELEASE on $debarch
+ This package provides kernel header files for $KERNELRELEASE on $debarch
.
This is useful for people who need to build external modules
EOF