- 15 Apr, 2013 19 commits
-
-
Thomas Petazzoni authored
Align the cpu node indentation with the rest of the file [gc]: added a commit description Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-
Jason Cooper authored
Pulling in mvebu branches which contain changes to armada*.dts? files for LPAE conversion. mvebu soc changes for v3.10 - use the mvebu-mbus driver - prep for LPAE support Depends: - mvebu/cleanup (tags/cleanup_for_v3.10) - mvebu/drivers (tags/drivers_for_v3.10)
-
Jason Cooper authored
pulling in mvebu branches which changes armada*.dts? files for LPAE changes mvebu fixes for v3.9 round 3 - Kirkwood - a couple of small fixes for the Iomega ix2-200 board (ether and led) - mvebu - allow GPIO button to work on Mirabox when running SMP -
Thomas Petazzoni authored
The Marvell Armada XP GP board has 3 physical full-size PCIe slots, so we enable the corresponding PCIe interfaces in the Device Tree. Signed-off-by:
-
Thomas Petazzoni authored
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 authored
The Globalscale Mirabox platform uses one PCIe interface for an available mini-PCIe slot, and the other PCIe interface for an internal USB 3.0 controller. We add the necessary Device Tree informations to enable those two interfaces. Signed-off-by:
-
Thomas Petazzoni authored
The Marvell evaluation board (DB) for the Armada XP SoC has 6 physicals full-size PCIe slots, so we enable the corresponding PCIe interfaces in the Device Tree. Signed-off-by:
-
Thomas Petazzoni authored
The PlatHome OpenBlocks AX3-4 has an internal mini-PCIe slot that can be used to plug mini-PCIe devices. We therefore enable the PCIe interface that corresponds to this slot. Signed-off-by:
-
Thomas Petazzoni authored
The Armada XP SoCs have multiple PCIe interfaces. The MV78230 has 2 PCIe units (one 4x or quad 1x, the other 1x only), the MV78260 has 3 PCIe units (two 4x or quad 1x and one 4x/1x), the MV78460 has 4 PCIe units (two 4x or quad 1x and two 4x/1x). We therefore add the necessary Device Tree informations to make those PCIe interfaces usable. Signed-off-by:
-
Thomas Petazzoni authored
The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the necessary Device Tree informations to make these interfaces availabel. Signed-off-by:
-
Lior Amsalem authored
In order to be able to support the LPAE, the internal registers virtual base must be aligned to 2MB. In LPAE section size is 2MB, in earlyprintk we map the internal registers and it must be section aligned. Signed-off-by:
Lior Amsalem <alior@marvell.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Gregory CLEMENT authored
When LPAE is activated on Armada XP, all registers and IOs are still 32bit, the 40bit extension is on the CPU to DRAM path (windows) only. That means that all the DMA transfer are restricted to the low 32 bits address space. This is limitation is achieved by selecting ZONE_DMA. Signed-off-by:
-
Thomas Petazzoni authored
Now that all Marvell EBU platforms have been converted to use the mvebu-mbus driver, we can remove the common plat-orion/addr-map.c code that isn't compiled anymore. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Thomas Petazzoni authored
This commit convers the mach-mv78xx0 sub-architecture to use the mvebu-mbus driver. We simply have to call mvebu_mbus_init() in the ->init_early() function, and modify the PCIe code so that it uses the new functions provided by mvebu-mbus to create the needed PCIe windows. Signed-off-by:
-
Thomas Petazzoni authored
This commit migrates the mach-orion5x platforms to use the mvebu-mbus driver and therefore removes the Orion5x-specific addr-map code. The dove_init_early() function now initializes the mvebu-mbus driver by calling mvebu_mbus_init(). We also convert a number of orion5x_setup_xyz_win() calls to the appropriate mvebu_mbus_add_window() calls, as each board was doing its own setup for the NOR window or other devices. Ultimately, those devices will be probed from the DT. The common address decoding windows are now registered in the orion5x_setup_wins() function. It is worth noting that the four PCIe address decoding windows will ultimately no longer have to be registered here: it will be done automatically by the PCIe driver once Dove has been migrated to use the upcoming mvebu PCIe driver. Signed-off-by:
-
Thomas Petazzoni authored
This commit migrates the mach-dove platforms to use the mvebu-mbus driver and therefore removes the Dove-specific addr-map code. The dove_init_early() function now initializes the mvebu-mbus driver by calling mvebu_mbus_init(). The address decoding windows are now registered in the dove_setup_cpu_wins() function. It is worth noting that the four PCIe address decoding windows will ultimately no longer have to be registered here: it will be done automatically by the PCIe driver once Dove has been migrated to use the upcoming mvebu PCIe driver. Signed-off-by:
-
Thomas Petazzoni authored
This commit migrates the mach-kirkwood platforms to use the mvebu-mbus driver and therefore removes the Kirkwood-specific addr-map code. The kirkwood_init_early() function is now responsible for initializing the mvebu-mbus driver by calling mvebu_mbus_init(). The address decoding windows are now registered in the kirkwood_setup_wins() function. It is worth noting that the four PCIe address decoding windows will ultimately no longer have to be registered here: it will be done automatically by the PCIe driver once Kirkwood has been migrated to use the upcoming mvebu PCIe driver. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
-
Thomas Petazzoni authored
The changes needed to migrate the mach-mvebu (Armada 370 and Armada XP) to the mvebu-mbus driver are fairly minimal, since not many devices currently supported on those SoCs use address decoding windows. The only one being the BootROM window, used to bring up secondary CPUs. However, this BootROM window needed for SMP brings an important requirement: the mvebu-mbus driver must be initialized at the ->early_init() time, otherwise the BootROM window cannot be setup early enough to be ready before the secondary CPUs are started. Signed-off-by:
-
Jason Cooper authored
mvebu drivers for v3.10 - mvebu: mbus driver for kirkwood, dove, orion5x, mv78xx, and armada 370/xp
-
- 11 Apr, 2013 6 commits
-
-
Lior Amsalem authored
In order to be able to use more than 4GB address-cells and size-cells have to be set to 2 Signed-off-by:
-
Ezequiel Garcia authored
This patch selects the devbus driver as part of the mvebu default config, along with the required options to detect and support CFI flash memories. Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by:
-
Ezequiel Garcia authored
The Plat'home Openblocks AX3 has a 128 MiB NOR flash device connected to the Device Bus. This commit adds the device tree node to support this device. The SoC supports a flexible and dynamic decoding window allocation scheme; but since this feature is still not implemented we need to specify the window base address in the device tree node itself. This base address has been selected in a completely arbitrary fashion. Signed-off-by:
-
Ezequiel Garcia authored
The Armada XP Development Board DB-MV784MP-GP has a NOR flash device connected to the Device Bus. This commit adds the device tree node to support this device. This SoC supports a flexible and dynamic decoding window allocation scheme; but since this feature is still not implemented we need to specify the window base address in the device tree node itself. This base address has been selected in a completely arbitrary fashion. Signed-off-by:
-
Ezequiel Garcia authored
Armada 370 and Armada XP SoC have a Device Bus controller to handle NOR, NAND, SRAM and FPGA devices. This patch adds the device tree node to enable the controller. Signed-off-by:
-
Thomas Petazzoni authored
The target and attributes for the PCIe address decoding windows were not correct on Kirkwood for the second PCIe interface. Signed-off-by:
-
- 10 Apr, 2013 2 commits
-
-
Gregory CLEMENT authored
This patch fix the regression introduced by the commit 3202bf01 "arm: mvebu: Improve the SMP support of the interrupt controller": GPIO IRQ were no longer delivered to the CPUs. To be delivered to a CPU an interrupt must be enabled at CPU level and at interrupt source level. Before the offending patch, all the interrupts were enabled at source level during map() function. Mask() and unmask() was done by handling the per-CPU part. It was fine when running in UP with only one CPU. The offending patch added support for SMP, in this case mask() and unmask() was done by handling the interrupt source level part. The per-CPU level part was handled by the affinity API to select the CPU which will receive the interrupt. (Due to some hardware limitation only one CPU at a time can received a given interrupt). For "normal" interrupt __setup_irq() was called when an irq was registered. irq_set_affinity() is called from this function, which enabled the interrupt on one of the CPUs. Whereas for GPIO IRQ which were chained interrupts, the irq_set_affinity() was never called and none of the CPUs was selected to receive the interrupt. With this patch all the interrupt are enable on the current CPU during map() function. Enabling the interrupts on a CPU doesn't depend anymore on irq_set_affinity() and then the chained irq are not anymore a special case. However the CPU which will receive the irq can still be modify later using irq_set_affinity(). Tested with Mirabox (A370) and Openblocks AX3 (AXP), rootfs mounted over NFS, compiled with CONFIG_SMP=y/N. Signed-off-by:
Ryan Press <ryan@presslab.us> Investigated-by:
-
Nigel Roberts authored
Signed-off-by:
-
- 03 Apr, 2013 3 commits
-
-
Ezequiel Garcia authored
The thermal management driver for Armada XP/370 has been added so we update the defconfig to reflect this. Signed-off-by:
-
Ezequiel Garcia authored
This patch adds support for the thermal controller available in all Armada 370 boards. This controller has two 4-byte registers: one to read the thermal sensor, the other for sensor initialization. Signed-off-by:
-
Ezequiel Garcia authored
This patch adds support for the thermal controller available in all Armada XP boards. This controller has two 4-byte registers: one to read the thermal sensor, the other for sensor initialization. Signed-off-by:
-
- 01 Apr, 2013 1 commit
-
-
Nigel Roberts authored
In the conversion to pinctrl, an error in the pins for the rebuild LED was introduced. This patch assigns the correct pins and includes the correct name for the LED in kirkwood-iomega_ix2_200.dts. Signed-off-by:
Nigel Roberts <nigel@nobiscuit.com> Cc: <stable@vger.kernel.org> # v3.8.x Signed-off-by:
-
- 31 Mar, 2013 3 commits
-
-
Ryan Press authored
Add the three external LED definitions to the device tree file on the Mirabox. The Mirabox user guide calls out one as a power LED, and the other two are defined for WiFi, but as the current mwifiex drivers don't have LED support, we make them status LEDs. These have been tested working by writing to the appropriate /sys/class/leds trigger. Signed-off-by:
Neil Greatorex <neil@fatboyfat.co.uk> Tested-by:
-
Alexander Clouter authored
The orion5x SoC includes DMA functionality, so lets enable that and turn it on by default. Signed-off-by:
Alexander Clouter <alex@digriz.org.uk> Signed-off-by:
-
Alexander Clouter authored
The orion5x SoC also includes a USB EHCI componment so lets add that to the dtsi (disable by default incase the pins are not broken out). Signed-off-by:
-
- 30 Mar, 2013 5 commits
-
-
Jason Cooper authored
mvebu cleanup for v3.10 - plat-orion: prep for mvebu-mbus driver
-
Neil Greatorex authored
The new mvebu-mbus driver was not checking the device tree for coherency fabric hardware and hence was not setting the hw_io_coherency flag in mbus_state. This prevented the mvsdio driver from operating correctly. This patch restores the check. Signed-off-by:
-
Simon Guinot authored
This patch adds a dedicated dbg_show function to the gpio-mvebu driver. In addition to the generic gpiolib informations, this function displays informations related with the specific Marvell registers (blink enable, data in polarity, interrupt masks and cause). Signed-off-by:
Simon Guinot <simon.guinot@sequanux.org> Signed-off-by:
-
Sebastian Hesselbarth authored
Device tree based guruplug boards still use mvsdio platform_data and kirkwood_sdio_init to enable sdio. DT support for sdio is already there, so make use of it. This also fixes mvsdio accidentially breaking nand by configuring mpp0 to gpio, while used also by nand (nand_io2 on mpp0). Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by:
Soeren Moch <smoch@web.de> Acked-by:
-
Ezequiel Garcia authored
The Marvell Armada 370 Reference Design board has a software-controlled button on the front side, marked as "SW". This patch adds minimal support for this button. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
- 28 Mar, 2013 1 commit
-
-
Thomas Petazzoni authored
The Marvell EBU SoCs have a configurable physical address space layout: the physical ranges of memory used to address PCI(e) interfaces, NOR flashes, SRAM and various other types of memory are configurable by software, through a mechanism of so-called 'address decoding windows'. This new driver mvebu-mbus consolidates the existing code to address the configuration of these memory ranges, which is spread into mach-mvebu, mach-orion5x, mach-mv78xx0, mach-dove and mach-kirkwood. Following patches convert each Marvell EBU SoC family to use this driver, therefore removing the old code that was configuring the address decoding windows. It is worth mentioning that the MVEBU_MBUS Kconfig option is intentionally added as a blind option. The new driver implements and exports the mv_mbus_dram_info() function, which is used by various Marvell drivers throughout the tree to get access to window configuration parameters that they require. This function is also implemented in arch/arm/plat-orion/addr-map.c, which ultimately gets removed at the end of this patch series. So, in order to preserve bisectability, we want to ensure that *either* this new driver, *or* the legacy code in plat-orion/addr-map.c gets compiled in. By making MVEBU_MBUS a blind option, we are sure that only a platform that does 'select MVEBU_MBUS' will get this new driver compiled in. Therefore, throughout the next patches that convert the Marvell sub-architectures one after the other to this new driver, we add the 'select MVEBU_MBUS' and also ensure to remove plat-orion/addr-map.c from the build for this specific sub-architecture. This ensures that bisectability is preserved. Ealier versions of this driver had a DT binding, but since those were not yet agreed upon, they were removed. The driver still uses of_device_id to find the SoC specific details according to the string passed to mvebu_mbus_init(). The plan is to re-introduce a proper DT binding as a followup set of patches. Signed-off-by:
-
