update to 3.10.33

- add support for system specific patches, cubox-i and raspberry-pi patches
  are in conflict
- fix hifiberry driver support

3 files changed, 0 insertions, 584365 deletions

diff --git a/target/linux/patches/3.10.30/solidrun-cubox-i.patch b/target/linux/patches/3.10.30/solidrun-cubox-i.patch
deleted file mode 100644
index beaa71b4e..000000000
--- a/target/linux/patches/3.10.30/solidrun-cubox-i.patch
+++ /dev/null
@@ -1,584365 +0,0 @@
-diff -Nur linux-3.10.30/Documentation/ABI/testing/sysfs-class-mtd linux-3.10.30-cubox-i/Documentation/ABI/testing/sysfs-class-mtd
---- linux-3.10.30/Documentation/ABI/testing/sysfs-class-mtd	2014-02-13 22:48:15.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/ABI/testing/sysfs-class-mtd	2014-03-08 20:32:51.000000000 +0100
-@@ -104,7 +104,7 @@
- 		One of the following ASCII strings, representing the device
- 		type:
- 
--		absent, ram, rom, nor, nand, dataflash, ubi, unknown
-+		absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
- 
- What:		/sys/class/mtd/mtdX/writesize
- Date:		April 2009
-@@ -128,9 +128,8 @@
- Contact:	linux-mtd@lists.infradead.org
- Description:
- 		Maximum number of bit errors that the device is capable of
--		correcting within each region covering an ecc step.  This will
--		always be a non-negative integer.  Note that some devices will
--		have multiple ecc steps within each writesize region.
-+		correcting within each region covering an ECC step (see
-+		ecc_step_size).  This will always be a non-negative integer.
- 
- 		In the case of devices lacking any ECC capability, it is 0.
- 
-@@ -173,3 +172,15 @@
- 		This is generally applicable only to NAND flash devices with ECC
- 		capability.  It is ignored on devices lacking ECC capability;
- 		i.e., devices for which ecc_strength is zero.
-+
-+What:		/sys/class/mtd/mtdX/ecc_step_size
-+Date:		May 2013
-+KernelVersion:	3.10
-+Contact:	linux-mtd@lists.infradead.org
-+Description:
-+		The size of a single region covered by ECC, known as the ECC
-+		step.  Devices may have several equally sized ECC steps within
-+		each writesize region.
-+
-+		It will always be a non-negative integer.  In the case of
-+		devices lacking any ECC capability, it is 0.
-diff -Nur linux-3.10.30/Documentation/DocBook/mtdnand.tmpl linux-3.10.30-cubox-i/Documentation/DocBook/mtdnand.tmpl
---- linux-3.10.30/Documentation/DocBook/mtdnand.tmpl	2014-02-13 22:48:15.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/DocBook/mtdnand.tmpl	2014-03-08 20:32:51.000000000 +0100
-@@ -1222,10 +1222,6 @@
- #define NAND_BBT_VERSION	0x00000100
- /* Create a bbt if none axists */
- #define NAND_BBT_CREATE		0x00000200
--/* Search good / bad pattern through all pages of a block */
--#define NAND_BBT_SCANALLPAGES	0x00000400
--/* Scan block empty during good / bad block scan */
--#define NAND_BBT_SCANEMPTY	0x00000800
- /* Write bbt if neccecary */
- #define NAND_BBT_WRITE		0x00001000
- /* Read and write back block contents when writing bbt */
-diff -Nur linux-3.10.30/Documentation/arm/small_task_packing.txt linux-3.10.30-cubox-i/Documentation/arm/small_task_packing.txt
---- linux-3.10.30/Documentation/arm/small_task_packing.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/arm/small_task_packing.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,136 @@
-+Small Task Packing in the big.LITTLE MP Reference Patch Set
-+
-+What is small task packing?
-+----
-+Simply that the scheduler will fit as many small tasks on a single CPU
-+as possible before using other CPUs. A small task is defined as one
-+whose tracked load is less than 90% of a NICE_0 task. This is a change
-+from the usual behavior since the scheduler will normally use an idle
-+CPU for a waking task unless that task is considered cache hot.
-+
-+
-+How is it implemented?
-+----
-+Since all small tasks must wake up relatively frequently, the main
-+requirement for packing small tasks is to select a partly-busy CPU when
-+waking rather than looking for an idle CPU. We use the tracked load of
-+the CPU runqueue to determine how heavily loaded each CPU is and the
-+tracked load of the task to determine if it will fit on the CPU. We
-+always start with the lowest-numbered CPU in a sched domain and stop
-+looking when we find a CPU with enough space for the task.
-+
-+Some further tweaks are necessary to suppress load balancing when the
-+CPU is not fully loaded, otherwise the scheduler attempts to spread
-+tasks evenly across the domain.
-+
-+
-+How does it interact with the HMP patches?
-+----
-+Firstly, we only enable packing on the little domain. The intent is that
-+the big domain is intended to spread tasks amongst the available CPUs
-+one-task-per-CPU. The little domain however is attempting to use as
-+little power as possible while servicing its tasks.
-+
-+Secondly, since we offload big tasks onto little CPUs in order to try
-+to devote one CPU to each task, we have a threshold above which we do
-+not try to pack a task and instead will select an idle CPU if possible.
-+This maintains maximum forward progress for busy tasks temporarily
-+demoted from big CPUs.
-+
-+
-+Can the behaviour be tuned?
-+----
-+Yes, the load level of a 'full' CPU can be easily modified in the source
-+and is exposed through sysfs as /sys/kernel/hmp/packing_limit to be
-+changed at runtime. The presence of the packing behaviour is controlled
-+by CONFIG_SCHED_HMP_LITTLE_PACKING and can be disabled at run-time
-+using /sys/kernel/hmp/packing_enable.
-+The definition of a small task is hard coded as 90% of NICE_0_LOAD
-+and cannot be modified at run time.
-+
-+
-+Why do I need to tune it?
-+----
-+The optimal configuration is likely to be different depending upon the
-+design and manufacturing of your SoC.
-+
-+In the main, there are two system effects from enabling small task
-+packing.
-+
-+1. CPU operating point may increase
-+2. wakeup latency of tasks may be increased
-+
-+There are also likely to be secondary effects from loading one CPU
-+rather than spreading tasks.
-+
-+Note that all of these system effects are dependent upon the workload
-+under consideration.
-+
-+
-+CPU Operating Point
-+----
-+The primary impact of loading one CPU with a number of light tasks is to
-+increase the compute requirement of that CPU since it is no longer idle
-+as often. Increased compute requirement causes an increase in the
-+frequency of the CPU through CPUfreq.
-+
-+Consider this example:
-+We have a system with 3 CPUs which can operate at any frequency between
-+350MHz and 1GHz. The system has 6 tasks which would each produce 10%
-+load at 1GHz. The scheduler has frequency-invariant load scaling
-+enabled. Our DVFS governor aims for 80% utilization at the chosen
-+frequency.
-+
-+Without task packing, these tasks will be spread out amongst all CPUs
-+such that each has 2. This will produce roughly 20% system load, and
-+the frequency of the package will remain at 350MHz.
-+
-+With task packing set to the default packing_limit, all of these tasks
-+will sit on one CPU and require a package frequency of ~750MHz to reach
-+80% utilization. (0.75 = 0.6 * 0.8).
-+
-+When a package operates on a single frequency domain, all CPUs in that
-+package share frequency and voltage.
-+
-+Depending upon the SoC implementation there can be a significant amount
-+of energy lost to leakage from idle CPUs. The decision about how
-+loaded a CPU must be to be considered 'full' is therefore controllable
-+through sysfs (sys/kernel/hmp/packing_limit) and directly in the code.
-+
-+Continuing the example, lets set packing_limit to 450 which means we
-+will pack tasks until the total load of all running tasks >= 450. In
-+practise, this is very similar to a 55% idle 1Ghz CPU.
-+
-+Now we are only able to place 4 tasks on CPU0, and two will overflow
-+onto CPU1. CPU0 will have a load of 40% and CPU1 will have a load of
-+20%. In order to still hit 80% utilization, CPU0 now only needs to
-+operate at (0.4*0.8=0.32) 320MHz, which means that the lowest operating
-+point will be selected, the same as in the non-packing case, except that
-+now CPU2 is no longer needed and can be power-gated.
-+
-+In order to use less energy, the saving from power-gating CPU2 must be
-+more than the energy spent running CPU0 for the extra cycles. This
-+depends upon the SoC implementation.
-+
-+This is obviously a contrived example requiring all the tasks to
-+be runnable at the same time, but it illustrates the point.
-+
-+
-+Wakeup Latency
-+----
-+This is an unavoidable consequence of trying to pack tasks together
-+rather than giving them a CPU each. If you cannot find an acceptable
-+level of wakeup latency, you should turn packing off.
-+
-+Cyclictest is a good test application for determining the added latency
-+when configuring packing.
-+
-+
-+Why is it turned off for the VersatileExpress V2P_CA15A7 CoreTile?
-+----
-+Simply, this core tile only has power gating for the whole A7 package.
-+When small task packing is enabled, all our low-energy use cases
-+normally fit onto one A7 CPU. We therefore end up with 2 mostly-idle
-+CPUs and one mostly-busy CPU. This decreases the amount of time
-+available where the whole package is idle and can be turned off.
-+
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/arm/cci.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/cci.txt
---- linux-3.10.30/Documentation/devicetree/bindings/arm/cci.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/cci.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,172 @@
-+=======================================================
-+ARM CCI cache coherent interconnect binding description
-+=======================================================
-+
-+ARM multi-cluster systems maintain intra-cluster coherency through a
-+cache coherent interconnect (CCI) that is capable of monitoring bus
-+transactions and manage coherency, TLB invalidations and memory barriers.
-+
-+It allows snooping and distributed virtual memory message broadcast across
-+clusters, through memory mapped interface, with a global control register
-+space and multiple sets of interface control registers, one per slave
-+interface.
-+
-+Bindings for the CCI node follow the ePAPR standard, available from:
-+
-+www.power.org/documentation/epapr-version-1-1/
-+
-+with the addition of the bindings described in this document which are
-+specific to ARM.
-+
-+* CCI interconnect node
-+
-+	Description: Describes a CCI cache coherent Interconnect component
-+
-+	Node name must be "cci".
-+	Node's parent must be the root node /, and the address space visible
-+	through the CCI interconnect is the same as the one seen from the
-+	root node (ie from CPUs perspective as per DT standard).
-+	Every CCI node has to define the following properties:
-+
-+	- compatible
-+		Usage: required
-+		Value type: <string>
-+		Definition: must be set to
-+			    "arm,cci-400"
-+
-+	- reg
-+		Usage: required
-+		Value type: <prop-encoded-array>
-+		Definition: A standard property. Specifies base physical
-+			    address of CCI control registers common to all
-+			    interfaces.
-+
-+	- ranges:
-+		Usage: required
-+		Value type: <prop-encoded-array>
-+		Definition: A standard property. Follow rules in the ePAPR for
-+			    hierarchical bus addressing. CCI interfaces
-+			    addresses refer to the parent node addressing
-+			    scheme to declare their register bases.
-+
-+	CCI interconnect node can define the following child nodes:
-+
-+	- CCI control interface nodes
-+
-+		Node name must be "slave-if".
-+		Parent node must be CCI interconnect node.
-+
-+		A CCI control interface node must contain the following
-+		properties:
-+
-+		- compatible
-+			Usage: required
-+			Value type: <string>
-+			Definition: must be set to
-+				    "arm,cci-400-ctrl-if"
-+
-+		- interface-type:
-+			Usage: required
-+			Value type: <string>
-+			Definition: must be set to one of {"ace", "ace-lite"}
-+				    depending on the interface type the node
-+				    represents.
-+
-+		- reg:
-+			Usage: required
-+			Value type: <prop-encoded-array>
-+			Definition: the base address and size of the
-+				    corresponding interface programming
-+				    registers.
-+
-+* CCI interconnect bus masters
-+
-+	Description: masters in the device tree connected to a CCI port
-+		     (inclusive of CPUs and their cpu nodes).
-+
-+	A CCI interconnect bus master node must contain the following
-+	properties:
-+
-+	- cci-control-port:
-+		Usage: required
-+		Value type: <phandle>
-+		Definition: a phandle containing the CCI control interface node
-+			    the master is connected to.
-+
-+Example:
-+
-+	cpus {
-+		#size-cells = <0>;
-+		#address-cells = <1>;
-+
-+		CPU0: cpu@0 {
-+			device_type = "cpu";
-+			compatible = "arm,cortex-a15";
-+			cci-control-port = <&cci_control1>;
-+			reg = <0x0>;
-+		};
-+
-+		CPU1: cpu@1 {
-+			device_type = "cpu";
-+			compatible = "arm,cortex-a15";
-+			cci-control-port = <&cci_control1>;
-+			reg = <0x1>;
-+		};
-+
-+		CPU2: cpu@100 {
-+			device_type = "cpu";
-+			compatible = "arm,cortex-a7";
-+			cci-control-port = <&cci_control2>;
-+			reg = <0x100>;
-+		};
-+
-+		CPU3: cpu@101 {
-+			device_type = "cpu";
-+			compatible = "arm,cortex-a7";
-+			cci-control-port = <&cci_control2>;
-+			reg = <0x101>;
-+		};
-+
-+	};
-+
-+	dma0: dma@3000000 {
-+		compatible = "arm,pl330", "arm,primecell";
-+		cci-control-port = <&cci_control0>;
-+		reg = <0x0 0x3000000 0x0 0x1000>;
-+		interrupts = <10>;
-+		#dma-cells = <1>;
-+		#dma-channels = <8>;
-+		#dma-requests = <32>;
-+	};
-+
-+	cci@2c090000 {
-+		compatible = "arm,cci-400";
-+		#address-cells = <1>;
-+		#size-cells = <1>;
-+		reg = <0x0 0x2c090000 0 0x1000>;
-+		ranges = <0x0 0x0 0x2c090000 0x6000>;
-+
-+		cci_control0: slave-if@1000 {
-+			compatible = "arm,cci-400-ctrl-if";
-+			interface-type = "ace-lite";
-+			reg = <0x1000 0x1000>;
-+		};
-+
-+		cci_control1: slave-if@4000 {
-+			compatible = "arm,cci-400-ctrl-if";
-+			interface-type = "ace";
-+			reg = <0x4000 0x1000>;
-+		};
-+
-+		cci_control2: slave-if@5000 {
-+			compatible = "arm,cci-400-ctrl-if";
-+			interface-type = "ace";
-+			reg = <0x5000 0x1000>;
-+		};
-+	};
-+
-+This CCI node corresponds to a CCI component whose control registers sits
-+at address 0x000000002c090000.
-+CCI slave interface @0x000000002c091000 is connected to dma controller dma0.
-+CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};
-+CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/arm/imx/busfreq-imx6.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/imx/busfreq-imx6.txt
---- linux-3.10.30/Documentation/devicetree/bindings/arm/imx/busfreq-imx6.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/imx/busfreq-imx6.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,64 @@
-+Freescale Busfreq driver
-+
-+It is a generic driver that manages the frequency of the DDR, AHB and AXI buses in the iMX6x architecture.
-+It works for both SMP and UP systems and for both DDR3 and LPDDR2 memory types.
-+
-+Required properties are listed below:
-+- compatible: should be "fsl,imx6_busfreq"
-+- clocks: Lists the various clocks used by the busfreq driver
-+- interrupts - Lists the interrupts used by the busfreq driver. This is needed only for SMP architecutre.
-+- fsl,max_ddr_freq - The max ddr freq for this chip
-+
-+Examples:
-+For SOC imx6q.dtsi:
-+	busfreq { /* BUSFREQ */
-+		compatible = "fsl,imx6_busfreq";
-+		clocks = <&clks 171>, <&clks 6>, <&clks 11>, <&clks 104>, <&clks 172>, <&clks 58>,
-+			<&clks 18>, <&clks 60>, <&clks 20>, <&clks 3>;
-+		clock-names = "pll2_bus", "pll2_pfd2_396m", "pll2_198m", "arm", "pll3_usb_otg", "periph",
-+			"periph_pre", "periph_clk2", "periph_clk2_sel", "osc";
-+		interrupts = <0 107 0x04>, <0 112 0x4>, <0 113 0x4>, <0 114 0x4>;
-+		interrupt-names = "irq_busfreq_0", "irq_busfreq_1", "irq_busfreq_2", "irq_busfreq_3";
-+		fsl,max_ddr_freq = <528000000>;
-+	};
-+
-+The Freescale Busfreq driver supports the following setpoints for the DDR freq:
-+enum bus_freq_mode {
-+	BUS_FREQ_HIGH, -> The max freq the SOC supports
-+	BUS_FREQ_MED,  -> Medium setpoint (ex 400MHz for DDR3 when the max is 528MHz)
-+	BUS_FREQ_AUDIO, -> Audio playback freq (50MHz)
-+	BUS_FREQ_LOW,  -> Low power IDLE freq (24MHz)
-+};
-+
-+Currently the Freescale Busfreq driver implementation requires drivers to call the following APIs:
-+1. request_bus_freq(enum bus_freq_mode):
-+	The driver is requesting the system and ddr freq to be set to the requested value. The driver should call this
-+	API before it even enables its clocks.
-+
-+2. release_bus_freq(enum bus_freq_mode):
-+	The driver no longer needs the system and ddr freq at the required value. The driver should call this API after
-+	its work is done and it has disabled its clocks.
-+
-+Examples:
-+In the IPU driver, the requesting and releasing of the required bus frequency is tied into the runtime PM implementation:
-+
-+int ipu_runtime_suspend(struct device *dev)
-+{
-+	release_bus_freq(BUS_FREQ_HIGH);
-+	dev_dbg(dev, "ipu busfreq high release.\n");
-+
-+	return 0;
-+}
-+
-+int ipu_runtime_resume(struct device *dev)
-+{
-+	request_bus_freq(BUS_FREQ_HIGH);
-+	dev_dbg(dev, "ipu busfreq high requst.\n");
-+
-+	return 0;
-+}
-+
-+static const struct dev_pm_ops ipu_pm_ops = {
-+	SET_RUNTIME_PM_OPS(ipu_runtime_suspend, ipu_runtime_resume, NULL)
-+	SET_SYSTEM_SLEEP_PM_OPS(ipu_suspend, ipu_resume)
-+};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/arm/imx/gpc.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/imx/gpc.txt
---- linux-3.10.30/Documentation/devicetree/bindings/arm/imx/gpc.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/imx/gpc.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,20 @@
-+Freescale imx GPC bindings
-+
-+Optional properties:
-+- fsl,cpu_pupscr_sw2iso: for powering up CPU, number of 32K clock cycle PGC will wait before negating isolation signal.
-+- fsl,cpu_pupscr_sw: for powering up CPU, number of 32K clock cycle PGC will wait before asserting isolation signal.
-+- fsl,cpu_pdnscr_iso2sw: for powering down CPU, number of ipg clock cycle PGC will wait before negating isolation signal.
-+- fsl,cpu_pdnscr_iso: for powering down CPU, number of ipg clock cycle PGC will wait before asserting isolation signal.
-+
-+These properties are for adjusting the GPC PGC CPU power up/down setting, if there is no such property in dts, then default
-+value in GPC PGC registers will be used.
-+
-+
-+Example:
-+
-+	&gpc {
-+		fsl,cpu_pupscr_sw2iso = <0xf>;
-+		fsl,cpu_pupscr_sw = <0xf>;
-+		fsl,cpu_pdnscr_iso2sw = <0x1>;
-+		fsl,cpu_pdnscr_iso = <0x1>;
-+	};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/arm/pmu.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/pmu.txt
---- linux-3.10.30/Documentation/devicetree/bindings/arm/pmu.txt	2014-02-13 22:48:15.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/pmu.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -16,6 +16,9 @@
- 	"arm,arm1176-pmu"
- 	"arm,arm1136-pmu"
- - interrupts : 1 combined interrupt or 1 per core.
-+- cluster : a phandle to the cluster to which it belongs
-+	If there are more than one cluster with same CPU type
-+	then there should be separate PMU nodes per cluster.
- 
- Example:
- 
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
---- linux-3.10.30/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,19 @@
-+ARM Dual Cluster System Configuration Block
-+-------------------------------------------
-+
-+The Dual Cluster System Configuration Block (DCSCB) provides basic
-+functionality for controlling clocks, resets and configuration pins in
-+the Dual Cluster System implemented by the Real-Time System Model (RTSM).
-+
-+Required properties:
-+
-+- compatible : should be "arm,rtsm,dcscb"
-+
-+- reg : physical base address and the size of the registers window
-+
-+Example:
-+
-+	dcscb@60000000 {
-+		compatible = "arm,rtsm,dcscb";
-+		reg = <0x60000000 0x1000>;
-+	};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/bus/imx-weim.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/bus/imx-weim.txt
---- linux-3.10.30/Documentation/devicetree/bindings/bus/imx-weim.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/bus/imx-weim.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,49 @@
-+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
-+
-+The term "wireless" does not imply that the WEIM is literally an interface
-+without wires. It simply means that this module was originally designed for
-+wireless and mobile applications that use low-power technology.
-+
-+The actual devices are instantiated from the child nodes of a WEIM node.
-+
-+Required properties:
-+
-+ - compatible:		Should be set to "fsl,imx6q-weim"
-+ - reg:			A resource specifier for the register space
-+			(see the example below)
-+ - clocks:		the clock, see the example below.
-+ - #address-cells:	Must be set to 2 to allow memory address translation
-+ - #size-cells:		Must be set to 1 to allow CS address passing
-+ - ranges:		Must be set up to reflect the memory layout with four
-+			integer values for each chip-select line in use:
-+
-+			   <cs-number> 0 <physical address of mapping> <size>
-+
-+Timing property for child nodes. It is mandatory, not optional.
-+
-+ - fsl,weim-cs-timing:	The timing array, contains 6 timing values for the
-+			child node. We can get the CS index from the child
-+			node's "reg" property. This property contains the values
-+			for the registers EIM_CSnGCR1, EIM_CSnGCR2, EIM_CSnRCR1,
-+			EIM_CSnRCR2, EIM_CSnWCR1, EIM_CSnWCR2 in this order.
-+
-+Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
-+
-+	weim: weim@021b8000 {
-+		compatible = "fsl,imx6q-weim";
-+		reg = <0x021b8000 0x4000>;
-+		clocks = <&clks 196>;
-+		#address-cells = <2>;
-+		#size-cells = <1>;
-+		ranges = <0 0 0x08000000 0x08000000>;
-+
-+		nor@0,0 {
-+			compatible = "cfi-flash";
-+			reg = <0 0 0x02000000>;
-+			#address-cells = <1>;
-+			#size-cells = <1>;
-+			bank-width = <2>;
-+			fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
-+					0x0000c000 0x1404a38e 0x00000000>;
-+		};
-+	};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/clock/imx6q-clock.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/clock/imx6q-clock.txt
---- linux-3.10.30/Documentation/devicetree/bindings/clock/imx6q-clock.txt	2014-02-13 22:48:15.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/clock/imx6q-clock.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -89,8 +89,6 @@
- 	gpu3d_shader		74
- 	ipu1_podf		75
- 	ipu2_podf		76
--	ldb_di0_podf		77
--	ldb_di1_podf		78
- 	ipu1_di0_pre		79
- 	ipu1_di1_pre		80
- 	ipu2_di0_pre		81
-@@ -208,6 +206,29 @@
- 	pll4_post_div		193
- 	pll5_post_div		194
- 	pll5_video_div		195
-+	eim_slow      		196
-+	spdif      		197
-+	cko2_sel      		198
-+	cko2_podf      		199
-+	cko2      		200
-+	cko      		201
-+	vdoa      		202
-+	gpt_3m      		203
-+	video_27m      		204
-+	ldb_di0_div_7		205
-+	ldb_di1_div_7		206
-+	ldb_di0_div_sel		207
-+	ldb_di1_div_sel		208
-+	pll4_audio_div		209
-+	lvds1_sel      		210
-+	lvds1_in      		211
-+	lvds1_out		212
-+	caam_mem		213
-+	caam_aclk		214
-+	caam_ipg		215
-+	epit1			216
-+	epit2			217
-+	tzasc2			218
- 
- Examples:
- 
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/clock/imx6sl-clock.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
---- linux-3.10.30/Documentation/devicetree/bindings/clock/imx6sl-clock.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/clock/imx6sl-clock.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,10 @@
-+* Clock bindings for Freescale i.MX6 SoloLite
-+
-+Required properties:
-+- compatible: Should be "fsl,imx6sl-ccm"
-+- reg: Address and length of the register set
-+- #clock-cells: Should be <1>
-+
-+The clock consumer should specify the desired clock by having the clock
-+ID in its "clocks" phandle cell.  See include/dt-bindings/clock/imx6sl-clock.h
-+for the full list of i.MX6 SoloLite clock IDs.
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/clock/vf610-clock.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/clock/vf610-clock.txt
---- linux-3.10.30/Documentation/devicetree/bindings/clock/vf610-clock.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/clock/vf610-clock.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,26 @@
-+* Clock bindings for Freescale Vybrid VF610 SOC
-+
-+Required properties:
-+- compatible: Should be "fsl,vf610-ccm"
-+- reg: Address and length of the register set
-+- #clock-cells: Should be <1>
-+
-+The clock consumer should specify the desired clock by having the clock
-+ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
-+for the full list of VF610 clock IDs.
-+
-+Examples:
-+
-+clks: ccm@4006b000 {
-+	compatible = "fsl,vf610-ccm";
-+	reg = <0x4006b000 0x1000>;
-+	#clock-cells = <1>;
-+};
-+
-+uart1: serial@40028000 {
-+	compatible = "fsl,vf610-uart";
-+	reg = <0x40028000 0x1000>;
-+	interrupts = <0 62 0x04>;
-+	clocks = <&clks VF610_CLK_UART1>;
-+	clock-names = "ipg";
-+};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/cpufreq/cpufreq-imx6q.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/cpufreq/cpufreq-imx6q.txt
---- linux-3.10.30/Documentation/devicetree/bindings/cpufreq/cpufreq-imx6q.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/cpufreq/cpufreq-imx6q.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,59 @@
-+iMX6q/iMX6dl/iMX6sl specific CPUFREQ settings
-+
-+iMX6q/iMX6dl/iMX6sl has limitation that a couple of voltage rails (VDDSOC_CAP and VDDPU_CAP)
-+must track VDDARM_CAP within 50mV:
-+VDDARM_CAP - VDDSOC_CAP/VDDPU_CAP <= 50mV
-+
-+The VDDSOC_CAP and VDDPU_CAP operating points for various VDDARM_CAP settings are listed below.
-+
-+Required properties:
-+- fsl,soc-operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
-+  for details. It is a voltage frequency tuple.
-+
-+- For other entries in the example below please refer to Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
-+
-+Examples:
-+
-+cpus {
-+	#address-cells = <1>;
-+	#size-cells = <0>;
-+
-+	cpu@0 {
-+		compatible = "arm,cortex-a9";
-+		reg = <0>;
-+		next-level-cache = <&L2>;
-+		operating-points = <
-+			/* kHz    uV */
-+			1200000 1275000
-+			996000  1250000
-+			792000  1175000
-+			396000  1075000
-+		>;
-+		fsl,soc-operating-points = <
-+			/* ARM kHz  SOC-PU uV */
-+			1200000       1275000
-+			996000        1250000
-+			792000        1175000
-+			396000        1175000
-+		>;
-+		clock-latency = <61036>; /* two CLK32 periods */
-+	};
-+
-+	cpu@1 {
-+		compatible = "arm,cortex-a9";
-+		reg = <1>;
-+		next-level-cache = <&L2>;
-+	};
-+
-+	cpu@2 {
-+		compatible = "arm,cortex-a9";
-+		reg = <2>;
-+		next-level-cache = <&L2>;
-+	};
-+
-+	cpu@3 {
-+		compatible = "arm,cortex-a9";
-+		reg = <3>;
-+		next-level-cache = <&L2>;
-+	};
-+};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
---- linux-3.10.30/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt	2014-02-13 22:48:15.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -4,14 +4,71 @@
- - compatible : Should be "fsl,<chip>-sdma"
- - reg : Should contain SDMA registers location and length
- - interrupts : Should contain SDMA interrupt
-+- #dma-cells : Must be <3>.
-+  The first cell specifies the DMA request/event ID.  See details below
-+  about the second and third cell.
- - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
-   scripts firmware
- 
-+The second cell of dma phandle specifies the peripheral type of DMA transfer.
-+The full ID of peripheral types can be found below.
-+
-+	ID	transfer type
-+	---------------------
-+	0	MCU domain SSI
-+	1	Shared SSI
-+	2	MMC
-+	3	SDHC
-+	4	MCU domain UART
-+	5	Shared UART
-+	6	FIRI
-+	7	MCU domain CSPI
-+	8	Shared CSPI
-+	9	SIM
-+	10	ATA
-+	11	CCM
-+	12	External peripheral
-+	13	Memory Stick Host Controller
-+	14	Shared Memory Stick Host Controller
-+	15	DSP
-+	16	Memory
-+	17	FIFO type Memory
-+	18	SPDIF
-+	19	IPU Memory
-+	20	ASRC
-+	21	ESAI
-+	22	HDMI Audio
-+
-+The third cell specifies the transfer priority as below.
-+
-+	ID	transfer priority
-+	-------------------------
-+	0	High
-+	1	Medium
-+	2	Low
-+
- Examples:
- 
- sdma@83fb0000 {
- 	compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
- 	reg = <0x83fb0000 0x4000>;
- 	interrupts = <6>;
-+	#dma-cells = <3>;
- 	fsl,sdma-ram-script-name = "sdma-imx51.bin";
- };
-+
-+DMA clients connected to the i.MX SDMA controller must use the format
-+described in the dma.txt file.
-+
-+Examples:
-+
-+ssi2: ssi@70014000 {
-+	compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
-+	reg = <0x70014000 0x4000>;
-+	interrupts = <30>;
-+	clocks = <&clks 49>;
-+	dmas = <&sdma 24 1 0>,
-+	       <&sdma 25 1 0>;
-+	dma-names = "rx", "tx";
-+	fsl,fifo-depth = <15>;
-+};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/fb/fsl_epdc_fb.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/fb/fsl_epdc_fb.txt
---- linux-3.10.30/Documentation/devicetree/bindings/fb/fsl_epdc_fb.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/fb/fsl_epdc_fb.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,30 @@
-+* Freescale MXC Electrophoretic Display Controller (EPDC)
-+
-+Required properties:
-+- compatible: Should be "fsl,<chip>-epdc".  Supported chips include
-+  imx6dl and imx6sl
-+- reg: Address and length of the register set for EPDC
-+- interrupts: Should contain EPDC interrupts
-+- clocks: the clocks for EPDC
-+- pinctrl-names: should be "default"
-+- pinctrl-0: should be pinctrl_ipu1_1 or pinctrl_ipu2_1, which depends on the
-+  IPU connected.
-+- V3P3_supply: power supply for EPDC_PWRCTRL0 from pmic
-+- VCOM_supply: power supply for EPDC_VCOM0 from pmic
-+- DISPLAY_supply: power supply enable for pmic
-+
-+Examples:
-+
-+imx6_epdc@0x020f8000 {
-+	compatible = "fsl,imx6dl-epdc";
-+	reg = <0x020f8000 4000>;
-+	interrupts = <0 97 0x04>;
-+	clocks = <&clks 133>, <&clks 137>;  /* ipu2, ipu2_di1 */
-+	clock-names = "epdc-axi", "epdc-pix";
-+	pinctrl-names = "default";
-+	pinctrl-0 = <&pinctrl_epdc_0>;
-+	V3P3_supply = <&V3P3_reg>;
-+	VCOM_supply = <&VCOM_reg>;
-+	DISPLAY_supply = <&DISPLAY_reg>;
-+	status = "disabled";
-+};
-diff -Nur linux-3.10.30/Documentation/devicetree/bindings/fb/fsl_ipuv3_fb.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/fb/fsl_ipuv3_fb.txt
---- linux-3.10.30/Documentation/devicetree/bindings/fb/fsl_ipuv3_fb.txt	1970-01-01 01:00:00.000000000 +0100
-+++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/fb/fsl_ipuv3_fb.txt	2014-03-08 20:32:51.000000000 +0100
-@@ -0,0 +1,146 @@
-+* FSL IPUv3 Display/FB
-+
-+The FSL IPUv3 is Image Processing Unit version 3, a part of video and graphics
-+subsystem in an application processor. The goal of the IPU is to provide
-+comprehensive support for the flow of data from an image sensor or/and to a
-+display device.
-+
-+Two IPU units are on the imx6q SOC while only one IPU unit on the imx6dl SOC.
-+Each IPU unit has two display interfaces.
-+
-+For LDB/LVDS panel, there are two LVDS channels(LVDS0 and LVDS1) which can
-+transfer video data, these two channels can be used as
-+split/dual/single/separate mode.
-+-split mode means display data from DI0 or DI1 will send to both channels
-+ LVDS0+LVDS1.
-+-dual mode means display data from DI0 or DI1 will be duplicated on LVDS0
-+ and LVDS1, it said, LVDS0 and LVDS1 has the same content.
-+-single mode means only work for DI0/DI1->LVDS0 or DI0/DI1->LVDS1.
-+-separate mode means you can make DI0/DI1->LVDS0 and DI0/DI1->LVDS1 work
-+ at the same time.
-+ "ldb=spl0/1"	--      split mode on DI0/1
-+ "ldb=dul0/1"	--      dual mode on DI0/1
-+ "ldb=sin0/1"	--      single mode on LVDS0/1
-+ "ldb=sep0/1"	--      separate mode begin from LVDS0/1
-+
-+Required properties for IPU:
-+- bypass_reset :Bypass reset to avoid display channel being.
-+  stopped by probe since it may start to work in bootloader: 0 or 1.
-+- compatible : should be "fsl,imx6q-ipu".
-+- reg : the register address range.
-+- interrupts : the error and sync interrupts request.
-+- clocks : the clock sources that it depends on.
-+- clock-names:  the related clock names.
-+- resets : IPU reset specifier.  See reset.txt and fsl,imx-src.txt in
-+  Documentation/devicetree/bindings/reset/ for details.
-+
-+Required properties for fb:
-+- compatible : should be "fsl,mxc_sdc_fb".
-+- disp_dev : display device: "ldb", "lcd", "hdmi", "mipi_dsi".
-+- mode_str : video mode string: "LDB-XGA" or "LDB-1080P60" for ldb,
-+  "CLAA-WVGA" for lcd, "TRULY-WVGA" for TRULY mipi_dsi lcd panel,
-+  "1920x1080M@60" for hdmi.
-+- default_bpp : default bits per pixel: 8/16/24/32
-+- int_clk : use internal clock as pixel clock: 0 or 1
-+- late_init : to avoid display channel being re-initialized
-+  as we've probably setup the channel in bootloader: 0 or 1
-+- interface_pix_fmt : display interface pixel format as below:
-+	RGB666		IPU_PIX_FMT_RGB666
-+	RGB565		IPU_PIX_FMT_RGB565
-+	RGB24		IPU_PIX_FMT_RGB24
-+	BGR24		IPU_PIX_FMT_BGR24
-+	GBR24		IPU_PIX_FMT_GBR24
-+	YUV444		IPU_PIX_FMT_YUV444
-+	LVDS666		IPU_PIX_FMT_LVDS666
-+	YUYV		IPU_PIX_FMT_YUYV
-+	UYVY		IPU_PIX_FMT_UYVY
-+	YVYV		IPU_PIX_FMT_YVYU
-+	VYUY		IPU_PIX_FMT_VYUY
-+
-+Required properties for display:
-+- compatible : should be "fsl,lcd" for lcd panel, "fsl,imx6q-ldb" for ldb
-+- reg : the register address range if necessary to have.
-+- interrupts : the error and sync interrupts if necessary to have.
-+- clocks : the clock sources that it depends on if necessary to have.
-+- clock-names: the related clock names if necessary to have.
-+- ipu_id : ipu id for the first display device: 0 or 1
-+- disp_id : display interface id for the first display interface: 0 or 1
-+- default_ifmt : save as above display interface pixel format for lcd
-+- pinctrl-names : should be "default"
-+- pinctrl-0 : should be pinctrl_ipu1_1 or pinctrl_ipu2_1, which depends on the
-+  IPU connected.
-+- sec_ipu_id : secondary ipu id for the second display device(ldb only): 0 or 1
-+- sec_disp_id : secondary display interface id for the second display
-+  device(ldb only): 0 or 1
-+- ext_ref : reference resistor select for ldb only: 0 or 1
-+- mode : ldb mode as below:
-+	spl0		LDB_SPL_DI0
-+	spl1		LDB_SPL_DI1
-+	dul0		LDB_DUL_DI0
-+	dul1		LDB_DUL_DI1
-+	sin0		LDB_SIN0
-+	sin1		LDB_SIN1
-+	sep0		LDB_SEP0
-+	sep1		LDB_SEP1
-+- gpr : the mux controller for the display engine's display interfaces and the display encoder
-+	(only valid for mipi dsi now).
-+- disp-power-on-supply : the regulator to control display panel's power.
-+			(only valid for mipi dsi now).
-+- resets : the gpio pin to reset the display device(only valid for mipi display panel now).
-+- lcd_panel : the video mode name for the display device(only valid for mipi display panel now).
-+- dev_id : the display engine's identity within the system, which intends to replace ipu_id
-+	   (only valid for mipi dsi now).
-+
-+Example for IPU:
-+		ipu1: ipu@02400000 {
-+			compatible = "fsl,imx6q-ipu";
-+			reg = <0x02400000 0x400000>;
-+			interrupts = <0 6 0x4 0 5 0x4>;
-+			clocks = <&clks 130>, <&clks 131>, <&clks 132>,
-+				 <&clks 39>, <&clks 40>,
-+				 <&clks 135>, <&clks 136>;
-+			clock-names = "bus", "di0", "di1",
-+				      "di0_sel", "di1_sel",
-+				      "ldb_di0", "ldb_di1";
-+			resets = <&src 2>;
-+			bypass_reset = <0>;
-+		};
-+
-+Example for fb:
-+		fb0 {
-+			compatible = "fsl,mxc_sdc_fb";
-+			disp_dev = "ldb";
-+			interface_pix_fmt = "RGB666";
-+			mode_