summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
AgeCommit message (Collapse)AuthorFilesLines
2018-05-18ARM: dts: armada-370-xp: update NAND node with new bindingsMiquel Raynal1-40/+50
Use the new bindings of the Marvell NAND controller driver. Also adapt the NAND controller node organization to distinguish which property is relevant for the controller, and which one is NAND chip specific. Expose the partitions as a subnode of the NAND chip. Remove the 'marvell,nand-enable-arbiter' property, not needed anymore as the new driver activates the arbiter by default for all boards which is either needed or harmless. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-27arm: dts: armada-*.dts: use SPDX-License-Identifier for most of the Armada ↵Gregory CLEMENT1-38/+1
based board Follow the recent trend for the license description, and also fix the wrongly stated X11 to MIT. As already pointed on the DT ML, the X11 license text [1] is explicitly for the X Consortium and has a couple of extra clauses. The MIT license text [2] is actually what the current DT files claim. [1] https://spdx.org/licenses/X11.html [2] https://spdx.org/licenses/MIT.html Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-02-13ARM: dts: armada: netgear-rn*: fix rtc node nameAlexandre Belloni1-1/+1
The node name should be generic and must not contain the part number. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2017-01-03ARM: dts: mvebu: Correct license textAlexandre Belloni1-5/+5
The license text has been mangled at some point then copy pasted across multiple files. Restore it to what it should be. Note that this is not intended as a license change. Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Stefan Roese <sr@denx.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-11-19ARM: dts: armada-370-xp: Fixup memory DT warningGregory CLEMENT1-1/+1
memory has a reg property so the unit name should contain an address. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-11-19ARM: dts: armada-xp: Fixup pcie DT warningsGregory CLEMENT1-22/+22
PCIe has a range property, so the unit name should contain an address. Take the opportunity to use the node label instead of the full name. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-11-19ARM: dts: armada-370-xp: Fixup mdio DT warningGregory CLEMENT1-10/+11
MDIO has a reg property so the unit name should contain an address. Take the opportunity to use the node label instead of the full name. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-10-17ARM: dts: armada-xp-rn2120: add pinmuxing for ethernetUwe Kleine-König1-0/+6
Up to now working ethernet depended on the bootloader to configure the pinmuxing. Make it explicit. As a side effect this change makes ethernet work in barebox. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-10-17ARM: dts: armada-xp-rn2120: drop wrong compatible for i2c0Uwe Kleine-König1-1/+0
The compatible is supposed to be "marvell,mv78230-i2c", "marvell,mv64xxx-i2c", as provided by armada-xp.dtsi. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-03-11ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory windowThomas Petazzoni1-2/+2
When the Crypto SRAM mappings were added to the Device Tree files describing the Armada XP boards in commit c466d997bb16 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards"), the fact that those mappings were overlaping with the PCIe memory aperture was overlooked. Due to this, we currently have for all Armada XP platforms a situation that looks like this: Memory mapping on Armada XP boards with internal registers at 0xf1000000: - 0x00000000 -> 0xf0000000 3.75G RAM - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB) - 0xf1000000 -> 0xf1100000 1M internal registers - 0xf8000000 -> 0xffe0000 126M PCIe memory aperture - 0xf8100000 -> 0xf8110000 64KB Crypto SRAM #0 => OVERLAPS WITH PCIE ! - 0xf8110000 -> 0xf8120000 64KB Crypto SRAM #1 => OVERLAPS WITH PCIE ! - 0xffe00000 -> 0xfff00000 1M PCIe I/O aperture - 0xfff0000 -> 0xffffffff 1M BootROM The overlap means that when PCIe devices are added, depending on their memory window needs, they might or might not be mapped into the physical address space. Indeed, they will not be mapped if the area allocated in the PCIe memory aperture by the PCI core overlaps with one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB of PCIe memory will see its PCIe memory window allocated from 0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due to this, the PCIe window is not created, and any attempt to access the PCIe window makes the kernel explode: [ 3.302213] igb: Copyright (c) 2007-2014 Intel Corporation. [ 3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143) [ 3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window [ 3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22 [ 3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018 This problem does not occur on Armada 370 boards, because we use the following memory mapping (for boards that have internal registers at 0xf1000000): - 0x00000000 -> 0xf0000000 3.75G RAM - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB) - 0xf1000000 -> 0xf1100000 1M internal registers - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 => OK ! - 0xf8000000 -> 0xffe0000 126M PCIe memory - 0xffe00000 -> 0xfff00000 1M PCIe I/O - 0xfff0000 -> 0xffffffff 1M BootROM Obviously, the solution is to align the location of the Crypto SRAM mappings of Armada XP to be similar with the ones on Armada 370, i.e have them between the "internal registers" area and the beginning of the PCIe aperture. However, we have a special case with the OpenBlocks AX3-4 platform, which has a 128 MB NOR flash. Currently, this NOR flash is mapped from 0xf0000000 to 0xf8000000. This is possible because on OpenBlocks AX3-4, the internal registers are not at 0xf1000000. And this explains why the Crypto SRAM mappings were not configured at the same place on Armada XP. Hence, the solution is two-fold: (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from 0xe8000000 to 0xf0000000. This frees the 0xf0000000 -> 0xf80000000 space. (2) Move the Crypto SRAM mappings on Armada XP to be similar to Armada 370 (except of course that Armada XP has two Crypto SRAM and not one). After this patch, the memory mapping on Armada XP boards with registers at 0xf1 is: - 0x00000000 -> 0xf0000000 3.75G RAM - 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB) - 0xf1000000 -> 0xf1100000 1M internal registers - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 - 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1 - 0xf8000000 -> 0xffe0000 126M PCIe memory - 0xffe00000 -> 0xfff00000 1M PCIe I/O - 0xfff0000 -> 0xffffffff 1M BootROM And the memory mapping for the special case of the OpenBlocks AX3-4 (internal registers at 0xd0000000, NOR of 128 MB): - 0x00000000 -> 0xc0000000 3G RAM - 0xd0000000 -> 0xd1000000 1M internal registers - 0xe800000 -> 0xf0000000 128M NOR flash - 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 - 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1 - 0xf8000000 -> 0xffe0000 126M PCIe memory - 0xffe00000 -> 0xfff00000 1M PCIe I/O - 0xfff0000 -> 0xffffffff 1M BootROM Fixes: c466d997bb16 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards") Reported-by: Phil Sutter <phil@nwl.cc> Cc: Phil Sutter <phil@nwl.cc> Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-12-15ARM: dts: armada: replace isil, irq2-can-wakeup-machine with wakeup-source ↵Sudeep Holla1-1/+1
property Though the driver will continue to check for and support the legacy "isil,irq2-can-wakeup-machine" boolean property to wakeup source, "wakeup-source" is the new standard binding. This patch replaces the legacy "isil,irq2-can-wakeup-machine" with the unified "wakeup-source" property in order to avoid any futher copy-paste duplication. Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-10-12arm: mvebu: reorder nodes under internal-regs by address in RN2120 .dts fileArnaud Ebalard1-43/+43
This cosmetic patch reorder nodes under internal-regs by increasing address order, as expected. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-10-12arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120Arnaud Ebalard1-0/+6
By default, armada-370-xp.dtsi file has internal RTC enabled. NETGEAR ReadyNAS 102, 104 and 2120 all use an Intersil ISL12057 I2C RTC chip. The internal RTC not being disabled in the .dts files of those devices result in the following useless first line during boot: [ 4.500056] rtc-mv d0010300.rtc: internal RTC not ticking [ 4.505684] i2c /dev entries driver [ 4.513246] rtc-isl12057 0-0068: rtc core: registered rtc-isl12057 as rtc0 This patch marks Armada internal RTC as disabled in individual .dts files of those devices. Reported-by: TuxOholic <tuxoholic@hotmail.de> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-09-29ARM: mvebu: define crypto SRAM ranges for all armada-xp boardsBoris Brezillon1-1/+3
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-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-17Merge tag 'dt-for-linus' of ↵Linus Torvalds1-4/+37
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC DT updates from Olof Johansson: "DT changes continue to be the bulk of our merge window contents. We continue to have a large set of changes across the board as new platforms and drivers are added. Some of the new platforms are: - Alphascale ASM9260 - Marvell Armada 388 - CSR Atlas7 - TI Davinci DM816x - Hisilicon HiP01 - ST STiH418 There have also been some sweeping changes, including relicensing of DTS contents from GPL to GPLv2+/X11 so that the same files can be reused in other non-GPL projects more easily. There's also been changes to the DT Makefile to make it a little less conflict-ridden and churny down the road" * tag 'dt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (330 commits) ARM: dts: Add PPMU node for exynos4412-trats2 ARM: dts: Add PPMU node for exynos3250-monk and exynos3250-rinato ARM: dts: Add PPMU dt node for exynos4 and exynos4210 ARM: dts: Add PPMU dt node for exynos3250 ARM: dts: add mipi dsi device node for exynos4415 ARM: dts: add fimd device node for exynos4415 ARM: dts: Add syscon phandle to the video-phy node for Exynos4 ARM: dts: Add sound nodes for exynos4412-trats2 ARM: dts: Fix CLK_MOUT_CAMn parent clocks assignment for exynos4412-trats2 ARM: dts: Fix CLK_UART_ISP_SCLK clock assignment in exynos4x12.dtsi ARM: dts: Add max77693 charger node for exynos4412-trats2 ARM: dts: Switch max77686 regulators to GPIO control for exynos4412-trats2 ARM: dts: Add suspend configuration for max77686 regulators for exynos4412-trats2 ARM: dts: Add Maxim 77693 fuel gauge node for exynos4412-trats2 ARM: dts: am57xx-beagle-x15: Fix USB2 mode ARM: dts: am57xx-beagle-x15: Add extcon nodes for USB ARM: dts: dra72-evm: Add extcon nodes for USB ARM: dts: dra7-evm: Add extcon nodes for USB ARM: dts: rockchip: move the hdmi ddc-i2c-bus property to the actual boards ARM: dts: rockchip: enable vops and hdmi output on rk3288-firefly and -evb ...
2015-02-14ARM: mvebu: ISL12057 rtc chip can now wake up RN102, RN102 and RN2120Arnaud Ebalard1-0/+1
Now that alarm support for ISL12057 chip is available w/ the specific "isil,irq2-can-wakeup-machine" property, let's use that feature of the driver dedicated to NETGEAR ReadyNAS 102, 104 and 2120 specific routing of RTC Alarm IRQ#2 pin; on those devices, this pin is not connected to the SoC but to a PMIC, which allows the device to be powered up when RTC alarm rings. For that to work, the chip needs to be explicitly marked as a device wakeup source using this "isil,irq2-can-wakeup-machine" boolean property. This makes 'wakealarm' sysfs entry available to configure the alarm. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Peter Huewe <peter.huewe@infineon.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Darshana Padmadas <darshanapadmadas@gmail.com> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Landley <rob@landley.net> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Kumar Gala <galak@codeaurora.org> Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-01-27ARM: mvebu: armada-xp-netgear-rn2120: Relicense the device tree under GPLv2+/X11Gregory CLEMENT1-4/+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: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-11-02ARM: mvebu: armada-xp: Use pinctrl node aliasSebastian Hesselbarth1-82/+82
Armada XP pinctrl node gained an alias, make use of it. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: armada-xp: Add node alias to pinctrl and add base addressSebastian Hesselbarth1-1/+1
In other MVEBU SoCs, the pin controller node is called pin-ctrl with its base address added. Also, we have a node alias to access the pinctrl node easily. Fix this for Armada XP pinctrl nodes to be consistent with other SoCs. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: Enable rear eSATA ports of NETGEAR ReadyNAS 2120Arnaud Ebalard1-0/+6
NETGEAR ReadyNAS 2120 supports its four main SATA disks via 2 Marvell 88SE9170 SATA controllers connected on the PCIe bus of the the SoC. The two eSATA ports available at the rear of the device are handled by the native SATA controller of the Armada XP SoC powering the NAS. This patch enables the SoC SATA controller in the .dts file to make those two rear ports available. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Acked-by: Andrew Lunn <andrew@lunn.ch> Link: https://lkml.kernel.org/r/f3876c7a9ef11eb758b9df18c671ee740b8be614.1414250947.git.arno@natisbad.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-10-09Merge tag 'dt-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC DT updates from Arnd Bergmann: "As usual, this is the largest branch, though this time a little under half of the total changes with 307 individual non-merge changesets. The largest changes are the addition of new machines, in particular the Tegra based Chromebook, the Renesas r8a7794 SoC, and DT support for the old i.MX1 platform. Other changes include - at91: various sam9 and sama5 updates - exynos: much extended Peach Pi/Pit (Chromebook 2) support - keystone: new peripherals - meson: added DT for meson6 SoC - mvebu: new device support for Armada 370/375 - qcom: improved support for IPQ8064 and MSM8x60 - rockchip: much improved support for rk3288 - shmobile: lots of updates all over the place - sunxi: dts license change - sunxi: more a23 device support - vexpress: CLCD DT description" * tag 'dt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (308 commits) ARM: DTS: meson: update DTSI to add watchdog node ARM: dts: keystone-k2l: fix mdio io start address ARM: dts: keystone-k2e: fix mdio io start address ARM: dts: keystone-k2e: update usb1 node for dma properties ARM: dts: keystone: fix io range for usb_phy0 Revert "Merge tag 'hix5hd2-dt-for-3.18' of git://github.com/hisilicon/linux-hisi into next/dt" Revert "ARM: dts: hix5hd2: add wdg node" ARM: dts: add rk3288 i2s controller ARM: vexpress: Add CLCD Device Tree properties ARM: bcm2835: add I2S pinctrl to device tree ARM: meson: documentation: add bindings documentation ARM: meson: dts: add basic Meson/Meson6/Meson6-atv1200 DTSI/DTS ARM: dts: mt6589: Change compatible string for GIC ARM: dts: mediatek: Add compatible property for aquaris5 ARM: dts: mt6589-aquaris5: Add boot argument earlyprintk ARM: dts: mt6589: Fix typo in GIC unit address ARM: dts: Build dtb for Mediatek board ARM: dts: keystone: fix bindings for pcie and usb clock nodes ARM: dts: keystone: k2l: Fix chip selects for SPI devices ARM: dts: keystone: add dsp gpio controllers nodes ...
2014-09-09ARM: mvebu: Change vendor prefix for Intersil Corporation to isilPhilipp Zabel1-1/+1
Currently there is a wild mixture of isl, isil, and intersil compatibles in the kernel. At this point, changing the vendor symbol to the most often used variant, which is equal to the NASDAQ symbol, isil, should not hurt. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lkml.kernel.org/r/1410167960-554-4-git-send-email-p.zabel@pengutronix.de Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-09-09ARM: mvebu: Netgear RN2120: Use Hardware BCH ECCArnaud Ebalard1-0/+4
The bootloader on the Netgear ReadyNAS RN2120 uses Hardware BCH ECC (strength = 4), while the pxa3xx NAND driver by default uses Hamming ECC (strength = 1). This patch changes the ECC mode on these machines to match that of the bootloader and of the stock firmware. That way, it is now possible to update the kernel from userland (e.g. using standard tools from mtd-utils package); u-boot will happily load and boot it. The issue was initially reported and fixed by Ben Pedell for RN102. The RN2120 shares the same Hynix H27U1G8F2BTR NAND flash and setup. This patch is based on Ben's fix for RN102. Fixes: ad51eddd95ad ("ARM: mvebu: Enable NAND controller in ReadyNAS 2120 .dts file") Cc: <stable@vger.kernel.org> # v3.14+ Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Link: https://lkml.kernel.org/r/61f6a1b7ad0adc57a0e201b9680bc2e5f214a317.1410035142.git.arno@natisbad.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-26ARM: mvebu: don't use clocks property in UART node for Netgear RN2120Thomas Petazzoni1-1/+0
The Netgear RN2120 was not using the same strategy as the other Armada 370/375/38x/XP boards: it was using a 'clocks' property and not the 'clock-frequency' property in its UART controller Device Tree node. However, now that this clock reference is present at the SoC-level, there is no point in duplicating it at the board-level. 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-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-20ARM: mvebu: Enable ISL12057 RTC chip in ReadyNAS 2120 .dts fileArnaud Ebalard1-0/+5
Now that support for Intersil ISL12057 RTC chip is available upstream, let's enable it in NETGEAR ReadyNAS 2120 .dts file so that the device stop believing it's the 70's. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-08ARM: mvebu: Enable NAND controller in ReadyNAS 2120 .dts fileArnaud Ebalard1-0/+36
Now that NAND controller support is available for Armada XP (cb28e2537a6f: ARM: mvebu: Add support for NAND controller in Armada 370/XP), this patch enables support for ReadyNAS 2120 and defines default partition layout as delivered by NETGEAR. As described in similar commits 2be2bc39c6f0 (ARM: mvebu: Enable NAND controller in Armada XP GP board) and d8c552dddfbf (ARM: mvebu: Enable NAND controller in Armada 370 Mirabox), "marvell,keep-config" parameter is used as current support does not allow for setting of timing parameters yet. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-02ARM: mvebu: Add Netgear ReadyNAS 2120 boardArnaud Ebalard1-0/+286
All hardware parts of the (mv78230 Armada XP based) NETGEAR ReadyNAS 2120 are supported by mainline kernel (USB 3.0 and eSATA rear ports, USB 2.0 front port, Gigabit controller and PHYs for the two rear ports, serial port, LEDs, Buttons, 88SE9170 SATA controllers, three G762 fan controllers, G751 temperature sensor) except for: - the Intersil ISL12057 I2C RTC Chip, - the Armada NAND controller. Support for both of those is currently work in progress and does not prevent boot. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Jason Cooper <jason@lakedaemon.net>