summaryrefslogtreecommitdiff
path: root/arch/arm/mach-mvebu/common.h
AgeCommit message (Collapse)Author
2015-07-25ARM: mvebu: Add standby supportGregory CLEMENT
Until now only one Armada XP and one Armada 388 based board supported suspend to ram. However, most of the recent mvebu SoCs can support the standby mode. Unlike for the suspend to ram, nothing special has to be done for these SoCs. This patch allows the system to use the standby mode on Armada 370, 38x, 39x and XP SoCs. There are issues with the Armada 375, and the support might be added (if possible) in a future patch. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2014-11-30ARM: mvebu: implement suspend/resume support for Armada XPThomas Petazzoni
This commit implements the core of the platform code to enable suspend/resume on Armada XP. It registers the platform_suspend_ops structure, and implements the ->enter() hook of this structure. It is worth mentioning that this commit only provides the SoC-level part of suspend/resume, which calls into some board-specific code provided in a follow-up commit. The most important thing that this SoC-level code has to do is to build an in-memory structure that contains a magic number, the return address in the kernel after resume, and a set of address/value pairs. This structure is used by the bootloader to restore a certain number of registers (according to the set of address/value pairs) and then jump back into the kernel at the provided location. The code also puts the SDRAM into self-refresh mode, before calling into board-specific code to actually enter the suspend to RAM state. [ jac - add email exchange between Andrew Lunn and Thomas Petazzoni to better describe who consumes the address/value pairs ] > > Is this a well defined mechanism supported by mainline uboot, barebox > > etc. Or is it some Marvell extension to their uboot? > > As far as I know, it is a Marvell extension to their "binary header", > so it's done even before U-Boot starts. Since the hardware needs > assistance from the bootloader to do suspend/resume, there is > necessarily a certain amount of cooperation/agreement needed by what > the kernel does and what the bootloader expects. I'm not sure there's > any "standard" mechanism here. Do you know of any? > > I know the suspend/resume on the Blackfin architecture works the same > way (at least it used to work that way years ago when I did a bit of > Blackfin stuff). And here as well, there was some cooperation between > the kernel and the bootloader. See > arch/blackfin/mach-common/dpmc_modes.S, function do_hibernate() at the > end. > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-10-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-24ARM: mvebu: export the SCU addressGregory CLEMENT
The SCU address will be needed in other files than board-v7.c, especially in pmsu.c for cpuidle related activities. So this patch adds a function that allows to retrieve the virtual address at which the SCU has been mapped. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1406120453-29291-10-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-06-30ARM: mvebu: Use system controller to get the soc id when possibleGregory CLEMENT
On Armada 38x it is possible to get the SoC Id and the revision without using the PCI register. Accessing the PCI registers implies enabling its clock and, because of the initialization issue, not keeping them enable. So if possible it is better to avoid it. Armada 370 and Armada XP provides the SoC ID values from the system controller but not the revision. Armada 375 provides both but the SoC ID value looks buggy (0x6660 instead of 0x6720). Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1403538128-27859-1-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-06-21ARM: mvebu: implement CPU hotplug support for Armada XPThomas Petazzoni
This commit implements CPU hotplug support for the Marvell Armada XP platform. The CPU hotplug stub functions from hotplug.c are moved into platsmp.c, as it doesn't make much sense to have a separate file just for these two functions. In addition, this commit: * Implements the ->cpu_die() function of SMP operations by calling armada_370_xp_pmsu_idle_enter() to enter the deep idle state for CPUs going offline. * Implements a dummy ->cpu_kill() function, simply needed for the kernel to know we have CPU hotplug support. * The armada_xp_boot_secondary() function makes sure to wake up the CPU if waiting in deep idle state by sending an IPI. This is because armada_xp_boot_secondary() is now used in two different situations: for the initial boot of secondary CPUs (where CPU reset deassert is used to wake up CPUs) and for CPU hotplug (where an IPI is used to take CPU out of deep idle). * At boot time, we exit from the idle state in the ->smp_secondary_init() hook. This commit has been tested using CPU hotplug through sysfs (/sys/devices/system/cpu/cpuX/online) and using kexec. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1401481098-23326-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08ARM: mvebu: add function to set the resume boot address for Armada 375Gregory CLEMENT
In order to boot the secondary CPUs on Armada 375, we need to set the boot address of these CPUs, through a register part of the System Controller (this deviates from the Armada XP design, where the boot address was defined using a register part of the PMSU unit). Therefore, this commit adds a new helper function in the System Controller driver to set the secondary CPU boot address. Moreover, it moves the System Controller initialization as an early_initcall(), since arch_initcall() is too late for an SMP-related initialization. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397483648-26611-7-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483648-26611-7-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08ARM: mvebu: move Armada XP specific SMP initialization to platsmp.cThomas Petazzoni
The pmsu.c driver contained an armada_xp_boot_cpu() function that sets the boot address of a secondary CPUs and deasserts the reset. However, the Armada 375 needs a slightly different logic, so it makes more sense to move this code into the Armada XP specific platsmp.c. In order to achieve this, the mvebu_pmsu_set_cpu_boot_addr() function is exported. It will be needed for both the Armada XP and Armada 38x SMP implementations. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483648-26611-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24ARM: mvebu: introduce CPU reset codeThomas Petazzoni
The Armada 370 and Armada XP have registers that allow to reset the CPUs, which is particularly useful to take the secondary CPUs out of reset in the context of the SMP support. Unfortunately, an implementation mistake was originally made and the support for these registers was integrated into the PMSU driver, which is in fact completely unrelated. And it turns out that the Armada 375 has the same CPU reset registers, but does not have the PMSU registers. Therefore, this commit creates a small CPU reset driver. All it does is provide a simple mvebu_cpu_reset_deassert() function that the SMP support code can call to take secondary CPUs out of reset. As of this commit, the driver isn't being used, it will be used through changes in the following commits. Note that we initially planned to use the 'reset controller' framework, but it requires the addition of "resets" properties in the Device Tree, which are causing too many problems if we want to keep the Device Tree backward compatibility. Moreover, the 'reset controller' framework is mainly useful when a device driver needs to request a reset of its device from a separate reset controller. In our case, the CPU reset handling and the SMP core code are both located in arch/arm/mach-mvebu/ and are tightly linked together, so there's no real benefit in going through a separate framework. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1397483433-25836-2-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-27ARM: mvebu: move Armada 370/XP specific definitions to armada-370-xp.hThomas Petazzoni
In preparation to the introduction of the support for additional SoC, the mvebu/common.h should be clear of Armada 370/XP-specific definitions. Therefore, move the Armada 370/XP SMP specific definitions to the armada-370-xp.h file. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-27ARM: mvebu: remove prototypes of non-existing functions from common.hThomas Petazzoni
The mach-mvebu/common.h file contains prototypes of functions that have been removed, so this commit removes the corresponding prototypes. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-12-25ARM: mvebu: move ARMADA_XP_MAX_CPUS to armada-370-xp.hThomas Petazzoni
The ARMADA_XP_MAX_CPUS definition was in common.h, which as its name says, is common to all mvebu SoCs. It is more logical to have this XP specific definition in the already existing armada-370-xp.h header file, especially in preparation to the addition of the support for other SOCs in mach-mvebu. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-11-24ARM: mvebu: fix some sparse warningsJisheng Zhang
This patch fixes conflicting types for 'set_cpu_coherent' and fixes the following sparse warnings. arch/arm/mach-mvebu/system-controller.c:42:38: warning: symbol 'armada_370_xp_system_controller' was not declared. Should it be static? arch/arm/mach-mvebu/system-controller.c:49:38: warning: symbol 'orion_system_controller' was not declared. Should it be static? arch/arm/mach-mvebu/system-controller.c:67:6: warning: symbol 'mvebu_restart' was not declared. Should it be static? arch/arm/mach-mvebu/coherency.c:31:15: warning: symbol 'coherency_phys_base' was not declared. Should it be static? arch/arm/mach-mvebu/coherency.c:48:5: warning: symbol 'set_cpu_coherent' was not declared. Should it be static? arch/arm/mach-mvebu/coherency.c:123:12: warning: symbol 'coherency_init' was not declared. Should it be static? arch/arm/mach-mvebu/pmsu.c:38:5: warning: symbol 'armada_xp_boot_cpu' was not declared. Should it be static? arch/arm/mach-mvebu/pmsu.c:61:12: warning: symbol 'armada_370_xp_pmsu_init' was not declared. Should it be static? arch/arm/mach-mvebu/platsmp.c:49:13: warning: symbol 'set_secondary_cpus_clock' was not declared. Should it be static? arch/arm/mach-mvebu/platsmp.c:97:13: warning: symbol 'armada_xp_smp_prepare_cpus' was not declared. Should it be static? arch/arm/mach-mvebu/hotplug.c:24:12: warning: symbol 'armada_xp_cpu_die' was not declared. Should it be static? Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-07-09reboot: arm: change reboot_mode to use enum reboot_modeRobin Holt
Preparing to move the parsing of reboot= to generic kernel code forces the change in reboot_mode handling to use the enum. [akpm@linux-foundation.org: fix arch/arm/mach-socfpga/socfpga.c] Signed-off-by: Robin Holt <holt@sgi.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Russ Anderson <rja@sgi.com> Cc: Robin Holt <holt@sgi.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-06-13arm: mvebu: remove dependency of SMP init on static I/O mappingThomas Petazzoni
The ->smp_init_cpus() function is called very early during boot, at a point where dynamic I/O mappings are not yet possible. However, in the Armada 370/XP implementation of this function, we have to get the number of CPUs. We used to do that by accessing a hardware register, which requires relying on a static I/O mapping set up by ->map_io(). Not only this requires hardcoding a virtual address, but it also prevents us from removing the static I/O mapping. So this commit changes the way used to get the number of CPUs: we now use the Device Tree, which is a representation of the hardware, and provides us the number of available CPUs. This is also more accurate, because it potentially allows to boot the Linux kernel on only a number of CPUs given by the Device Tree, instead of unconditionally on all CPUs. As a consequence, the coherency_get_cpu_count() function becomes no longer used, so we remove it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2012-11-21arm: mvebu: Add SMP support for Armada XPGregory CLEMENT
This enables SMP support on the Armada XP processor. It adds the mandatory functions to support SMP such as: the SMP initialization functions in platsmp.c, the secondary CPU entry point in headsmp.S and the CPU hotplug initial support in hotplug.c. Signed-off-by: Yehuda Yitschak <yehuday@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Will Deacon <will.deacon@arm.com>
2012-11-21arm: mvebu: Add initial support for power managmement service unitGregory CLEMENT
The Armada 370 and Armada XP SOCs have a power management service unit which is responsible for powering down and waking up CPUs and other SOC units. This patch adds support for this unit. Signed-off-by: Yehuda Yitschak <yehuday@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2012-11-21arm: mvebu: Add support for coherency fabric in mach-mvebuGregory CLEMENT
The Armada 370 and Armada XP SOCs have a coherency fabric unit which is responsible for ensuring hardware coherency between all CPUs and between CPUs and I/O masters. This patch provides the basic support needed for SMP. Signed-off-by: Yehuda Yitschak <yehuday@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Will Deacon <will.deacon@arm.com>
2012-07-10arm: mach-mvebu: add support for Armada 370 and Armada XP with DTThomas Petazzoni
[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>
2012-07-10arm: mach-mvebu: add source filesGregory CLEMENT
[ben.dooks@codethink.co.uk: fixup style error in system-controller] [ben.dooks@codethink.co.uk: check result of of_match_node()] 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> Acked-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Yehuda Yitschak <yehuday@marvell.com> Tested-by: Lior Amsalem <alior@marvell.com> Tested-by: Andrew Lunn <andrew@lunn.ch>