Thomas, Whole series applied to mvebu/soc-suspend with the exception of the patch that needs to go through Russell's patch tracker. I Acked that one. thx, Jason. On Fri, Nov 21, 2014 at 04:59:57PM +0100, Thomas Petazzoni wrote: > Hello, > > This set of patches implement suspend to RAM for the Marvell Armada XP > platform, and specifically for the Armada XP GP board. For now, it > does not implement suspend/resume for all device drivers, it only > implements the core of the suspend/resume functionality: enough to > make sure that the system can enter suspend and resume from suspend, > restart all CPUs, and get back to a shell prompt. Additional work in > individual device drivers will be needed as follow-up patches. > > There are two important things to understand about the hardware before > reading this patch series: > > - The Armada XP SoC cannot put itself into a suspend to RAM state. It > requires an external circuit, which in most cases, is a PIC > micro-controller, to turn off the SoC. This PIC is connected to the > SoC using a set of GPIOs, which allow the SoC to talk to the PIC > and request certain things to be done. > > This means that the Armada XP suspend/resume logic has some > board-specific code, which is fairly uncommon for suspend/resume > code in the ARM world. > > We have chosen to represent the PIC and the fact that it's > connected to the SoC using 3 GPIOs in the Device > Tree. > > - When exiting from suspend, the SoC is actually powered up again > completely from scratch, so it goes through the bootloader. The > kernel has to fill a bootloader-specific structure at a fixed > physical address to pass information to the bootloader that will > tell the bootloader to do a resume and therefore jump back directly > into the kernel resume entry point, instead of doing a normal boot. > > - The bootloader has to reconfigure the DRAM controller, which > involves executing some DDR3 training code that has the unfortunate > side effect of overwriting the first 10 KB of each DRAM > chip-select. We therefore have to ensure that the kernel does not > use the first 10 KB of each DRAM chip select. > > So, in sequence: > > * PATCH 1 and 2 are mainly preparation patches: Device Tree binding > documentation, fixing an errata of the Armada XP. > > * PATCH 3 to 8 add suspend/resume support to some core drivers: > irqchip, clocksource, gpio, mvebu-mbus and clock. > > Note that the gpio suspend/resume patch was said to be applied by > Linus Walleij in > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/299201.html, > but I don't see it present in > https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/log/?h=for-next, > so I've kept it for now in this patch series. > > * PATCH 9 implements the core of the SoC suspend/resume logic. > > * PATCH 10 makes sure the first 10 KB of each DRAM chip select isn't > used by the kernel. > > * PATCH 11 implements the board-specific suspend/resume logic, > especially talking with the PIC micro-controller over GPIOs. > > * PATCH 12 and 13 make some other additional changes to the Armada XP > SoC support to make suspend/resume work properly. > > * PATCH 14 to 16 modify the Armada XP and Armada XP GP Device Tree > description to add the relevant hardware blocks that are needed for > suspend/resume: description of the PIC micro-controller and the 3 > GPIOs connecting it to the SoC, an additional set of the register > for mvebu-mbus, and the registers for the SDRAM controller. > > Changes since v2: > > - Add Acked-by from Daniel Lezcano on "clocksource: > time-armada-370-xp: add suspend/resume support". > > - In "clk: mvebu: add suspend/resume for gatable clocks", switch to a > global syscore_ops structure instead of a per gatable clock > controller instance. Suggested by Mike Turquette. > > Changes since v1: > > - Add Reviewed-by from Grégory Clement on > > Documentation: dt-bindings: minimal documentation for MVEBU SDRAM controller > gpio: mvebu: add suspend/resume support > bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration > > - Added Acked-by from Grégory Clement on > > ARM: mvebu: enable strex backoff delay > ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume > ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume > ARM: mvebu: synchronize secondary CPU clocks on resume > ARM: mvebu: add suspend/resume DT information for Armada XP GP > ARM: mvebu: adjust mbus controller description on Armada 370/XP > ARM: mvebu: add SDRAM controller description for Armada XP > clk: mvebu: add suspend/resume for gatable clocks > > - Add Acked-by from Alexandre Courbot on > gpio: mvebu: add suspend/resume support > > - Drop patch "irqchip: irq-armada-370-xp: use proper return value for > ->set_affinity()" as it was applied by Jason Cooper. > > - Fix typo in commit log of "clocksource: time-armada-370-xp: add > suspend/resume support", noticed by Grégory Clement. > > - Adjust the name of the new variables used in "clocksource: > time-armada-370-xp: add suspend/resume support" to save the state > of timer 0, to make it clear only the state of timer 0 is > preserved. Suggested by Grégory Clement. > > - In the suspend/resume code of the mvebu-mbus driver, make sure to > fail (and therefore abort the suspend) if the MBus bridge registers > were not mapped, instead of continuing with the suspend procedure > and later on have a system that we know cannot resume > properly. Suggested by Grégory Clement. > > - Remove cpu_pm_cluster_{enter,exit} calls from > mach-mvebu/pm.c. Suggested by Grégory Clement. > > - In patch "ARM: mvebu: Armada XP GP specific suspend/resume code", > fixup the wait loop of 100 cycles before entering suspend to > actually initialize the r1 register before entering the wait > loop. Before that, r1 was uninitialized, and a JTAG has shown that > it was generally defined to 0, so the loop started by decrementing > it by 1, making r1 equal 0xFFFFFFFF. So we had 2^32 iterations of a > two instructions loop, at 1.2 Ghz, about a 7 seconds > delay. Switching to the 100 cycles loop that is needed showed that > the previous mdelay of 250 ms was way too short: the PIC needs > several seconds before the two GPIO toggles. The Marvell vendor > kernel uses a bit more than 3 seconds delay, and experience has > shown that a 3 seconds delay works fine, while shorter delays > sometimes lead to a system that doesn't enter suspend. Noticed by > Grégory Clement. > > Best regards, > > Thomas > > Nadav Haklai (1): > ARM: mvebu: enable strex backoff delay > > Thomas Petazzoni (15): > Documentation: dt-bindings: minimal documentation for MVEBU SDRAM > controller > irqchip: irq-armada-370-xp: suspend/resume support > clocksource: time-armada-370-xp: add suspend/resume support > gpio: mvebu: add suspend/resume support > bus: mvebu-mbus: suspend/resume support > bus: mvebu-mbus: provide a mechanism to save SDRAM window > configuration > clk: mvebu: add suspend/resume for gatable clocks > ARM: mvebu: implement suspend/resume support for Armada XP > ARM: mvebu: reserve the first 10 KB of each memory bank for > suspend/resume > ARM: mvebu: Armada XP GP specific suspend/resume code > ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume > ARM: mvebu: synchronize secondary CPU clocks on resume > ARM: mvebu: add suspend/resume DT information for Armada XP GP > ARM: mvebu: adjust mbus controller description on Armada 370/XP > ARM: mvebu: add SDRAM controller description for Armada XP > > .../devicetree/bindings/bus/mvebu-mbus.txt | 17 +- > .../memory-controllers/mvebu-sdram-controller.txt | 21 ++ > arch/arm/boot/dts/armada-370-xp.dtsi | 3 +- > arch/arm/boot/dts/armada-xp-gp.dts | 19 +- > arch/arm/boot/dts/armada-xp.dtsi | 5 + > arch/arm/mach-mvebu/Makefile | 2 +- > arch/arm/mach-mvebu/board-v7.c | 51 +++++ > arch/arm/mach-mvebu/common.h | 2 + > arch/arm/mach-mvebu/platsmp.c | 31 ++- > arch/arm/mach-mvebu/pm-board.c | 141 +++++++++++++ > arch/arm/mach-mvebu/pm.c | 218 +++++++++++++++++++++ > arch/arm/mach-mvebu/pmsu.h | 1 + > arch/arm/mach-mvebu/pmsu_ll.S | 8 + > arch/arm/mm/proc-v7.S | 2 - > drivers/bus/mvebu-mbus.c | 180 ++++++++++++++++- > drivers/clk/mvebu/common.c | 32 ++- > drivers/clocksource/time-armada-370-xp.c | 25 +++ > drivers/gpio/gpio-mvebu.c | 99 ++++++++++ > drivers/irqchip/irq-armada-370-xp.c | 52 +++++ > include/linux/mbus.h | 1 + > 20 files changed, 876 insertions(+), 34 deletions(-) > create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt > create mode 100644 arch/arm/mach-mvebu/pm-board.c > create mode 100644 arch/arm/mach-mvebu/pm.c > > -- > 2.1.0 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
