2012-06-01 20:21:46 +04:00
|
|
|
/*
|
|
|
|
|
* Core functions for Marvell System On Chip
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2012 Marvell
|
|
|
|
|
*
|
|
|
|
|
* Lior Amsalem <alior@marvell.com>
|
|
|
|
|
* Gregory CLEMENT <gregory.clement@free-electrons.com>
|
|
|
|
|
* Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
|
*
|
|
|
|
|
* This file is licensed under the terms of the GNU General Public
|
|
|
|
|
* License version 2. This program is licensed "as is" without any
|
|
|
|
|
* warranty of any kind, whether express or implied.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __ARCH_MVEBU_COMMON_H
|
|
|
|
|
#define __ARCH_MVEBU_COMMON_H
|
|
|
|
|
|
2013-07-09 03:01:40 +04:00
|
|
|
#include <linux/reboot.h>
|
|
|
|
|
|
|
|
|
|
void mvebu_restart(enum reboot_mode mode, const char *cmd);
|
ARM: mvebu: introduce CPU reset code
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>
2014-04-14 17:50:28 +04:00
|
|
|
int mvebu_cpu_reset_deassert(int cpu);
|
2014-04-14 17:53:58 +04:00
|
|
|
void mvebu_pmsu_set_cpu_boot_addr(int hw_cpu, void *boot_addr);
|
2014-04-14 17:54:03 +04:00
|
|
|
void mvebu_system_controller_set_cpu_boot_addr(void *boot_addr);
|
2014-06-23 19:42:08 +04:00
|
|
|
int mvebu_system_controller_get_soc_id(u32 *dev, u32 *rev);
|
2012-06-01 20:21:46 +04:00
|
|
|
|
2014-07-23 17:00:46 +04:00
|
|
|
void __iomem *mvebu_get_scu_base(void);
|
|
|
|
|
|
ARM: mvebu: implement suspend/resume support for Armada XP
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-11-21 19:00:06 +03:00
|
|
|
int mvebu_pm_init(void (*board_pm_enter)(void __iomem *sdram_reg, u32 srcmd));
|
|
|
|
|
|
2012-06-01 20:21:46 +04:00
|
|
|
#endif
|
