GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.
The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf*colibri* files to this combination.
CCs were acquired using:
git shortlog -sne --no-merges arch/arm/boot/dts/vf*colibri*
Acked-by: Cory Tusar <cory.tusar@pid1solutions.com>
Acked-by: Sanchayan Maity <maitysanchayan@gmail.com>
Acked-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Linux on Vybrid used several different L2 latencies so far, none
of them seem to be the right ones. According to the application note
AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
on CPU clock and is inside the L2 cache controller, whereas the data
portion is stored in the external SRAM running on platform clock.
Hence it is likely that the correct value requires a higher data
latency then tag latency.
These are the values which have been used so far:
- The mainline values:
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
Those values have lead to problems on higher clocks. They look
like a poor translation from the reset values (missing +1 offset
and a mix up between tag/latency values).
- The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
arm,data-latency = <4 2 3>
arm,tag-latency = <4 2 3>
The cache initialization function along with the value matches the
i.MX6 code from the same kernel, so it seems that those values have
just been copied.
- The Colibri values:
arm,data-latency = <2 1 2>;
arm,tag-latency = <3 2 3>;
Those were a mix between the values of the Linux 3.0 based BSP and
the mainline values above.
- The SoC Reset values (converted to DT notation):
arm,data-latency = <3 3 3>;
arm,tag-latency = <2 2 2>;
So far there is no official statement on what the correct values are.
See also the related Freescale community thread:
https://community.freescale.com/message/579785#579785
For now, the reset values seem to be the best bet. Remove all other
"bogus" values and use the reset value on vf610.dtsi level.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add Colibri VF50 device tree files vf500-colibri.dtsi and
vf500-colibri-eval-v3.dts, in line with the Colibri VF61 device tree
files. However, to minimize dupplication we also add vf-colibri.dtsi
and vf-colibri-eval-v3.dtsi which contain the common device tree
nodes.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
This adds more generic base device trees for Vybrid SoCs. There
are three series of Vybrid SoC commonly available:
- VF3xx series: single core, Cortex-A5 without external memory
- VF5xx series: single core, Cortex-A5
- VF6xx series: dual core, Cortex-A5/Cortex-M4
The second digit represents the presents of a L2 cache (VFx1x).
The VF3xx series are not suitable for Linux especially since the
internal memory is quite small (1.5MiB).
The VF500 is essentially the base SoC, with only one core and
without L1 cache. The VF610 is a superset of the VF500, hence
vf500.dtsi is then included and enhanced by vf610.dtsi. There is
no board using VF510 or VF600 currently, but, if needed, they can
be added easily.
The Linux kernel can also run on the Cortex-M4 CPU of Vybrid
using !MMU support. This patchset creates a device tree structure
which allows to share peripherals nodes for a VF6xx Cortex-M4
device tree too. The two CPU types have different views of the
system: Foremost they are using different interrupt controllers,
but also the memory map is slightly different. The base device
tree vfxxx.dtsi allows to create SoC and board level device trees
supporting the Cortex-M4 while reusing the shared peripherals
nodes.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The Colibri standard defines four pins as PWM outputs, two of them (PWM
A and C) are routed to FTM instance 0 and the other two (PWM B and D)
are routed to FTM instance 1. Hence enable both FTM instances for the
Colibri module and mux the four pins accordingly.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Add USB support for Colibri VF61 modules. The Colibri standard pinout
defines a pin for USB over-current. However, due to lack of pinmux
options, the USB hosts over-current protection signal of the Colibri
standard could not be connected to the PHY's over-current protection.
Hence we need to disable the over-current functionality of the USB
controller.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
The Colibri VF61 is a module which needs a carrier board to actually
run. Different carrier board have different hardware support, hence
we should reflect this in the device tree files. This patch adds the
Colibri Evaluation Board, which supports almost all peripherals
defined in the Colibri standard.
Also align the compatible naming, file splitting and file naming with
the scheme which was choosen for the Tegra based modules.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Stefan Agner