diff options
author | Andrey Konovalov <andrey.konovalov@linaro.org> | 2012-10-08 23:28:12 +0400 |
---|---|---|
committer | Andrey Konovalov <andrey.konovalov@linaro.org> | 2012-10-08 23:28:12 +0400 |
commit | 92acf1381651c40247e28df8af7327990826001c (patch) | |
tree | cc8494ccb0cb1aead2cbc57fdc079353e9d2711f | |
parent | 66ae7c5a3a74f402f6b098237ab89b05991e01e6 (diff) | |
parent | 01629e6c4f9c26781c13ef5db6957413ca4bef28 (diff) |
Merge branch 'tracking-llct-v3.6-misc-fixes' into merge-linux-linaro-core-trackingtracking-llct-ll-20121008.0llct-20121008.0
29 files changed, 694 insertions, 43 deletions
diff --git a/Documentation/devicetree/bindings/arm/freescale.txt b/Documentation/devicetree/bindings/arm/freescale.txt new file mode 100644 index 00000000000..8c52102b225 --- /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 00000000000..b353489acd4 --- /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 00000000000..45e03b8dd04 --- /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 00000000000..e81ffcc8443 --- /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 00000000000..9fda6ae314e --- /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 00000000000..72caabb85b7 --- /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 00000000000..f40886fef69 --- /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 00000000000..e5e9c8913d0 --- /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 00000000000..8426c620614 --- /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 00000000000..c61f0112bf3 --- /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 38c1a3b103a..29d9ce019c2 100644 --- a/arch/arm/kernel/kprobes-test-arm.c +++ b/arch/arm/kernel/kprobes-test-arm.c @@ -456,6 +456,8 @@ void kprobe_arm_test_cases(void) TEST_UNSUPPORTED(".word 0xe1700090") /* Unallocated space */ #if __LINUX_ARM_ARCH__ >= 6 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 05541cf4a87..2e63463178b 100644 --- a/arch/arm/mach-imx/Makefile.boot +++ b/arch/arm/mach-imx/Makefile.boot @@ -30,10 +30,16 @@ zreladdr-$(CONFIG_SOC_IMX51) += 0x90008000 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 7b31cbde877..87818d13f0e 100644 --- a/arch/arm/mach-imx/mach-mx51_babbage.c +++ b/arch/arm/mach-imx/mach-mx51_babbage.c @@ -423,6 +423,11 @@ static struct sys_timer mx51_babbage_timer = { .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 @@ MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board") .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 8d09c0126ca..928c98ecda3 100644 --- a/arch/arm/mach-imx/mach-mx51_efikamx.c +++ b/arch/arm/mach-imx/mach-mx51_efikamx.c @@ -287,7 +287,13 @@ static struct sys_timer mx51_efikamx_timer = { .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 @@ MACHINE_START(MX51_EFIKAMX, "Genesi Efika MX (Smarttop)") .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 fdbd181b97e..37d52e00e43 100644 --- a/arch/arm/mach-imx/mach-mx51_efikasb.c +++ b/arch/arm/mach-imx/mach-mx51_efikasb.c @@ -283,6 +283,11 @@ static struct sys_timer mx51_efikasb_timer = { .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 @@ MACHINE_START(MX51_EFIKASB, "Genesi Efika MX (Smartbook)") .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 8abe23c1d3c..67f5fc97d2a 100644 --- a/arch/arm/mach-imx/mach-mx53_loco.c +++ b/arch/arm/mach-imx/mach-mx53_loco.c @@ -309,6 +309,10 @@ static struct sys_timer mx53_loco_timer = { .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, @@ -318,4 +322,5 @@ MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board") .init_machine = mx53_loco_board_init, .init_late = imx53_init_late, .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 b03e562acc6..eab4c41e41b 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 28214483aab..5dbc6993b0f 100644 --- a/arch/arm/mach-omap2/board-igep0020.c +++ b/arch/arm/mach-omap2/board-igep0020.c @@ -644,6 +644,11 @@ static void __init igep_init(void) } } +static const char *igep2_dt_compat[] = { + "ISEE,igep-v2", + NULL +}; + MACHINE_START(IGEP0020, "IGEP v2 board") .atag_offset = 0x100, .reserve = omap_reserve, @@ -655,8 +660,14 @@ MACHINE_START(IGEP0020, "IGEP v2 board") .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, @@ -668,4 +679,5 @@ MACHINE_START(IGEP0030, "IGEP OMAP3 module") .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 6202fc76e49..8ead4c58102 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -530,6 +530,11 @@ static void __init omap3_beagle_init(void) 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, @@ -542,4 +547,5 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board") .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 70f6d1d2546..613556c982f 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -515,6 +515,11 @@ static void __init omap4_panda_init(void) 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, @@ -527,4 +532,5 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board") .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 779734d8ba3..64e90c61cd8 100644 --- a/arch/arm/mach-omap2/board-overo.c +++ b/arch/arm/mach-omap2/board-overo.c @@ -546,6 +546,11 @@ static void __init overo_init(void) "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 @@ MACHINE_START(OVERO, "Gumstix Overo") .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 ff0a4b5b0a8..6910b314456 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 e44f8c2d239..4150b942704 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -348,6 +348,7 @@ static int of_platform_bus_create(struct device_node *bus, 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 */ @@ -360,6 +361,7 @@ static int of_platform_bus_create(struct device_node *bus, auxdata = of_dev_lookup(lookup, bus); if (auxdata) { bus_id = auxdata->name; + id = auxdata->id; platform_data = auxdata->platform_data; } @@ -369,6 +371,11 @@ static int of_platform_bus_create(struct device_node *bus, } 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/staging/omapdrm/omap_drv.c b/drivers/staging/omapdrm/omap_drv.c index 4beab9447ce..44149eeb97a 100644 --- a/drivers/staging/omapdrm/omap_drv.c +++ b/drivers/staging/omapdrm/omap_drv.c @@ -761,7 +761,6 @@ static struct drm_driver omap_drm_driver = { .irq_postinstall = dev_irq_postinstall, .irq_uninstall = dev_irq_uninstall, .irq_handler = dev_irq_handler, - .reclaim_buffers = drm_core_reclaim_buffers, #ifdef CONFIG_DEBUG_FS .debugfs_init = omap_debugfs_init, .debugfs_cleanup = omap_debugfs_cleanup, diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c index 4b66374bdc8..940a63f67a2 100644 --- a/drivers/usb/host/ehci-q.c +++ b/drivers/usb/host/ehci-q.c @@ -1018,6 +1018,12 @@ static void qh_link_async (struct ehci_hcd *ehci, struct ehci_qh *qh) 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->xacterrs = 0; qh->qh_state = QH_STATE_LINKED; /* qtd completions reported later by interrupt */ @@ -1106,6 +1112,18 @@ static struct ehci_qh *qh_append_tds ( 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; } } diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index da07d98f7d1..53ed57567ce 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -760,6 +760,23 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd *ehci, const __hc32 *x) #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 b47d2040c9f..57d555ec713 100644 --- a/include/linux/of_platform.h +++ b/include/linux/of_platform.h @@ -44,13 +44,18 @@ struct of_dev_auxdata { 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/kernel/rcutree.c b/kernel/rcutree.c index f494157be2f..1c1016af4dd 100644 --- a/kernel/rcutree.c +++ b/kernel/rcutree.c @@ -304,7 +304,9 @@ cpu_has_callbacks_ready_to_invoke(struct rcu_data *rdp) static int cpu_needs_another_gp(struct rcu_state *rsp, struct rcu_data *rdp) { - return *rdp->nxttail[RCU_DONE_TAIL] && !rcu_gp_in_progress(rsp); + return *rdp->nxttail[RCU_DONE_TAIL + + ACCESS_ONCE(rsp->completed) != rdp->completed] && + !rcu_gp_in_progress(rsp); } /* diff --git a/scripts/package/builddeb b/scripts/package/builddeb index acb86507828..22686b9c156 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 @@ create_package() { 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" .. @@ -252,15 +253,14 @@ mkdir -p "$destdir" (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 @@ -281,6 +281,12 @@ EOF create_package "$fwpackagename" "$fwdir" fi +# Copy device tree files if generated +stat arch/$ARCH/boot/*.dtb && { + mkdir -p "$tmpdir/lib/firmware/$version/device-tree" + cp arch/$ARCH/boot/*.dtb "$tmpdir/lib/firmware/$version/device-tree" +} + cat <<EOF >> debian/control Package: $libc_headers_packagename |