- Jan 27, 2015
-
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Acked-by:
Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Acked-by:
Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Arnaud Ebalard <arno@natisbad.org> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Willy Tarreau <w@1wt.eu>
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Benoit Masson <yahoo@perenite.com> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Simon Baatz <gmbnomis@gmail.com> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Marcin Wojtas <mw@semihalf.com> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Greg Ungerer <gerg@uclinux.org> Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Simon Guinot <simon.guinot@sequanux.org> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Ben Peddell <klightspeed@killerwolves.net> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Ryan Press <ryan@presslab.us> Acked-by:
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
-
Gregory CLEMENT authored
The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by:
-
- Jan 22, 2015
-
-
Paul Bolle authored
The Kconfig symbol DEBUG_MVEBU_UART_ALTERNATE was renamed to DEBUG_MVEBU_UART0_ALTERNATE. And the symbol DEBUG_MVEBU_UART1_ALTERNATE was added to allow UART1 as a DEBUG_LL target. Make the comment at the top of this DTS reflect those changes. Since we're touching this DTS add comments to show which blocks describe UART0 and UART1. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Gregory CLEMENT authored
Add the regulators to each SATA port. Signed-off-by: -
Christoph Junghans authored
The pogoplug differs from the SheevaPlug only by a few details, but especially in the led assignments. This patch was tested under Gentoo Linux and is based on dts files from Arch Linux ARM and OpenWrt. Suggested-by:
Felix Kaechele <heffer@fedoraproject.org> Suggested-by:
Oleg Rakhmanov <moonman.ca@gmail.com> Signed-off-by:
Christoph Junghans <ottxor@gentoo.org> [Andrew Lunn <andrew@lunn.ch>: Fixed subject line] Signed-off-by:
-
- Jan 11, 2015
-
-
Thomas Petazzoni authored
Due to the special handling of window 13 on Armada 375 and Armada 38x (similar to Armada XP), the MBus hardware block is *not* compatible with the one used on Armada 370. Using the Armada 370 compatible string on Armada 375 and 38x will lead to a non-working device if window 13 ends up being used. Signed-off-by:
-
- Jan 10, 2015
-
-
Thomas Petazzoni authored
Contrary to what was originally thought, the Armada 375 and Armada 38x MBus windows hardware block is *not* compatible with the Armada 370, due to a difference in how window 13 is handled. It was rather compatible with the Armada XP MBus hardware block. However, the DTs for Armada 375 and Armada 38x encode the following compatible string for MBus: compatible = "marvell,armada375-mbus", "marvell,armada370-mbus", "simple-bus"; compatible = "marvell,armada380-mbus", "marvell,armada370-mbus", "simple-bus"; So, by extending the mvebu-mbus DT binding to also cover the marvell,armada375-mbus and marvell,armada380-mbus compatible strings, we can define a new behavior for those SoCs without changing the DT. Therefore, this commit adds those two new compatible strings to the DT binding documentation of mvebu-mbus. Note that it re-uses two existing duplicated lines for the armada370-mbus and armadaxp-mbus compatible strings. Signed-off-by:
-
- Jan 09, 2015
-
-
Gregory CLEMENT authored
The A388-GP is a board produced by Marvell that holds - 1 PCIe slot - 2 mini PCIe slot (one of them is multiplexed with the PCIe slot, muxing is selected through the GPIO expander) - 1 16MB SPI-NOR - 2 Gigabit Ethernet ports - 4 SATA ports (2 of them are multiplexed with the mini PCIe slots, muxing is selected through the GPIO expander) - 1 SDIO slot - 1 USB3 port - 2 USB2 port - 2 GPIO/interrupts expander on I2C Signed-off-by:
-
Gregory CLEMENT authored
This SoC belongs to the Armada 38x family. The main difference with the Armada 385 is that the 388 can handle two more SATA ports. Currently the consequence is the use of a different compatible string for the pinctrl node, in order to be able to use the pins associated to this 2 new SATA ports. The second SATA controller has also been moved from the armada38x.dtsi as it it specific to the Armada388 version. In the same time the Armada385 DB and Armada 385 RD board have been renamed in the 388 one and now include the armada-388.dtsi file. AS both of them have 4 SATA ports the SoC used on them were wrongly described. Signed-off-by:
-
Gregory CLEMENT authored
Update the binding documentation of the Armada 38x Soc family with the Armada 388. Signed-off-by:
-
Gregory CLEMENT authored
The pintcrl label was missing. Adding it allowed referring it from the root of the device tree. Also add the uart0 label used by the bootloader. Signed-off-by:
-
Gregory CLEMENT authored
With the Armada 385 GP board more pinctrl functions depending of the SoC are needed. Add them to the DTSI to avoid duplication. Signed-off-by:
-
Maxime Ripard authored
The A385-AP is a board produced by Marvell that holds 3 mPCIe slot, a 16MB SPI-NOR, 3 Gigabit Ethernet ports, USB3 and NAND flash storage. [gregory.clement@free-electrons.com: switch the license to the dual X11/GPL with the agreement of the author] Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Maxime Ripard authored
Some pinctrl functions can be shared with all DTS out there, since they are generic, SoC-wide muxing options. Add a number of these to the DTSI to avoid duplication. Signed-off-by:
-
Maxime Ripard authored
The compatible set in the armada-38x DTSI is always overridden, and the reg defined in there is duplicated in the armada-380 and armada-385 DTSIs. Remove these useless items. Signed-off-by:
-
Maxime Ripard authored
Some nodes in the DTs have a reg property but no unit name in their node name. This contradicts the way the ePAPR defines the node names. Fix this. Signed-off-by:
-
