lwn.git/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts, branch docs-5.3

ARM: dts: armada-xp: fix Armada XP boards NAND description

2019-02-19T14:58:43+00:00

Commit 3b79919946cd2cf4dac47842afc9a893acec4ed7 ("ARM: dts: armada-370-xp: update NAND node with new bindings") updated some Marvell Armada DT description to use the new NAND controller bindings, but did it incorrectly for a number of boards: armada-xp-gp, armada-xp-db and armada-xp-lenovo-ix4-300d. Due to this, the NAND is no longer detected on those platforms. This commit fixes that by properly using the new NAND DT binding. This commit was runtime-tested on Armada XP GP, the two other platforms are only compile-tested. Fixes: 3b79919946cd2 ("ARM: dts: armada-370-xp: update NAND node with new bindings") Cc: Miquel Raynal Signed-off-by: Thomas Petazzoni Signed-off-by: Gregory CLEMENT

ARM: dts: armada-370-xp: update NAND node with new bindings

2018-05-18T16:36:57+00:00

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 Signed-off-by: Gregory CLEMENT

arm: dts: armada-*.dts: use SPDX-License-Identifier for most of the Armada based board

2018-03-27T13:20:34+00:00

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 Signed-off-by: Gregory CLEMENT

ARM: dts: mvebu: Correct license text

2017-01-03T16:04:05+00:00

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 Acked-by: Stefan Roese Acked-by: Uwe Kleine-König Acked-by: Rafał Miłecki Acked-by: Sebastian Hesselbarth Signed-off-by: Alexandre Belloni Signed-off-by: Gregory CLEMENT

ARM: dts: armada-370-xp: Fixup memory DT warning

2016-11-19T08:16:41+00:00

memory has a reg property so the unit name should contain an address. Signed-off-by: Gregory CLEMENT

ARM: dts: armada-xp: Fixup pcie DT warnings

2016-11-19T08:16:35+00:00

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

ARM: dts: armada-370-xp: Fixup mdio DT warning

2016-11-19T08:16:32+00:00

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

ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window

2016-03-11T19:49:55+00:00

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 Cc: Phil Sutter Cc: Signed-off-by: Thomas Petazzoni Acked-by: Gregory CLEMENT Signed-off-by: Olof Johansson

ARM: mvebu: ix4-300d: Add compatible property to "partitions" node

2016-01-25T12:16:04+00:00

As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible property to "partitions" node"), the "partitions" subnode of an SPI FLASH device node must have a compatible property. The partitions are no longer detected if it is not present. Signed-off-by: Geert Uytterhoeven Acked-by: Brian Norris Signed-off-by: Gregory CLEMENT

ARM: dt: mvebu: ix4-300d: Cleanup NAND partition ranges

2015-11-30T14:18:31+00:00

Prefix all partition reg properties to 32-bit to ease readability. While at it, also remove a stale x in front of boot partition offset and make some upper-case hex numbers lower-case. Signed-off-by: Sebastian Hesselbarth Acked-by: Andrew Lunn Signed-off-by: Gregory CLEMENT