summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
AgeCommit message (Collapse)Author
2023-06-21ARM: dts: Move .dts files to vendor sub-directoriesRob Herring
The arm dts directory has grown to 1559 boards which makes it a bit unwieldy to maintain and use. Past attempts stalled out due to plans to move .dts files out of the kernel tree. Doing that is no longer planned (any time soon at least), so let's go ahead and group .dts files by vendors. This move aligns arm with arm64 .dts file structure. There's no change to dtbs_install as the flat structure is maintained on install. The naming of vendor directories is roughly in this order of preference: - Matching original and current SoC vendor prefix/name (e.g. ti, qcom) - Current vendor prefix/name if still actively sold (SoCs which have been aquired) (e.g. nxp/imx) - Existing platform name for older platforms not sold/maintained by any company (e.g. gemini, nspire) The whole move was scripted with the exception of MAINTAINERS and a few makefile fixups. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Michal Simek <michal.simek@amd.com> #Xilinx Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Paul Barker <paul.barker@sancloud.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Wei Xu <xuwei5@hisilicon.com> #hisilicon Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Nick Hawkins <nick.hawkins@hpe.com> Acked-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Peter Rosin <peda@axentia.se> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> #broadcom Acked-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Patrice Chotard <patrice.chotard@foss.st.com> Acked-by: Romain Perier <romain.perier@gmail.com> Acked-by: Alexandre TORGUE <alexandre.torgue@st.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org>
2023-04-07ARM: dts: armada: Add missing phy-mode and fixed linksAndrew Lunn
The DSA framework has got more picky about always having a phy-mode for the CPU port. The Armada Ethernet supports RGMII, SGMII, 1000base-x and 2500Base-X. Set the switch phy-mode based on how the SoC Ethernet ports is been configured. For RGMII mode, have the switch add the delays. Additionally, the cpu label has never actually been used in the binding, so remove it. Lastly, add a fixed-link node indicating the expected speed/duplex of the link to the SoC. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-11-28ARM: dts: armada: align LED node names with dtschemaKrzysztof Kozlowski
The node names should be generic and DT schema expects certain pattern: armada-370-seagate-personal-cloud.dtb: gpio-leds: 'red-sata0' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2022-06-27ARM: dts: marvell: correct gpio-keys propertiesKrzysztof Kozlowski
gpio-keys children do not use unit addresses. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220616005333.18491-14-krzysztof.kozlowski@linaro.org
2022-06-27ARM: dts: marvell: align gpio-key node names with dtschemaKrzysztof Kozlowski
The node names should be generic and DT schema expects certain pattern (e.g. with key/button/switch). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220616005333.18491-13-krzysztof.kozlowski@linaro.org
2022-04-20ARM: dts: marvell: align SPI NOR node name with dtschemaKrzysztof Kozlowski
The node names should be generic and SPI NOR dtschema expects "flash". Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220407143234.295426-1-krzysztof.kozlowski@linaro.org
2019-02-08arch: arm: dts: Remove disabled marvell,dsa propertiesAndrew Lunn
These have been disable since the change to probe Marvell Ethernet switches as MDIO devices. Remove the properties now that the code to suppport them will also be removed soon. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-05-18ARM: dts: armada-370-xp: update NAND node with new bindingsMiquel Raynal
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 CLEMENT
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>
2017-06-17ARM: dts: armada-xp: Use pwm-fan rather than gpio-fanAndrew Lunn
The mvebu GPIO driver can also perform PWM on some pins. Use the pwm-fan driver to control the fan of the WRT1900AC, giving us finer grained control over its speed and hence noise. Signed-off-by: Andrew Lunn <andrew@lunn.ch> URL: https://patchwork.ozlabs.org/patch/427291/ [Ralph Sennhauser: drop flags paramter from pwms, no longer used] Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-03-23ARM: dts: mvebu: linksys: enable buffer manager supportRalph Sennhauser
Add appropriate properties to devices in the Linksys WRT AC Series for the mvneta driver to use hardware buffer management. Also update "soc" ranges property and set the status of bm and bm-bppi to "okay" (SRAM). Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-03-08ARM: dts: armada: Add default trigger for sata ledAnsuel Smith
In others board we have the sata led set to function with the sata led trigger by default. This patch makes the same for these board that have sata led but get disabled by not associating it to any trigger. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2017-01-19ARM: dts: armada-xp-linksys-mamba: Utilize new DSA bindingFlorian Fainelli
Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa: Document new binding"). The legacy binding node is kept included, but is marked disabled. Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-11-19ARM: dts: armada-370-xp: Remove button address and fixup namesGregory CLEMENT
The gpio-key nodes do not have a reg property, so remove the address from the unit name. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-11-19ARM: dts: armada-370-xp: Remove address from dsa unit nameGregory CLEMENT
The dsa node does not have a reg property, so remove the address from the unit name. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-11-19ARM: dts: armada-370-xp: Fixup memory DT warningGregory CLEMENT
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 CLEMENT
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-08-08ARM: dts: mvebu: A37x/XP/38x/39x: Move SPI controller nodes into 'soc' nodeStefan Roese
This patch moves all Armada 370/XP/38x/39x SPI controller nodes from the 'internal-regs' node down into the 'soc' node. This is in preparation to enable the usage of the SPI direct access mode. A follow-up patch will add the static MBus mappings for the SPI devices into the 'reg' property of the SPI controller DT node. By moving these SPI controller nodes, this patch also makes use of the labels rather than keeping the tree structure. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-03-30ARM: mvebu: fix GPIO config on the Linksys boardsImre Kaloz
Some of the GPIO configs were wrong in the submitted DTS files, this patch fixes all affected boards. Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Cc: <stable@vger.kernel.org> # v4.1 + Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-03-11ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory windowThomas Petazzoni
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-09-29ARM: mvebu: define crypto SRAM ranges for all armada-xp boardsBoris Brezillon
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-28ARM: mvebu: armada-xp-linksys-mamba: Disable internal RTCImre Kaloz
The Mamba (like the OpenBlocks AX3) doesn't have a crystal connected to the internal RTC - let's prevent the kernel from probing it. Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Cc: <stable@vger.kernel.org> # v4.0 + Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-03-04ARM: ARMADA XP: WRT1900AC: Add support for the Ethernet switchAndrew Lunn
Add a DSA section to the DT blob representing the Ethernet switch. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-02-26ARM: mvebu: add Linksys WRT1900AC (Mamba) supportImre Kaloz
The Linksys WRT1900AC (Mamba) is a router that has - 2 mini-PCIe slots with Marvell 88W8864 radios - 1 USB 3.0 port - 1 USB 2.0/eSATAp port - 2 Ethernet interfaces connected to a 88E6172 switch (1x WAN + 4x LAN) - 128MB NAND flash - 256MB RAM gregory.clement@free-electrons.com: - add ARM to the title - fix the reference to CONFIG_DEBUG_MVEBU_UART0_ALTERNATE - fix the unbalanced comment for the syscfg partition Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>