summaryrefslogtreecommitdiffstats
path: root/arch/arm/boot/dts/armada-370-db.dts
AgeCommit message (Collapse)AuthorFilesLines
2015-09-29ARM: mvebu: define crypto SRAM ranges for all armada-370 boardsBoris Brezillon1-1/+2
Define the crypto SRAM ranges so that the resources referenced by the sa-sram node can be properly extracted from the DT. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-05-25ARM: mvebu: add "jedec,spi-nor" flash compatible bindingRafał Miłecki1-1/+1
Starting with commit 8947e396a829 ("Documentation: dt: mtd: replace "nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor" binding indicating support for JEDEC identification. Use it for all flashes that are supposed to support READ ID op according to the datasheets. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-04-14Merge tag 'mvebu-fixes-4.0-2' of git://git.infradead.org/linux-mvebu into ↵Arnd Bergmann1-1/+10
next/dt Pull "mvebu fix for 4.0" from Gregory CLEMENT: use 0xf1000000 as internal registers on Armada 370 DB: needed for the recent version of the board which no more comes with a bogus version of the Armada 370 SoC. * tag 'mvebu-fixes-4.0-2' of git://git.infradead.org/linux-mvebu: ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB ARM: mvebu: Disable CPU Idle on Armada 38x
2015-04-08ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DBThomas Petazzoni1-1/+10
All Marvell EBU SoCs (Kirkwood, Dove, Orion, Armada) have the capability of changing the location of their internal registers (i.e the registers for most hardware blocks inside the SoC). When coming out of reset, the internal registers are mapped at 0xd0000000, but since years and years, the tradition has been to have the internal registers remapped at 0xf1000000 by the bootloader, and Linux has since then assumed that the internal registers for the SoC were located at 0xf1000000 on Kirkwood, Dove, Orion, etc. Linux has never been aware that those registers are remappable (and there is no way to know where they are mapped at runtime, since the register to configure the address of the registers is itself within the internal registers). Then came the Armada 370 and Armada XP, in which some of the very early silicon steppings had an issue, which forced to use 0xd0000000: the SoC was no longer working properly when the internal registers were remapped at 0xf1000000. This issue is only affecting very early silicon steppings and production steppings are not affected: the issue has been fixed in between. Since what we (Free Electrons) used to do the initial submission of the Armada 370 and Armada XP platforms was evaluation boards with those very early steppings, we submitted Device Tree that assumed the internal registers were mapped at 0xd0000000. This is the case for Armada 370 DB, Armada XP DB and Armada XP GP. However, in practice, since Marvell has been shipping the evaluation boards with production steppings of the SoC, they are shipping those boards with bootloaders that remap the registers to 0xf1000000. We have already changed this internal register address to 0xf1000000 for the Armada XP DB in commit 82066bdb5a75 and for the Armada XP GP in commit 91ed32200e6e (both merged in v3.15). We only recently got our hand on an Armada 370 DB with a production stepping of the SoC, which uses a bootloader that remaps internal registers at 0xf1000000. Therefore, this commit aligns the Armada 370 DB to be like the Armada XP DB and Armada XP GP: assume that the internal registers are mapped at 0xf1000000. We would like to stress out the fact that the usage of 0xd0000000 as the internal register base address was a temporary workaround for early steppings deficiencies, and that the real long-term solution is the usage of 0xf1000000. Having 0xd0000000 is an *accident* in the life of the Marvell platform support in the kernel, as is confirmed by the usage of 0xf1000000 in all previous Marvell platforms (Dove, Kirkwood, Orion). There are unfortunately a number of commercial devices that continue to use 0xd0000000 even though they use production steppings of the SoC, simply because the vendors of such devices have never bothered using a more recent bootloader version from Marvell. There is not much we can do about it, and we plan on keeping 0xd0000000 in the Device Tree of such devices. The main reason for remapping the internal registers at 0xf1000000 instead of 0xd0000000 is that it leaves more space in the 0 -> 4 GB part of the physical address space for RAM. With registers at 0xd0000000, all RAM between 0xd0000000 to 0xffffffff is lost because it's covered by the I/O registers. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Jason Cooper <jason@lakedameon.net> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-03-04ARM: mvebu: use stdout-path in all armada-*.dtsThomas Petazzoni1-1/+1
This commit adds the stdout-path property in /chosen for all Armada boards that were not yet carrying this property, and gets rid of /chosen/bootargs which becomes unneeded: earlyprintk should not be used by default, and the console= parameter is replaced by the /chosen/stdout-path property. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-02-06Merge tag 'mvebu-dt-3.20-3' of git://git.infradead.org/linux-mvebu into next/dtOlof Johansson1-3/+37
Merge "ARM: mvebu: DT changes for v3.20 (round 2)" from Gregory CLEMENT: Relicense all Armada dts{i} files under dual license of GPLv2+ and X11. This should make it easier to reuse these files with other operating systems and boot loaders. * tag 'mvebu-dt-3.20-3' of git://git.infradead.org/linux-mvebu: (27 commits) ARM: mvebu: armada-xp-synology-ds414: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-openblocks-ax3-4: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-netgear-rn2120: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-mv78460: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-mv78260: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-mv78230: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-matrix: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-lenovo-ix4-300d: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-gp: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-db: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-xp-axpwifiap: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-38x: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-388-rd: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-385: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-388-db: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-380: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-375: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-375-db: Relicense the device tree under GPLv2+/X11 ARM: mvebu: armada-370-xp: Relicense the device tree under GPLv2+/X11 ... Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-26ARM: mvebu: armada-370-db: Relicense the device tree under GPLv2+/X11Gregory CLEMENT1-3/+37
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: Jason Cooper <jason@lakedaemon.net> Acked-by: Arnaud Ebalard <arno@natisbad.org> Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Simon Baatz <gmbnomis@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-21ARM: mvebu: Fix pinctrl configuration for Armada 370 DBGregory CLEMENT1-24/+0
The commit b4607572ef86 (ARM: mvebu: remove conflicting muxing on Armada 370 DB) removes the hog pins muxing. As it is explained in the commit log it solves a warning a boot time, but more important it also allows using the Giga port 0 of the board. Unfortunately in the same time the commit 4904a82a9399 (arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi) was merged and it introduced again the hog pins muxing. Because of it, the Giga port 0 of the board is no more usable. This commit remove again the conflicting muxing (hopefully for the last time). Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> [andrew@lunn.ch: Correct commit IDs] Signed-off-by: Andrew Lunn <andrew@lunn.ch> Fixes: 4904a82a9399 ("arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi")
2014-11-22arm: mvebu: define and use common Armada 370 SPI pinctrl settingsArnaud Ebalard1-0/+2
This patch defines common Armada 370 pinctrl settings for spi0 and spi1 interfaces: spi0: MPP33-36 as default, MPP32,63-65 as available alternate config spi1: MPP49-52 as default Currently, the Armada 370 DB .dts file has no explicit pinctrl info for the spi0 interface used to access the flash on the board. The patch fixes that by also adding explicit pinctrl info (MPP32,63-65) for this SPI interface. Note: this patch has the potential to break out-of-tree users w/o specific pinctrl settings for their spi interfaces if the default above does not match their config. Suggested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Link: https://lkml.kernel.org/r/1e812eb63b37718e273463e22e4d7512f8f0b624.1416613429.git.arno@natisbad.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-22arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsiArnaud Ebalard1-0/+24
What was done by Sebastian in 264a05e19bf5 ("ARM: mvebu: armada-xp: Add node alias to pinctrl and add base address") and 01c434225ee6 ("ARM: mvebu: armada-xp: Use pinctrl node alias") can also be done for Armada 370, i.e. - Rename Armada 370 pinctrl node to pin-ctrl with its address encoded - Add a node alias to access the pinctrl node easily. - use the newly available alias in existing Armada 370 .dts files We can even go a bit further by putting the pinctrl node definition in armada-370-xp.dtsi, with only its reg property defined. This allows us to then also use the newly defined node alias in armada-xp.dtsi, armada-370.dtsi. Suggested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Suggested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Link: https://lkml.kernel.org/r/b54eb45e5242728aace3ce8aef2eae4251f8dea3.1416613429.git.arno@natisbad.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-07ARM: mvebu: use simple-card DT binding for audio on Armada 370 DBThomas Petazzoni1-6/+50
This commit modifies the Armada 370 and Armada 370 DB Device Tree descriptions to use the simple-card DT binding to describe the audio complex of the Armada 370 DB instead of a custom audio machine driver. To do so, it: - Adds the sound-dai-cells properties to the CS42L51 node, the audio controller node and the SPDIF in/out nodes. - Completely changes the description of the sound complex to use the "simple-audio-card" DT binding instead of the "marvell,a370db-audio" DT binding. - Fixes the indentation to properly use tabs instead of spaces. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1414512524-24466-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-07ARM: mvebu: remove conflicting muxing on Armada 370 DBThomas Petazzoni1-24/+0
Back when audio was enabled, the muxing of some MPP pins was causing problems. However, since commit fea038ed55ae ("ARM: mvebu: Add proper pin muxing on the Armada 370 DB board"), those problematic MPP pins have been assigned a proper muxing for the Ethernet interfaces. This proper muxing is now conflicting with the hog pins muxing that had been added as part of 249f3822509b ("ARM: mvebu: add audio support to Armada 370 DB"). Therefore, this commit simply removes the hog pins muxing, which solves a warning a boot time due to the conflicting muxing requirements. Fixes: fea038ed55ae ("ARM: mvebu: Add proper pin muxing on the Armada 370 DB board") Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1414512524-24466-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-08-17ARM: mvebu: Add proper pin muxing on the Armada 370 DB boardEzequiel Garcia1-0/+6
This commit adds the required pin muxing for the network interfaces and the MDIO interface to be properly initialized. For instance, this makes it possible for a bootloader to initialize and access the network interfaces Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/1407759281-11513-4-git-send-email-ezequiel.garcia@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-06-02Merge tag 'dt-for-3.16' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into next Pull ARM SoC devicetree updates from Olof Johansson: "As with previous release, this continues to be among the largest branches we merge, with lots of new contents. New things for this release are among other things: - DTSI contents for the new SoCs supported in 3.16 (see SoC pull request) - Qualcomm APQ8064 and APQ8084 SoCs and eval boards - Nvidia Jetson TK1 development board (Tegra T124-based) Two new SoCs that didn't need enough new platform code to stand out enough for me to notice when writing the SoC tag, but that adds new DT contents are: - TI DRA72 - Marvell Berlin 2Q" * tag 'dt-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (500 commits) ARM: dts: add secure firmware support for exynos5420-arndale-octa ARM: dts: add pmu sysreg node to exynos3250 ARM: dts: correct the usb phy node in exynos5800-peach-pi ARM: dts: correct the usb phy node in exynos5420-peach-pit ARM: dts: add dts files for exynos5410 and exynos5410-smdk5410 ARM: dts: add dts files for exynos3250 SoC ARM: dts: add mfc node for exynos5800 ARM: dts: add Vbus regulator for USB 3.0 on exynos5800-peach-pi ARM: dts: enable fimd for exynos5800-peach-pi ARM: dts: enable display controller for exynos5800-peach-pi ARM: dts: enable hdmi for exynos5800-peach-pi ARM: dts: add dts file for exynos5800-peach-pi board ARM: dts: add dts file for exynos5800 SoC ARM: dts: add dts file for exynos5260-xyref5260 board ARM: dts: add dts files for exynos5260 SoC ARM: dts: update watchdog node name in exynos5440 ARM: dts: use key code macros on Origen and Arndale boards ARM: dts: enable RTC and WDT nodes on Origen boards ARM: dts: qcom: Add APQ8084-MTP board support ARM: dts: qcom: Add APQ8084 SoC support ...
2014-04-26ARM: mvebu: remove clock-frequency of serial port Device Tree nodesThomas Petazzoni1-1/+0
Now that the Armada 370/375/38x/XP SoC-level Device Tree files have the proper "clocks" property in their UART controllers node, it is no longer useful to have the clock-frequency property defined in the board-level Device Tree files. Therefore, this commit gets rid of all the useless 'clock-frequency' properties. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397806908-7550-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-25ARM: mvebu: specify I2C bus frequency on Armada 370 DBThomas Petazzoni1-0/+1
In commit 249f3822509b74f8c8d0731aeb7ccea065376c9b ('ARM: mvebu: add audio support to Armada 370 DB'), the I2C bus 0 was enabled on the Armada 370 DB board, and an I2C codec was described as being connected on this bus. However, this commit forgot to define the I2C bus frequency, which leads the i2c-mv64xxx to fail probing, as it cannot calculate the baud rate multiplier/divisor to derive the I2C bus frequency from the core SoC frequency. It makes audio completely unusable, as the I2C bus is not probed, and therefore the audio codec is not probed either. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397806908-7550-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-02-17ARM: mvebu: enable S/PDIF audio in Armada 370 DB Device TreeThomas Petazzoni1-1/+9
In addition to the analog audio input and output, the Armada 370 DB also has S/PDIF input and output optical connectors. This commit improves the Device Tree description of the Armada 370 DB platform to enable the S/PDIF support. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-02-17ARM: mvebu: add audio support to Armada 370 DBThomas Petazzoni1-0/+48
This commit adds the necessary Device Tree informations to enable audio support on the Armada 370 DB platform. In details it: * Instantiates the CS42L51 audio codec on the I2C0 bus, and configures this bus with the appropriate pin-muxing configuration. * Enables the I2S audio controller, and configures it with the appropriate pin-muxing configuration. * Through hog pins, ensures that the other pins possibly used for I2S are muxed with another function than I2S. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-11-25ARM: mvebu: re-enable PCIe on Armada 370 DBThomas Petazzoni1-14/+14
Commit 14fd8ed0a7fd19913 ("ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes") relocated the PCIe controller DT nodes one level up in the Device Tree, to reflect a more correct representation of the hardware introduced by the mvebu-mbus Device Tree binding. However, while most of the boards were properly adjusted accordingly, the Armada 370 DB board was left unchanged, and therefore, PCIe is seen as not enabled on this board. This patch fixes that by moving the PCIe controller node one level-up in armada-370-db.dts. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.12+ Fixes: 14fd8ed0a7fd19913 "ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes" Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06ARM: mvebu: Add BootROM to Armada 370/XP device treeEzequiel Garcia1-1/+2
In order to access the SoC BootROM, we need to declare a mapping (through a ranges property). The mbus driver will use this property to allocate a suitable address decoding window. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06ARM: mvebu: Add MBus to Armada 370/XP device treeEzequiel Garcia1-0/+2
The Armada 370/XP SoC family has a completely configurable address space handled by the MBus controller. This patch introduces the device tree layout of MBus, making the 'soc' node as mbus-compatible. Since every peripheral/controller is a child of this 'soc' node, this makes all of them sit behind the mbus, thus describing the hardware accurately. A translation entry has been added for the internal-regs mapping. This can't be done in the common armada-370-xp.dtsi because A370 and AXP have different addressing width. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06ARM: mvebu: Use the preprocessor on Armada 370/XP device tree filesEzequiel Garcia1-1/+1
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-15ARM: mvebu: Use standard MMC binding for all users of mvsdioSimon Baatz1-0/+1
In order to prepare the switch to the standard MMC device tree parser for mvsdio, adapt all current uses of mvsdio in the dts files to the standard format. Signed-off-by: Simon Baatz <gmbnomis@gmail.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15ARM: dts: mvebu: introduce internal-regs nodeGregory CLEMENT1-66/+68
Introduce a 'internal-regs' subnode, under which all devices are moved. This is not really needed for now, but will be for the mvebu-mbus driver. This generates a lot of code movement since it's indenting by one more tab all the devices. So it was a good opportunity to fix all the bad indentation. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15ARM: dts: mvebu: Convert all the mvebu files to use the range propertyGregory CLEMENT1-8/+8
This conversion will allow to keep 32 bits addresses for the internal registers whereas the memory of the system will be 64 bits. Later it will also ease the move of the mvebu-mbus driver to the device tree support. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15arm: mvebu: PCIe Device Tree informations for Armada 370 DBThomas Petazzoni1-0/+17
The Marvell evaluation board (DB) for the Armada 370 SoC has 2 physical full-size PCIe slots, so we enable the corresponding PCIe interfaces in the Device Tree. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-02-28arm: mvebu: Add SPI flash on Armada 370 DB boardGregory CLEMENT1-0/+12
This patch add support for the SPI flash MX25l25635E which is present on the Armada 370 DB board. This flash stores the bootloader and its environment. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-02-28arm: mvebu: Enable USB controllers on Armada 370/XP boardsEzequiel Garcia1-0/+8
This patch activates every USB port provided by each SoC. Except for Armada XP Openblocks AX3-4 board, where we enable only the first two USB ports until we have more information on the third one usage. Cc: Lior Amsalem <alior@marvell.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Tested-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-02-28arm: mvebu: enable the SD card slot on Armada 370 DB boardThomas Petazzoni1-0/+15
The Armada XP DB evaluation board has one SD card slot, directly connected to the SDIO IP of the SoC, so we add a device tree description for it. However, in the default configuration of the board, the SD card slot is not usable: the connector plugged into CON40 must be changed against a different one, provided with the board by the manufacturer. Since such a manual modification of the hardware is needed, we did not enable the SDIO interface by default, and left it to the board user to modify the Device Tree if needed. Since this board is really only an evaluation board for developers and not a final product, it is not too bad. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-01-10arm: mvebu: Fix memory size for Armada 370 DBGregory CLEMENT1-1/+1
Actually the Armada 370 DB (aka DB-88F6710-BP-DDR3) come with 1GB and not 512MB. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-11-20arm: mvebu: remove 'clock-frequency' properties from Armada 370/XP Ethernet ↵Thomas Petazzoni1-2/+0
nodes The mvneta driver for the Marvell Armada 370/XP Ethernet devices has gained proper clock framework integration, and the corresponding Device Tree nodes now have a correct 'clocks' pointer. The 'clock-frequency' properties in the various .dts files for Armada 370/XP boards have therefore become useless. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-11-20Merge tag 'marvell-boards-net-for-3.8' of ↵Thomas Petazzoni1-0/+23
github.com:MISL-EBU-System-SW/mainline-public into test-the-merge Marvell boards changes related to Ethernet, for 3.8 Conflicts: arch/arm/boot/dts/armada-370-xp.dtsi arch/arm/boot/dts/armada-xp-db.dts
2012-11-20arm: mvebu: SATA support: board-level DT data for Armada 370/XP boardsGregory CLEMENT1-0/+4
Add the SATA device tree bindings for - Armada XP evaluation board (DB-78460-BP) - Armada 370 evaluation board (DB-88F6710-BP-DDR3) Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-11-20clocksource: convert time-armada-370-xp to clk frameworkGregory CLEMENT1-4/+0
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by Gregory CLEMENT <gregory.clement@free-electrons.com>
2012-11-16arm: mvebu: enable Ethernet controllers on Armada 370/XP eval boardsThomas Petazzoni1-0/+23
This patch enables the two network interfaces of the Armada 370 official Marvell evaluation platform, and the four network interfaces of the Armada XP official Marvell evaluation platform. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-07-10arm: mach-mvebu: add support for Armada 370 and Armada XP with DTThomas Petazzoni1-0/+42
[ben.dooks@codethink.co.uk: ensure error check on of_property_read_u32] [ben.dooks@codethink.co.uk: use mpic address instead of bus-unit's ] [ben.dooks@codethink.co.uk: BUG_ON() if the of_iomap() fails for mpic] [ben.dooks@codethink.co.uk: move mpic per-cpu register base ] [ben.dooks@codethink.co.uk: number fetch should use irqd_to_hwirq()] Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Yehuda Yitschak <yehuday@marvell.com> Tested-by: Lior Amsalem <alior@marvell.com>