diff options
Diffstat (limited to 'target/arm')
| -rw-r--r-- | target/arm/cubox-i/patches/3.10.33/solidrun-cubox-i.patch | 584365 | ||||
| -rw-r--r-- | target/arm/raspberry-pi/patches/3.10.33/raspberry-pi.patch | 101472 |
2 files changed, 685837 insertions, 0 deletions
diff --git a/target/arm/cubox-i/patches/3.10.33/solidrun-cubox-i.patch b/target/arm/cubox-i/patches/3.10.33/solidrun-cubox-i.patch new file mode 100644 index 000000000..beaa71b4e --- /dev/null +++ b/target/arm/cubox-i/patches/3.10.33/solidrun-cubox-i.patch @@ -0,0 +1,584365 @@ +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_str ="LDB-XGA"; ++ default_bpp = <16>; ++ int_clk = <0>; ++ late_init = <0>; ++ status = "okay"; ++ }; ++ ++Example for ldb display: ++ ldb@020e0000 { ++ ipu_id = <1>; ++ disp_id = <0>; ++ ext_ref = <1>; ++ mode = "sep0"; ++ sec_ipu_id = <1>; ++ sec_disp_id = <1>; ++ status = "okay"; ++ }; ++ ++Example for mipi dsi display: ++ mipi_dsi: mipi@021e0000 { ++ compatible = "fsl,imx6q-mipi-dsi"; ++ reg = <0x021e0000 0x4000>; ++ interrupts = <0 102 0x04>; ++ gpr = <&gpr>; ++ clocks = <&clks 138>, <&clks 204>; ++ clock-names = "mipi_pllref_clk", "mipi_cfg_clk"; ++ dev_id = <0>; ++ disp_id = <0>; ++ lcd_panel = "TRULY-WVGA"; ++ disp-power-on-supply = <®_mipi_dsi_pwr_on> ++ resets = <&mipi_dsi_reset>; ++ status = "okay"; ++ }; +diff -Nur linux-3.10.30/Documentation/devicetree/bindings/fb/mxsfb.txt linux-3.10.30-cubox-i/Documentation/devicetree/bindings/fb/mxsfb.txt +--- linux-3.10.30/Documentation/devicetree/bindings/fb/mxsfb.txt 2014-02-13 22:48:15.000000000 +0100 ++++ linux-3.10.30-cubox-i/Documentation/devicetree/bindings/fb/mxsfb.txt 2014-03-08 20:32:51.000000000 +0100 +@@ -3,6 +3,9 @@ + Required properties: + - compatible: Should be "fsl,<chip>-lcdif". Supported chips include + imx23 and imx28. |