* [PATCHv3 00/16] Suspend to RAM support for Armada XP
@ 2014-11-21 15:59 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 15:59 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 00/16] Suspend to RAM support for Armada XP
@ 2014-11-21 15:59 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 01/16] Documentation: dt-bindings: minimal documentation for MVEBU SDRAM controller
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 15:59 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 15:59 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni, Kumar Gala,
Ian Campbell, Mark Rutland, Rob Herring
The suspend/resume code for Armada XP has to modify certain registers
of the SDRAM controller. Therefore, we need to define a Device Tree
binding for this hardware block.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
.../memory-controllers/mvebu-sdram-controller.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
new file mode 100644
index 0000000..89657d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
@@ -0,0 +1,21 @@
+Device Tree bindings for MVEBU SDRAM controllers
+
+The Marvell EBU SoCs all have a SDRAM controller. The SDRAM controller
+differs from one SoC variant to another, but they also share a number
+of commonalities.
+
+For now, this Device Tree binding documentation only documents the
+Armada XP SDRAM controller.
+
+Required properties:
+
+ - compatible: for Armada XP, "marvell,armada-xp-sdram-controller"
+ - reg: a resource specifier for the register space, which should
+ include all SDRAM controller registers as per the datasheet.
+
+Example:
+
+sdramc@1400 {
+ compatible = "marvell,armada-xp-sdram-controller";
+ reg = <0x1400 0x500>;
+};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 01/16] Documentation: dt-bindings: minimal documentation for MVEBU SDRAM controller
@ 2014-11-21 15:59 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
The suspend/resume code for Armada XP has to modify certain registers
of the SDRAM controller. Therefore, we need to define a Device Tree
binding for this hardware block.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree at vger.kernel.org
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../memory-controllers/mvebu-sdram-controller.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
new file mode 100644
index 0000000..89657d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
@@ -0,0 +1,21 @@
+Device Tree bindings for MVEBU SDRAM controllers
+
+The Marvell EBU SoCs all have a SDRAM controller. The SDRAM controller
+differs from one SoC variant to another, but they also share a number
+of commonalities.
+
+For now, this Device Tree binding documentation only documents the
+Armada XP SDRAM controller.
+
+Required properties:
+
+ - compatible: for Armada XP, "marvell,armada-xp-sdram-controller"
+ - reg: a resource specifier for the register space, which should
+ include all SDRAM controller registers as per the datasheet.
+
+Example:
+
+sdramc at 1400 {
+ compatible = "marvell,armada-xp-sdram-controller";
+ reg = <0x1400 0x500>;
+};
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 15:59 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 15:59 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Russell King, stable,
Thomas Petazzoni
From: Nadav Haklai <nadavh@marvell.com>
Under extremely rare conditions, in an MPCore node consisting of at
least 3 CPUs, two CPUs trying to perform a STREX to data on the same
shared cache line can enter a livelock situation.
This patch enables the HW mechanism that overcomes the bug. This fixes
the incorrect setup of the STREX backoff delay bit due to a wrong
description in the specification.
Note that enabling the STREX backoff delay mechanism is done by
leaving the bit *cleared*, while the bit was currently being set by
the proc-v7.S code.
[Thomas: adapt to latest mainline, slightly reword the commit log, add
stable markers.]
Cc: Russell King <linux@arm.linux.org.uk>
Cc: <stable@vger.kernel.org> # v3.8+
Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
This patch is submitted as part of the suspend/resume work, because
the suspend/resume path is triggering this rare bug in a very
reproducible fashion.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mm/proc-v7.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index b3a9478..22ac2a6 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -270,7 +270,6 @@ __v7_pj4b_setup:
/* Auxiliary Debug Modes Control 1 Register */
#define PJ4B_STATIC_BP (1 << 2) /* Enable Static BP */
#define PJ4B_INTER_PARITY (1 << 8) /* Disable Internal Parity Handling */
-#define PJ4B_BCK_OFF_STREX (1 << 5) /* Enable the back off of STREX instr */
#define PJ4B_CLEAN_LINE (1 << 16) /* Disable data transfer for clean line */
/* Auxiliary Debug Modes Control 2 Register */
@@ -293,7 +292,6 @@ __v7_pj4b_setup:
/* Auxiliary Debug Modes Control 1 Register */
mrc p15, 1, r0, c15, c1, 1
orr r0, r0, #PJ4B_CLEAN_LINE
- orr r0, r0, #PJ4B_BCK_OFF_STREX
orr r0, r0, #PJ4B_INTER_PARITY
bic r0, r0, #PJ4B_STATIC_BP
mcr p15, 1, r0, c15, c1, 1
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay
@ 2014-11-21 15:59 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Nadav Haklai <nadavh@marvell.com>
Under extremely rare conditions, in an MPCore node consisting of at
least 3 CPUs, two CPUs trying to perform a STREX to data on the same
shared cache line can enter a livelock situation.
This patch enables the HW mechanism that overcomes the bug. This fixes
the incorrect setup of the STREX backoff delay bit due to a wrong
description in the specification.
Note that enabling the STREX backoff delay mechanism is done by
leaving the bit *cleared*, while the bit was currently being set by
the proc-v7.S code.
[Thomas: adapt to latest mainline, slightly reword the commit log, add
stable markers.]
Cc: Russell King <linux@arm.linux.org.uk>
Cc: <stable@vger.kernel.org> # v3.8+
Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
This patch is submitted as part of the suspend/resume work, because
the suspend/resume path is triggering this rare bug in a very
reproducible fashion.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mm/proc-v7.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index b3a9478..22ac2a6 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -270,7 +270,6 @@ __v7_pj4b_setup:
/* Auxiliary Debug Modes Control 1 Register */
#define PJ4B_STATIC_BP (1 << 2) /* Enable Static BP */
#define PJ4B_INTER_PARITY (1 << 8) /* Disable Internal Parity Handling */
-#define PJ4B_BCK_OFF_STREX (1 << 5) /* Enable the back off of STREX instr */
#define PJ4B_CLEAN_LINE (1 << 16) /* Disable data transfer for clean line */
/* Auxiliary Debug Modes Control 2 Register */
@@ -293,7 +292,6 @@ __v7_pj4b_setup:
/* Auxiliary Debug Modes Control 1 Register */
mrc p15, 1, r0, c15, c1, 1
orr r0, r0, #PJ4B_CLEAN_LINE
- orr r0, r0, #PJ4B_BCK_OFF_STREX
orr r0, r0, #PJ4B_INTER_PARITY
bic r0, r0, #PJ4B_STATIC_BP
mcr p15, 1, r0, c15, c1, 1
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 03/16] irqchip: irq-armada-370-xp: suspend/resume support
[not found] ` <1416585613-2113-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
` (9 subsequent siblings)
11 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Thomas Petazzoni, Thomas Gleixner,
linux-kernel
This commit adds suspend/resume support to the irqchip driver used on
Armada XP platforms (amongst others). It does so by adding a set of
suspend/resume syscore_ops, that will respectively save and restore
the necessary registers to ensure interrupts continue to work after
resume.
It is worth mentioning that the affinity is lost during a
suspend/resume cycle, because when a secondary CPU is brought
off-line, all interrupts that are assigned to this CPU in terms of
affinity gets re-assigned to a still running CPU. Therefore, right
before entering suspend, all interrupts are assigned to the boot CPU.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: linux-kernel@vger.kernel.org
---
drivers/irqchip/irq-armada-370-xp.c | 52 +++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 3e238cd..4ec137b 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -26,6 +26,7 @@
#include <linux/of_pci.h>
#include <linux/irqdomain.h>
#include <linux/slab.h>
+#include <linux/syscore_ops.h>
#include <linux/msi.h>
#include <asm/mach/arch.h>
#include <asm/exception.h>
@@ -66,6 +67,7 @@
static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
static struct irq_domain *armada_370_xp_mpic_domain;
+static u32 doorbell_mask_reg;
#ifdef CONFIG_PCI_MSI
static struct irq_domain *armada_370_xp_msi_domain;
static DECLARE_BITMAP(msi_used, PCI_MSI_DOORBELL_NR);
@@ -474,6 +476,54 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
} while (1);
}
+static int armada_370_xp_mpic_suspend(void)
+{
+ doorbell_mask_reg = readl(per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+ return 0;
+}
+
+static void armada_370_xp_mpic_resume(void)
+{
+ int nirqs;
+ irq_hw_number_t irq;
+
+ /* Re-enable interrupts */
+ nirqs = (readl(main_int_base + ARMADA_370_XP_INT_CONTROL) >> 2) & 0x3ff;
+ for (irq = 0; irq < nirqs; irq++) {
+ struct irq_data *data;
+ int virq;
+
+ virq = irq_linear_revmap(armada_370_xp_mpic_domain, irq);
+ if (virq == 0)
+ continue;
+
+ if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
+ writel(irq, per_cpu_int_base +
+ ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+ else
+ writel(irq, main_int_base +
+ ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+
+ data = irq_get_irq_data(virq);
+ if (!irqd_irq_disabled(data))
+ armada_370_xp_irq_unmask(data);
+ }
+
+ /* Reconfigure doorbells for IPIs and MSIs */
+ writel(doorbell_mask_reg,
+ per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+ if (doorbell_mask_reg & IPI_DOORBELL_MASK)
+ writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+ if (doorbell_mask_reg & PCI_MSI_DOORBELL_MASK)
+ writel(1, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+
+struct syscore_ops armada_370_xp_mpic_syscore_ops = {
+ .suspend = armada_370_xp_mpic_suspend,
+ .resume = armada_370_xp_mpic_resume,
+};
+
static int __init armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent)
{
@@ -530,6 +580,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
armada_370_xp_mpic_handle_cascade_irq);
}
+ register_syscore_ops(&armada_370_xp_mpic_syscore_ops);
+
return 0;
}
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 03/16] irqchip: irq-armada-370-xp: suspend/resume support
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
Thomas Gleixner, linux-kernel-u79uwXL29TY76Z2rM5mHXA
This commit adds suspend/resume support to the irqchip driver used on
Armada XP platforms (amongst others). It does so by adding a set of
suspend/resume syscore_ops, that will respectively save and restore
the necessary registers to ensure interrupts continue to work after
resume.
It is worth mentioning that the affinity is lost during a
suspend/resume cycle, because when a secondary CPU is brought
off-line, all interrupts that are assigned to this CPU in terms of
affinity gets re-assigned to a still running CPU. Therefore, right
before entering suspend, all interrupts are assigned to the boot CPU.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/irqchip/irq-armada-370-xp.c | 52 +++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 3e238cd..4ec137b 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -26,6 +26,7 @@
#include <linux/of_pci.h>
#include <linux/irqdomain.h>
#include <linux/slab.h>
+#include <linux/syscore_ops.h>
#include <linux/msi.h>
#include <asm/mach/arch.h>
#include <asm/exception.h>
@@ -66,6 +67,7 @@
static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
static struct irq_domain *armada_370_xp_mpic_domain;
+static u32 doorbell_mask_reg;
#ifdef CONFIG_PCI_MSI
static struct irq_domain *armada_370_xp_msi_domain;
static DECLARE_BITMAP(msi_used, PCI_MSI_DOORBELL_NR);
@@ -474,6 +476,54 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
} while (1);
}
+static int armada_370_xp_mpic_suspend(void)
+{
+ doorbell_mask_reg = readl(per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+ return 0;
+}
+
+static void armada_370_xp_mpic_resume(void)
+{
+ int nirqs;
+ irq_hw_number_t irq;
+
+ /* Re-enable interrupts */
+ nirqs = (readl(main_int_base + ARMADA_370_XP_INT_CONTROL) >> 2) & 0x3ff;
+ for (irq = 0; irq < nirqs; irq++) {
+ struct irq_data *data;
+ int virq;
+
+ virq = irq_linear_revmap(armada_370_xp_mpic_domain, irq);
+ if (virq == 0)
+ continue;
+
+ if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
+ writel(irq, per_cpu_int_base +
+ ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+ else
+ writel(irq, main_int_base +
+ ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+
+ data = irq_get_irq_data(virq);
+ if (!irqd_irq_disabled(data))
+ armada_370_xp_irq_unmask(data);
+ }
+
+ /* Reconfigure doorbells for IPIs and MSIs */
+ writel(doorbell_mask_reg,
+ per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+ if (doorbell_mask_reg & IPI_DOORBELL_MASK)
+ writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+ if (doorbell_mask_reg & PCI_MSI_DOORBELL_MASK)
+ writel(1, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+
+struct syscore_ops armada_370_xp_mpic_syscore_ops = {
+ .suspend = armada_370_xp_mpic_suspend,
+ .resume = armada_370_xp_mpic_resume,
+};
+
static int __init armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent)
{
@@ -530,6 +580,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
armada_370_xp_mpic_handle_cascade_irq);
}
+ register_syscore_ops(&armada_370_xp_mpic_syscore_ops);
+
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 03/16] irqchip: irq-armada-370-xp: suspend/resume support
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds suspend/resume support to the irqchip driver used on
Armada XP platforms (amongst others). It does so by adding a set of
suspend/resume syscore_ops, that will respectively save and restore
the necessary registers to ensure interrupts continue to work after
resume.
It is worth mentioning that the affinity is lost during a
suspend/resume cycle, because when a secondary CPU is brought
off-line, all interrupts that are assigned to this CPU in terms of
affinity gets re-assigned to a still running CPU. Therefore, right
before entering suspend, all interrupts are assigned to the boot CPU.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: linux-kernel at vger.kernel.org
---
drivers/irqchip/irq-armada-370-xp.c | 52 +++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 3e238cd..4ec137b 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -26,6 +26,7 @@
#include <linux/of_pci.h>
#include <linux/irqdomain.h>
#include <linux/slab.h>
+#include <linux/syscore_ops.h>
#include <linux/msi.h>
#include <asm/mach/arch.h>
#include <asm/exception.h>
@@ -66,6 +67,7 @@
static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
static struct irq_domain *armada_370_xp_mpic_domain;
+static u32 doorbell_mask_reg;
#ifdef CONFIG_PCI_MSI
static struct irq_domain *armada_370_xp_msi_domain;
static DECLARE_BITMAP(msi_used, PCI_MSI_DOORBELL_NR);
@@ -474,6 +476,54 @@ armada_370_xp_handle_irq(struct pt_regs *regs)
} while (1);
}
+static int armada_370_xp_mpic_suspend(void)
+{
+ doorbell_mask_reg = readl(per_cpu_int_base +
+ ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+ return 0;
+}
+
+static void armada_370_xp_mpic_resume(void)
+{
+ int nirqs;
+ irq_hw_number_t irq;
+
+ /* Re-enable interrupts */
+ nirqs = (readl(main_int_base + ARMADA_370_XP_INT_CONTROL) >> 2) & 0x3ff;
+ for (irq = 0; irq < nirqs; irq++) {
+ struct irq_data *data;
+ int virq;
+
+ virq = irq_linear_revmap(armada_370_xp_mpic_domain, irq);
+ if (virq == 0)
+ continue;
+
+ if (irq != ARMADA_370_XP_TIMER0_PER_CPU_IRQ)
+ writel(irq, per_cpu_int_base +
+ ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+ else
+ writel(irq, main_int_base +
+ ARMADA_370_XP_INT_SET_ENABLE_OFFS);
+
+ data = irq_get_irq_data(virq);
+ if (!irqd_irq_disabled(data))
+ armada_370_xp_irq_unmask(data);
+ }
+
+ /* Reconfigure doorbells for IPIs and MSIs */
+ writel(doorbell_mask_reg,
+ per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS);
+ if (doorbell_mask_reg & IPI_DOORBELL_MASK)
+ writel(0, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+ if (doorbell_mask_reg & PCI_MSI_DOORBELL_MASK)
+ writel(1, per_cpu_int_base + ARMADA_370_XP_INT_CLEAR_MASK_OFFS);
+}
+
+struct syscore_ops armada_370_xp_mpic_syscore_ops = {
+ .suspend = armada_370_xp_mpic_suspend,
+ .resume = armada_370_xp_mpic_resume,
+};
+
static int __init armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent)
{
@@ -530,6 +580,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
armada_370_xp_mpic_handle_cascade_irq);
}
+ register_syscore_ops(&armada_370_xp_mpic_syscore_ops);
+
return 0;
}
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 04/16] clocksource: time-armada-370-xp: add suspend/resume support
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Thomas Petazzoni, Daniel Lezcano,
Thomas Gleixner, linux-kernel
This commit adds a set of suspend/resume syscore_ops to respectively
save and restore a number of timer registers, in order to make sure
the clockevent and clocksource devices continue to work properly
across a suspend/resume cycle.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
drivers/clocksource/time-armada-370-xp.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 0451e62..ff37d3a 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -43,6 +43,7 @@
#include <linux/module.h>
#include <linux/sched_clock.h>
#include <linux/percpu.h>
+#include <linux/syscore_ops.h>
/*
* Timer block registers.
@@ -223,6 +224,28 @@ static struct notifier_block armada_370_xp_timer_cpu_nb = {
.notifier_call = armada_370_xp_timer_cpu_notify,
};
+static u32 timer0_ctrl_reg, timer0_local_ctrl_reg;
+
+static int armada_370_xp_timer_suspend(void)
+{
+ timer0_ctrl_reg = readl(timer_base + TIMER_CTRL_OFF);
+ timer0_local_ctrl_reg = readl(local_base + TIMER_CTRL_OFF);
+ return 0;
+}
+
+static void armada_370_xp_timer_resume(void)
+{
+ writel(0xffffffff, timer_base + TIMER0_VAL_OFF);
+ writel(0xffffffff, timer_base + TIMER0_RELOAD_OFF);
+ writel(timer0_ctrl_reg, timer_base + TIMER_CTRL_OFF);
+ writel(timer0_local_ctrl_reg, local_base + TIMER_CTRL_OFF);
+}
+
+struct syscore_ops armada_370_xp_timer_syscore_ops = {
+ .suspend = armada_370_xp_timer_suspend,
+ .resume = armada_370_xp_timer_resume,
+};
+
static void __init armada_370_xp_timer_common_init(struct device_node *np)
{
u32 clr = 0, set = 0;
@@ -285,6 +308,8 @@ static void __init armada_370_xp_timer_common_init(struct device_node *np)
/* Immediately configure the timer on the boot CPU */
if (!res)
armada_370_xp_timer_setup(this_cpu_ptr(armada_370_xp_evt));
+
+ register_syscore_ops(&armada_370_xp_timer_syscore_ops);
}
static void __init armada_xp_timer_init(struct device_node *np)
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 04/16] clocksource: time-armada-370-xp: add suspend/resume support
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds a set of suspend/resume syscore_ops to respectively
save and restore a number of timer registers, in order to make sure
the clockevent and clocksource devices continue to work properly
across a suspend/resume cycle.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel at vger.kernel.org
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
drivers/clocksource/time-armada-370-xp.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 0451e62..ff37d3a 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -43,6 +43,7 @@
#include <linux/module.h>
#include <linux/sched_clock.h>
#include <linux/percpu.h>
+#include <linux/syscore_ops.h>
/*
* Timer block registers.
@@ -223,6 +224,28 @@ static struct notifier_block armada_370_xp_timer_cpu_nb = {
.notifier_call = armada_370_xp_timer_cpu_notify,
};
+static u32 timer0_ctrl_reg, timer0_local_ctrl_reg;
+
+static int armada_370_xp_timer_suspend(void)
+{
+ timer0_ctrl_reg = readl(timer_base + TIMER_CTRL_OFF);
+ timer0_local_ctrl_reg = readl(local_base + TIMER_CTRL_OFF);
+ return 0;
+}
+
+static void armada_370_xp_timer_resume(void)
+{
+ writel(0xffffffff, timer_base + TIMER0_VAL_OFF);
+ writel(0xffffffff, timer_base + TIMER0_RELOAD_OFF);
+ writel(timer0_ctrl_reg, timer_base + TIMER_CTRL_OFF);
+ writel(timer0_local_ctrl_reg, local_base + TIMER_CTRL_OFF);
+}
+
+struct syscore_ops armada_370_xp_timer_syscore_ops = {
+ .suspend = armada_370_xp_timer_suspend,
+ .resume = armada_370_xp_timer_resume,
+};
+
static void __init armada_370_xp_timer_common_init(struct device_node *np)
{
u32 clr = 0, set = 0;
@@ -285,6 +308,8 @@ static void __init armada_370_xp_timer_common_init(struct device_node *np)
/* Immediately configure the timer on the boot CPU */
if (!res)
armada_370_xp_timer_setup(this_cpu_ptr(armada_370_xp_evt));
+
+ register_syscore_ops(&armada_370_xp_timer_syscore_ops);
}
static void __init armada_xp_timer_init(struct device_node *np)
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 05/16] gpio: mvebu: add suspend/resume support
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Thomas Petazzoni, Linus Walleij,
Alexandre Courbot, linux-gpio
This commit adds the implementation of ->suspend() and ->resume()
platform_driver hooks in order to save and restore the state of the
GPIO configuration. In order to achieve that, additional fields are
added to the mvebu_gpio_chip structure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 418e386..dd5545c 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -83,6 +83,14 @@ struct mvebu_gpio_chip {
int irqbase;
struct irq_domain *domain;
int soc_variant;
+
+ /* Used to preserve GPIO registers accross suspend/resume */
+ u32 out_reg;
+ u32 io_conf_reg;
+ u32 blink_en_reg;
+ u32 in_pol_reg;
+ u32 edge_mask_regs[4];
+ u32 level_mask_regs[4];
};
/*
@@ -554,6 +562,93 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
};
MODULE_DEVICE_TABLE(of, mvebu_gpio_of_match);
+static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
+ int i;
+
+ mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip));
+ mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip));
+ mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip));
+ mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip));
+
+ switch (mvchip->soc_variant) {
+ case MVEBU_GPIO_SOC_VARIANT_ORION:
+ mvchip->edge_mask_regs[0] =
+ readl(mvchip->membase + GPIO_EDGE_MASK_OFF);
+ mvchip->level_mask_regs[0] =
+ readl(mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ for (i = 0; i < 2; i++) {
+ mvchip->edge_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_EDGE_MASK_MV78200_OFF(i));
+ mvchip->level_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_LEVEL_MASK_MV78200_OFF(i));
+ }
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
+ for (i = 0; i < 4; i++) {
+ mvchip->edge_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i));
+ mvchip->level_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ }
+ break;
+ default:
+ BUG();
+ }
+
+ return 0;
+}
+
+static int mvebu_gpio_resume(struct platform_device *pdev)
+{
+ struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
+ int i;
+
+ writel(mvchip->out_reg, mvebu_gpioreg_out(mvchip));
+ writel(mvchip->io_conf_reg, mvebu_gpioreg_io_conf(mvchip));
+ writel(mvchip->blink_en_reg, mvebu_gpioreg_blink(mvchip));
+ writel(mvchip->in_pol_reg, mvebu_gpioreg_in_pol(mvchip));
+
+ switch (mvchip->soc_variant) {
+ case MVEBU_GPIO_SOC_VARIANT_ORION:
+ writel(mvchip->edge_mask_regs[0],
+ mvchip->membase + GPIO_EDGE_MASK_OFF);
+ writel(mvchip->level_mask_regs[0],
+ mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ for (i = 0; i < 2; i++) {
+ writel(mvchip->edge_mask_regs[i],
+ mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(i));
+ writel(mvchip->level_mask_regs[i],
+ mvchip->membase +
+ GPIO_LEVEL_MASK_MV78200_OFF(i));
+ }
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
+ for (i = 0; i < 4; i++) {
+ writel(mvchip->edge_mask_regs[i],
+ mvchip->membase +
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i));
+ writel(mvchip->level_mask_regs[i],
+ mvchip->membase +
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ }
+ break;
+ default:
+ BUG();
+ }
+
+ return 0;
+}
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
@@ -577,6 +672,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
if (!mvchip)
return -ENOMEM;
+ platform_set_drvdata(pdev, mvchip);
+
if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios)) {
dev_err(&pdev->dev, "Missing ngpios OF property\n");
return -ENODEV;
@@ -735,5 +832,7 @@ static struct platform_driver mvebu_gpio_driver = {
.of_match_table = mvebu_gpio_of_match,
},
.probe = mvebu_gpio_probe,
+ .suspend = mvebu_gpio_suspend,
+ .resume = mvebu_gpio_resume,
};
module_platform_driver(mvebu_gpio_driver);
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 05/16] gpio: mvebu: add suspend/resume support
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds the implementation of ->suspend() and ->resume()
platform_driver hooks in order to save and restore the state of the
GPIO configuration. In order to achieve that, additional fields are
added to the mvebu_gpio_chip structure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio at vger.kernel.org
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/gpio/gpio-mvebu.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 418e386..dd5545c 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -83,6 +83,14 @@ struct mvebu_gpio_chip {
int irqbase;
struct irq_domain *domain;
int soc_variant;
+
+ /* Used to preserve GPIO registers accross suspend/resume */
+ u32 out_reg;
+ u32 io_conf_reg;
+ u32 blink_en_reg;
+ u32 in_pol_reg;
+ u32 edge_mask_regs[4];
+ u32 level_mask_regs[4];
};
/*
@@ -554,6 +562,93 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
};
MODULE_DEVICE_TABLE(of, mvebu_gpio_of_match);
+static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
+ int i;
+
+ mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip));
+ mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip));
+ mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip));
+ mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip));
+
+ switch (mvchip->soc_variant) {
+ case MVEBU_GPIO_SOC_VARIANT_ORION:
+ mvchip->edge_mask_regs[0] =
+ readl(mvchip->membase + GPIO_EDGE_MASK_OFF);
+ mvchip->level_mask_regs[0] =
+ readl(mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ for (i = 0; i < 2; i++) {
+ mvchip->edge_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_EDGE_MASK_MV78200_OFF(i));
+ mvchip->level_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_LEVEL_MASK_MV78200_OFF(i));
+ }
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
+ for (i = 0; i < 4; i++) {
+ mvchip->edge_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i));
+ mvchip->level_mask_regs[i] =
+ readl(mvchip->membase +
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ }
+ break;
+ default:
+ BUG();
+ }
+
+ return 0;
+}
+
+static int mvebu_gpio_resume(struct platform_device *pdev)
+{
+ struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev);
+ int i;
+
+ writel(mvchip->out_reg, mvebu_gpioreg_out(mvchip));
+ writel(mvchip->io_conf_reg, mvebu_gpioreg_io_conf(mvchip));
+ writel(mvchip->blink_en_reg, mvebu_gpioreg_blink(mvchip));
+ writel(mvchip->in_pol_reg, mvebu_gpioreg_in_pol(mvchip));
+
+ switch (mvchip->soc_variant) {
+ case MVEBU_GPIO_SOC_VARIANT_ORION:
+ writel(mvchip->edge_mask_regs[0],
+ mvchip->membase + GPIO_EDGE_MASK_OFF);
+ writel(mvchip->level_mask_regs[0],
+ mvchip->membase + GPIO_LEVEL_MASK_OFF);
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_MV78200:
+ for (i = 0; i < 2; i++) {
+ writel(mvchip->edge_mask_regs[i],
+ mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(i));
+ writel(mvchip->level_mask_regs[i],
+ mvchip->membase +
+ GPIO_LEVEL_MASK_MV78200_OFF(i));
+ }
+ break;
+ case MVEBU_GPIO_SOC_VARIANT_ARMADAXP:
+ for (i = 0; i < 4; i++) {
+ writel(mvchip->edge_mask_regs[i],
+ mvchip->membase +
+ GPIO_EDGE_MASK_ARMADAXP_OFF(i));
+ writel(mvchip->level_mask_regs[i],
+ mvchip->membase +
+ GPIO_LEVEL_MASK_ARMADAXP_OFF(i));
+ }
+ break;
+ default:
+ BUG();
+ }
+
+ return 0;
+}
+
static int mvebu_gpio_probe(struct platform_device *pdev)
{
struct mvebu_gpio_chip *mvchip;
@@ -577,6 +672,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
if (!mvchip)
return -ENOMEM;
+ platform_set_drvdata(pdev, mvchip);
+
if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios)) {
dev_err(&pdev->dev, "Missing ngpios OF property\n");
return -ENODEV;
@@ -735,5 +832,7 @@ static struct platform_driver mvebu_gpio_driver = {
.of_match_table = mvebu_gpio_of_match,
},
.probe = mvebu_gpio_probe,
+ .suspend = mvebu_gpio_suspend,
+ .resume = mvebu_gpio_resume,
};
module_platform_driver(mvebu_gpio_driver);
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 06/16] bus: mvebu-mbus: suspend/resume support
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
This commit extends the mvebu-mbus driver to provide suspend/resume
support. Since mvebu-mbus is not a platform_driver, the syscore_ops
mechanism is used to get ->suspend() and ->resume() hooks called into
the driver.
In those hooks, we save and restore the MBus windows state, to make
sure after resume all Mbus windows are properly restored. Note that
while the state of some windows could be gathered by looking again at
the Device Tree (for statically described windows), it is not the case
of dynamically described windows such as the PCIe memory and I/O
windows. Therefore, we take the simple approach of saving and
restoring the registers for all MBus windows.
In addition, the commit extends the Device Tree binding of the MBus
controller, to control the MBus bridge registers (which define which
parts of the physical address space is routed to MBus windows
vs. normal RAM memory). Those registers must be saved and restored
during suspend/resume. The Device Tree binding extension is made is a
backward compatible fashion, but of course, suspend/resume will not
work without the Device Tree update.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 17 +--
drivers/bus/mvebu-mbus.c | 124 ++++++++++++++++++++-
2 files changed, 130 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index 5fa44f5..5e16c3c 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -48,9 +48,12 @@ Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
- Two entries are expected (see the examples below):
- the first one controls the devices decoding window and
- the second one controls the SDRAM decoding window.
+ Two or three entries are expected (see the examples below):
+ the first one controls the devices decoding window,
+ the second one controls the SDRAM decoding window and
+ the third controls the MBus bridge (only with the
+ marvell,armada370-mbus and marvell,armadaxp-mbus
+ compatible strings)
Example:
@@ -67,7 +70,7 @@ Example:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@@ -126,7 +129,7 @@ are skipped.
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@@ -170,7 +173,7 @@ Using this macro, the above example would be:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* other children */
@@ -266,7 +269,7 @@ See the example below, where a more complete device tree is shown:
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
interrupt-controller@20000 {
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 26c3779d..e8c1593 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -57,6 +57,7 @@
#include <linux/of_address.h>
#include <linux/debugfs.h>
#include <linux/log2.h>
+#include <linux/syscore_ops.h>
/*
* DDR target is the same on all platforms.
@@ -94,20 +95,39 @@
#define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
+/* Relative to mbusbridge_base */
+#define MBUS_BRIDGE_CTRL_OFF 0x0
+#define MBUS_BRIDGE_BASE_OFF 0x4
+
+/* Maximum number of windows, for all known platforms */
+#define MBUS_WINS_MAX 20
+
struct mvebu_mbus_state;
struct mvebu_mbus_soc_data {
unsigned int num_wins;
unsigned int num_remappable_wins;
+ bool has_mbus_bridge;
unsigned int (*win_cfg_offset)(const int win);
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
};
+/*
+ * Used to store the state of one MBus window accross suspend/resume.
+ */
+struct mvebu_mbus_win_data {
+ u32 ctrl;
+ u32 base;
+ u32 remap_lo;
+ u32 remap_hi;
+};
+
struct mvebu_mbus_state {
void __iomem *mbuswins_base;
void __iomem *sdramwins_base;
+ void __iomem *mbusbridge_base;
struct dentry *debugfs_root;
struct dentry *debugfs_sdram;
struct dentry *debugfs_devs;
@@ -115,6 +135,11 @@ struct mvebu_mbus_state {
struct resource pcie_io_aperture;
const struct mvebu_mbus_soc_data *soc;
int hw_io_coherency;
+
+ /* Used during suspend/resume */
+ u32 mbus_bridge_ctrl;
+ u32 mbus_bridge_base;
+ struct mvebu_mbus_win_data wins[MBUS_WINS_MAX];
};
static struct mvebu_mbus_state mbus_state;
@@ -549,6 +574,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins = 20,
.num_remappable_wins = 8,
+ .has_mbus_bridge = true,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
@@ -698,11 +724,73 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
+static int mvebu_mbus_suspend(void)
+{
+ struct mvebu_mbus_state *s = &mbus_state;
+ int win;
+
+ if (!s->mbusbridge_base)
+ return -ENODEV;
+
+ for (win = 0; win < s->soc->num_wins; win++) {
+ void __iomem *addr = s->mbuswins_base +
+ s->soc->win_cfg_offset(win);
+
+ s->wins[win].base = readl(addr + WIN_BASE_OFF);
+ s->wins[win].ctrl = readl(addr + WIN_CTRL_OFF);
+
+ if (win >= s->soc->num_remappable_wins)
+ continue;
+
+ s->wins[win].remap_lo = readl(addr + WIN_REMAP_LO_OFF);
+ s->wins[win].remap_hi = readl(addr + WIN_REMAP_HI_OFF);
+ }
+
+ s->mbus_bridge_ctrl = readl(s->mbusbridge_base +
+ MBUS_BRIDGE_CTRL_OFF);
+ s->mbus_bridge_base = readl(s->mbusbridge_base +
+ MBUS_BRIDGE_BASE_OFF);
+
+ return 0;
+}
+
+static void mvebu_mbus_resume(void)
+{
+ struct mvebu_mbus_state *s = &mbus_state;
+ int win;
+
+ writel(s->mbus_bridge_ctrl,
+ s->mbusbridge_base + MBUS_BRIDGE_CTRL_OFF);
+ writel(s->mbus_bridge_base,
+ s->mbusbridge_base + MBUS_BRIDGE_BASE_OFF);
+
+ for (win = 0; win < s->soc->num_wins; win++) {
+ void __iomem *addr = s->mbuswins_base +
+ s->soc->win_cfg_offset(win);
+
+ writel(s->wins[win].base, addr + WIN_BASE_OFF);
+ writel(s->wins[win].ctrl, addr + WIN_CTRL_OFF);
+
+ if (win >= s->soc->num_remappable_wins)
+ continue;
+
+ writel(s->wins[win].remap_lo, addr + WIN_REMAP_LO_OFF);
+ writel(s->wins[win].remap_hi, addr + WIN_REMAP_HI_OFF);
+ }
+}
+
+struct syscore_ops mvebu_mbus_syscore_ops = {
+ .suspend = mvebu_mbus_suspend,
+ .resume = mvebu_mbus_resume,
+};
+
static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
phys_addr_t mbuswins_phys_base,
size_t mbuswins_size,
phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+ size_t sdramwins_size,
+ phys_addr_t mbusbridge_phys_base,
+ size_t mbusbridge_size)
{
int win;
@@ -716,11 +804,24 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
return -ENOMEM;
}
+ if (mbusbridge_phys_base) {
+ mbus->mbusbridge_base = ioremap(mbusbridge_phys_base,
+ mbusbridge_size);
+ if (!mbus->mbusbridge_base) {
+ iounmap(mbus->sdramwins_base);
+ iounmap(mbus->mbuswins_base);
+ return -ENOMEM;
+ }
+ } else
+ mbus->mbusbridge_base = NULL;
+
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
mbus->soc->setup_cpu_target(mbus);
+ register_syscore_ops(&mvebu_mbus_syscore_ops);
+
return 0;
}
@@ -746,7 +847,7 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
mbuswins_phys_base,
mbuswins_size,
sdramwins_phys_base,
- sdramwins_size);
+ sdramwins_size, 0, 0);
}
#ifdef CONFIG_OF
@@ -887,7 +988,7 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
int __init mvebu_mbus_dt_init(bool is_coherent)
{
- struct resource mbuswins_res, sdramwins_res;
+ struct resource mbuswins_res, sdramwins_res, mbusbridge_res;
struct device_node *np, *controller;
const struct of_device_id *of_id;
const __be32 *prop;
@@ -923,6 +1024,19 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
return -EINVAL;
}
+ /*
+ * Set the resource to 0 so that it can be left unmapped by
+ * mvebu_mbus_common_init() if the DT doesn't carry the
+ * necessary information. This is needed to preserve backward
+ * compatibility.
+ */
+ memset(&mbusbridge_res, 0, sizeof(mbusbridge_res));
+
+ if (mbus_state.soc->has_mbus_bridge) {
+ if (of_address_to_resource(controller, 2, &mbusbridge_res))
+ pr_warn(FW_WARN "deprecated mbus-mvebu Device Tree, suspend/resume will not work\n");
+ }
+
mbus_state.hw_io_coherency = is_coherent;
/* Get optional pcie-{mem,io}-aperture properties */
@@ -933,7 +1047,9 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
mbuswins_res.start,
resource_size(&mbuswins_res),
sdramwins_res.start,
- resource_size(&sdramwins_res));
+ resource_size(&sdramwins_res),
+ mbusbridge_res.start,
+ resource_size(&mbusbridge_res));
if (ret)
return ret;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 06/16] bus: mvebu-mbus: suspend/resume support
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
This commit extends the mvebu-mbus driver to provide suspend/resume
support. Since mvebu-mbus is not a platform_driver, the syscore_ops
mechanism is used to get ->suspend() and ->resume() hooks called into
the driver.
In those hooks, we save and restore the MBus windows state, to make
sure after resume all Mbus windows are properly restored. Note that
while the state of some windows could be gathered by looking again at
the Device Tree (for statically described windows), it is not the case
of dynamically described windows such as the PCIe memory and I/O
windows. Therefore, we take the simple approach of saving and
restoring the registers for all MBus windows.
In addition, the commit extends the Device Tree binding of the MBus
controller, to control the MBus bridge registers (which define which
parts of the physical address space is routed to MBus windows
vs. normal RAM memory). Those registers must be saved and restored
during suspend/resume. The Device Tree binding extension is made is a
backward compatible fashion, but of course, suspend/resume will not
work without the Device Tree update.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 17 +--
drivers/bus/mvebu-mbus.c | 124 ++++++++++++++++++++-
2 files changed, 130 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index 5fa44f5..5e16c3c 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -48,9 +48,12 @@ Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
- Two entries are expected (see the examples below):
- the first one controls the devices decoding window and
- the second one controls the SDRAM decoding window.
+ Two or three entries are expected (see the examples below):
+ the first one controls the devices decoding window,
+ the second one controls the SDRAM decoding window and
+ the third controls the MBus bridge (only with the
+ marvell,armada370-mbus and marvell,armadaxp-mbus
+ compatible strings)
Example:
@@ -67,7 +70,7 @@ Example:
mbusc: mbus-controller at 20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@@ -126,7 +129,7 @@ are skipped.
mbusc: mbus-controller at 20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@@ -170,7 +173,7 @@ Using this macro, the above example would be:
mbusc: mbus-controller at 20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* other children */
@@ -266,7 +269,7 @@ See the example below, where a more complete device tree is shown:
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller at 20000 {
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
interrupt-controller at 20000 {
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 26c3779d..e8c1593 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -57,6 +57,7 @@
#include <linux/of_address.h>
#include <linux/debugfs.h>
#include <linux/log2.h>
+#include <linux/syscore_ops.h>
/*
* DDR target is the same on all platforms.
@@ -94,20 +95,39 @@
#define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
+/* Relative to mbusbridge_base */
+#define MBUS_BRIDGE_CTRL_OFF 0x0
+#define MBUS_BRIDGE_BASE_OFF 0x4
+
+/* Maximum number of windows, for all known platforms */
+#define MBUS_WINS_MAX 20
+
struct mvebu_mbus_state;
struct mvebu_mbus_soc_data {
unsigned int num_wins;
unsigned int num_remappable_wins;
+ bool has_mbus_bridge;
unsigned int (*win_cfg_offset)(const int win);
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
};
+/*
+ * Used to store the state of one MBus window accross suspend/resume.
+ */
+struct mvebu_mbus_win_data {
+ u32 ctrl;
+ u32 base;
+ u32 remap_lo;
+ u32 remap_hi;
+};
+
struct mvebu_mbus_state {
void __iomem *mbuswins_base;
void __iomem *sdramwins_base;
+ void __iomem *mbusbridge_base;
struct dentry *debugfs_root;
struct dentry *debugfs_sdram;
struct dentry *debugfs_devs;
@@ -115,6 +135,11 @@ struct mvebu_mbus_state {
struct resource pcie_io_aperture;
const struct mvebu_mbus_soc_data *soc;
int hw_io_coherency;
+
+ /* Used during suspend/resume */
+ u32 mbus_bridge_ctrl;
+ u32 mbus_bridge_base;
+ struct mvebu_mbus_win_data wins[MBUS_WINS_MAX];
};
static struct mvebu_mbus_state mbus_state;
@@ -549,6 +574,7 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins = 20,
.num_remappable_wins = 8,
+ .has_mbus_bridge = true,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
@@ -698,11 +724,73 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
+static int mvebu_mbus_suspend(void)
+{
+ struct mvebu_mbus_state *s = &mbus_state;
+ int win;
+
+ if (!s->mbusbridge_base)
+ return -ENODEV;
+
+ for (win = 0; win < s->soc->num_wins; win++) {
+ void __iomem *addr = s->mbuswins_base +
+ s->soc->win_cfg_offset(win);
+
+ s->wins[win].base = readl(addr + WIN_BASE_OFF);
+ s->wins[win].ctrl = readl(addr + WIN_CTRL_OFF);
+
+ if (win >= s->soc->num_remappable_wins)
+ continue;
+
+ s->wins[win].remap_lo = readl(addr + WIN_REMAP_LO_OFF);
+ s->wins[win].remap_hi = readl(addr + WIN_REMAP_HI_OFF);
+ }
+
+ s->mbus_bridge_ctrl = readl(s->mbusbridge_base +
+ MBUS_BRIDGE_CTRL_OFF);
+ s->mbus_bridge_base = readl(s->mbusbridge_base +
+ MBUS_BRIDGE_BASE_OFF);
+
+ return 0;
+}
+
+static void mvebu_mbus_resume(void)
+{
+ struct mvebu_mbus_state *s = &mbus_state;
+ int win;
+
+ writel(s->mbus_bridge_ctrl,
+ s->mbusbridge_base + MBUS_BRIDGE_CTRL_OFF);
+ writel(s->mbus_bridge_base,
+ s->mbusbridge_base + MBUS_BRIDGE_BASE_OFF);
+
+ for (win = 0; win < s->soc->num_wins; win++) {
+ void __iomem *addr = s->mbuswins_base +
+ s->soc->win_cfg_offset(win);
+
+ writel(s->wins[win].base, addr + WIN_BASE_OFF);
+ writel(s->wins[win].ctrl, addr + WIN_CTRL_OFF);
+
+ if (win >= s->soc->num_remappable_wins)
+ continue;
+
+ writel(s->wins[win].remap_lo, addr + WIN_REMAP_LO_OFF);
+ writel(s->wins[win].remap_hi, addr + WIN_REMAP_HI_OFF);
+ }
+}
+
+struct syscore_ops mvebu_mbus_syscore_ops = {
+ .suspend = mvebu_mbus_suspend,
+ .resume = mvebu_mbus_resume,
+};
+
static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
phys_addr_t mbuswins_phys_base,
size_t mbuswins_size,
phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+ size_t sdramwins_size,
+ phys_addr_t mbusbridge_phys_base,
+ size_t mbusbridge_size)
{
int win;
@@ -716,11 +804,24 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
return -ENOMEM;
}
+ if (mbusbridge_phys_base) {
+ mbus->mbusbridge_base = ioremap(mbusbridge_phys_base,
+ mbusbridge_size);
+ if (!mbus->mbusbridge_base) {
+ iounmap(mbus->sdramwins_base);
+ iounmap(mbus->mbuswins_base);
+ return -ENOMEM;
+ }
+ } else
+ mbus->mbusbridge_base = NULL;
+
for (win = 0; win < mbus->soc->num_wins; win++)
mvebu_mbus_disable_window(mbus, win);
mbus->soc->setup_cpu_target(mbus);
+ register_syscore_ops(&mvebu_mbus_syscore_ops);
+
return 0;
}
@@ -746,7 +847,7 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
mbuswins_phys_base,
mbuswins_size,
sdramwins_phys_base,
- sdramwins_size);
+ sdramwins_size, 0, 0);
}
#ifdef CONFIG_OF
@@ -887,7 +988,7 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
int __init mvebu_mbus_dt_init(bool is_coherent)
{
- struct resource mbuswins_res, sdramwins_res;
+ struct resource mbuswins_res, sdramwins_res, mbusbridge_res;
struct device_node *np, *controller;
const struct of_device_id *of_id;
const __be32 *prop;
@@ -923,6 +1024,19 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
return -EINVAL;
}
+ /*
+ * Set the resource to 0 so that it can be left unmapped by
+ * mvebu_mbus_common_init() if the DT doesn't carry the
+ * necessary information. This is needed to preserve backward
+ * compatibility.
+ */
+ memset(&mbusbridge_res, 0, sizeof(mbusbridge_res));
+
+ if (mbus_state.soc->has_mbus_bridge) {
+ if (of_address_to_resource(controller, 2, &mbusbridge_res))
+ pr_warn(FW_WARN "deprecated mbus-mvebu Device Tree, suspend/resume will not work\n");
+ }
+
mbus_state.hw_io_coherency = is_coherent;
/* Get optional pcie-{mem,io}-aperture properties */
@@ -933,7 +1047,9 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
mbuswins_res.start,
resource_size(&mbuswins_res),
sdramwins_res.start,
- resource_size(&sdramwins_res));
+ resource_size(&sdramwins_res),
+ mbusbridge_res.start,
+ resource_size(&mbusbridge_res));
if (ret)
return ret;
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 07/16] bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
On Marvell EBU platforms, when doing suspend/resume, the SDRAM window
configuration must be saved on suspend, and restored on
resume. However, it needs to be restored on resume *before*
re-entering the kernel, because the SDRAM window configuration defines
the layout of the memory. For this reason, it cannot simply be done in
the ->suspend() and ->resume() hooks of the mvebu-mbus driver.
Instead, it needs to be restored by the bootloader "boot info"
mechanism used when resuming. This mechanism allows the kernel to
define a list of (address, value) pairs when suspending, that the
bootloader will restore on resume before jumping back into the kernel.
This commit therefore adds a new function to the mvebu-mbus driver,
called mvebu_mbus_save_cpu_target(), which will be called by the
platform code to make the mvebu-mbus driver save the SDRAM window
configuration in a way that can be understood by the bootloader "boot
info" mechanism.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/bus/mvebu-mbus.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mbus.h | 1 +
2 files changed, 57 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index e8c1593..eb7682d 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -110,6 +110,8 @@ struct mvebu_mbus_soc_data {
bool has_mbus_bridge;
unsigned int (*win_cfg_offset)(const int win);
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
+ int (*save_cpu_target)(struct mvebu_mbus_state *s,
+ u32 *store_addr);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
};
@@ -128,6 +130,7 @@ struct mvebu_mbus_state {
void __iomem *mbuswins_base;
void __iomem *sdramwins_base;
void __iomem *mbusbridge_base;
+ phys_addr_t sdramwins_phys_base;
struct dentry *debugfs_root;
struct dentry *debugfs_sdram;
struct dentry *debugfs_devs;
@@ -541,6 +544,28 @@ mvebu_mbus_default_setup_cpu_target(struct mvebu_mbus_state *mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
+static int
+mvebu_mbus_default_save_cpu_target(struct mvebu_mbus_state *mbus,
+ u32 *store_addr)
+{
+ int i;
+
+ for (i = 0; i < 4; i++) {
+ u32 base = readl(mbus->sdramwins_base + DDR_BASE_CS_OFF(i));
+ u32 size = readl(mbus->sdramwins_base + DDR_SIZE_CS_OFF(i));
+
+ writel(mbus->sdramwins_phys_base + DDR_BASE_CS_OFF(i),
+ store_addr++);
+ writel(base, store_addr++);
+ writel(mbus->sdramwins_phys_base + DDR_SIZE_CS_OFF(i),
+ store_addr++);
+ writel(size, store_addr++);
+ }
+
+ /* We've written 16 words to the store address */
+ return 16;
+}
+
static void __init
mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
{
@@ -571,11 +596,35 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
+static int
+mvebu_mbus_dove_save_cpu_target(struct mvebu_mbus_state *mbus,
+ u32 *store_addr)
+{
+ int i;
+
+ for (i = 0; i < 2; i++) {
+ u32 map = readl(mbus->sdramwins_base + DOVE_DDR_BASE_CS_OFF(i));
+
+ writel(mbus->sdramwins_phys_base + DOVE_DDR_BASE_CS_OFF(i),
+ store_addr++);
+ writel(map, store_addr++);
+ }
+
+ /* We've written 4 words to the store address */
+ return 4;
+}
+
+int mvebu_mbus_save_cpu_target(u32 *store_addr)
+{
+ return mbus_state.soc->save_cpu_target(&mbus_state, store_addr);
+}
+
static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins = 20,
.num_remappable_wins = 8,
.has_mbus_bridge = true,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -584,6 +633,7 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 4,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -592,6 +642,7 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 4,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_dove_save_cpu_target,
.setup_cpu_target = mvebu_mbus_dove_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_dove,
};
@@ -604,6 +655,7 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 4,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -612,6 +664,7 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 2,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -620,6 +673,7 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
.num_wins = 14,
.num_remappable_wins = 8,
.win_cfg_offset = mv78xx0_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -804,6 +858,8 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
return -ENOMEM;
}
+ mbus->sdramwins_phys_base = sdramwins_phys_base;
+
if (mbusbridge_phys_base) {
mbus->mbusbridge_base = ioremap(mbusbridge_phys_base,
mbusbridge_size);
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 550c88f..611b69f 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -61,6 +61,7 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
}
#endif
+int mvebu_mbus_save_cpu_target(u32 *store_addr);
void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 07/16] bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
On Marvell EBU platforms, when doing suspend/resume, the SDRAM window
configuration must be saved on suspend, and restored on
resume. However, it needs to be restored on resume *before*
re-entering the kernel, because the SDRAM window configuration defines
the layout of the memory. For this reason, it cannot simply be done in
the ->suspend() and ->resume() hooks of the mvebu-mbus driver.
Instead, it needs to be restored by the bootloader "boot info"
mechanism used when resuming. This mechanism allows the kernel to
define a list of (address, value) pairs when suspending, that the
bootloader will restore on resume before jumping back into the kernel.
This commit therefore adds a new function to the mvebu-mbus driver,
called mvebu_mbus_save_cpu_target(), which will be called by the
platform code to make the mvebu-mbus driver save the SDRAM window
configuration in a way that can be understood by the bootloader "boot
info" mechanism.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/bus/mvebu-mbus.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mbus.h | 1 +
2 files changed, 57 insertions(+)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index e8c1593..eb7682d 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -110,6 +110,8 @@ struct mvebu_mbus_soc_data {
bool has_mbus_bridge;
unsigned int (*win_cfg_offset)(const int win);
void (*setup_cpu_target)(struct mvebu_mbus_state *s);
+ int (*save_cpu_target)(struct mvebu_mbus_state *s,
+ u32 *store_addr);
int (*show_cpu_target)(struct mvebu_mbus_state *s,
struct seq_file *seq, void *v);
};
@@ -128,6 +130,7 @@ struct mvebu_mbus_state {
void __iomem *mbuswins_base;
void __iomem *sdramwins_base;
void __iomem *mbusbridge_base;
+ phys_addr_t sdramwins_phys_base;
struct dentry *debugfs_root;
struct dentry *debugfs_sdram;
struct dentry *debugfs_devs;
@@ -541,6 +544,28 @@ mvebu_mbus_default_setup_cpu_target(struct mvebu_mbus_state *mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
+static int
+mvebu_mbus_default_save_cpu_target(struct mvebu_mbus_state *mbus,
+ u32 *store_addr)
+{
+ int i;
+
+ for (i = 0; i < 4; i++) {
+ u32 base = readl(mbus->sdramwins_base + DDR_BASE_CS_OFF(i));
+ u32 size = readl(mbus->sdramwins_base + DDR_SIZE_CS_OFF(i));
+
+ writel(mbus->sdramwins_phys_base + DDR_BASE_CS_OFF(i),
+ store_addr++);
+ writel(base, store_addr++);
+ writel(mbus->sdramwins_phys_base + DDR_SIZE_CS_OFF(i),
+ store_addr++);
+ writel(size, store_addr++);
+ }
+
+ /* We've written 16 words to the store address */
+ return 16;
+}
+
static void __init
mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
{
@@ -571,11 +596,35 @@ mvebu_mbus_dove_setup_cpu_target(struct mvebu_mbus_state *mbus)
mvebu_mbus_dram_info.num_cs = cs;
}
+static int
+mvebu_mbus_dove_save_cpu_target(struct mvebu_mbus_state *mbus,
+ u32 *store_addr)
+{
+ int i;
+
+ for (i = 0; i < 2; i++) {
+ u32 map = readl(mbus->sdramwins_base + DOVE_DDR_BASE_CS_OFF(i));
+
+ writel(mbus->sdramwins_phys_base + DOVE_DDR_BASE_CS_OFF(i),
+ store_addr++);
+ writel(map, store_addr++);
+ }
+
+ /* We've written 4 words to the store address */
+ return 4;
+}
+
+int mvebu_mbus_save_cpu_target(u32 *store_addr)
+{
+ return mbus_state.soc->save_cpu_target(&mbus_state, store_addr);
+}
+
static const struct mvebu_mbus_soc_data armada_370_xp_mbus_data = {
.num_wins = 20,
.num_remappable_wins = 8,
.has_mbus_bridge = true,
.win_cfg_offset = armada_370_xp_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -584,6 +633,7 @@ static const struct mvebu_mbus_soc_data kirkwood_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 4,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -592,6 +642,7 @@ static const struct mvebu_mbus_soc_data dove_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 4,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_dove_save_cpu_target,
.setup_cpu_target = mvebu_mbus_dove_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_dove,
};
@@ -604,6 +655,7 @@ static const struct mvebu_mbus_soc_data orion5x_4win_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 4,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -612,6 +664,7 @@ static const struct mvebu_mbus_soc_data orion5x_2win_mbus_data = {
.num_wins = 8,
.num_remappable_wins = 2,
.win_cfg_offset = orion_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -620,6 +673,7 @@ static const struct mvebu_mbus_soc_data mv78xx0_mbus_data = {
.num_wins = 14,
.num_remappable_wins = 8,
.win_cfg_offset = mv78xx0_mbus_win_offset,
+ .save_cpu_target = mvebu_mbus_default_save_cpu_target,
.setup_cpu_target = mvebu_mbus_default_setup_cpu_target,
.show_cpu_target = mvebu_sdram_debug_show_orion,
};
@@ -804,6 +858,8 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
return -ENOMEM;
}
+ mbus->sdramwins_phys_base = sdramwins_phys_base;
+
if (mbusbridge_phys_base) {
mbus->mbusbridge_base = ioremap(mbusbridge_phys_base,
mbusbridge_size);
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 550c88f..611b69f 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -61,6 +61,7 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
}
#endif
+int mvebu_mbus_save_cpu_target(u32 *store_addr);
void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Thomas Petazzoni, Mike Turquette,
linux-kernel
This commit adds suspend/resume support for the gatable clock driver
used on Marvell EBU platforms. When getting out of suspend, the
Marvell EBU platforms go through the bootloader, which re-enables all
gatable clocks. However, upon resume, the clock framework will not
disable again all gatable clocks that are not used.
Therefore, if the clock driver does not save/restore the state of the
gatable clocks, all gatable clocks that are not claimed by any device
driver will remain enabled after a resume. This is why this driver
saves and restores the state of those clocks.
Since clocks aren't real devices, we don't have the normal ->suspend()
and ->resume() of the device model, and have to use the ->suspend()
and ->resume() hooks of the syscore_ops mechanism. This mechanism has
the unfortunate idea of not providing a way of passing private data,
which requires us to change the driver to make the assumption that
there is only once instance of the gatable clock control structure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: linux-kernel@vger.kernel.org
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/clk/mvebu/common.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
index b7fcb46..0d4d121 100644
--- a/drivers/clk/mvebu/common.c
+++ b/drivers/clk/mvebu/common.c
@@ -19,6 +19,7 @@
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include "common.h"
@@ -177,14 +178,17 @@ struct clk_gating_ctrl {
spinlock_t *lock;
struct clk **gates;
int num_gates;
+ void __iomem *base;
+ u32 saved_reg;
};
#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
+static struct clk_gating_ctrl *ctrl;
+
static struct clk *clk_gating_get_src(
struct of_phandle_args *clkspec, void *data)
{
- struct clk_gating_ctrl *ctrl = (struct clk_gating_ctrl *)data;
int n;
if (clkspec->args_count < 1)
@@ -199,15 +203,35 @@ static struct clk *clk_gating_get_src(
return ERR_PTR(-ENODEV);
}
+static int mvebu_clk_gating_suspend(void)
+{
+ ctrl->saved_reg = readl(ctrl->base);
+ return 0;
+}
+
+static void mvebu_clk_gating_resume(void)
+{
+ writel(ctrl->saved_reg, ctrl->base);
+}
+
+static struct syscore_ops clk_gate_syscore_ops = {
+ .suspend = mvebu_clk_gating_suspend,
+ .resume = mvebu_clk_gating_resume,
+};
+
void __init mvebu_clk_gating_setup(struct device_node *np,
const struct clk_gating_soc_desc *desc)
{
- struct clk_gating_ctrl *ctrl;
struct clk *clk;
void __iomem *base;
const char *default_parent = NULL;
int n;
+ if (ctrl) {
+ pr_err("mvebu-clk-gating: cannot instantiate more than one gatable clock device\n");
+ return;
+ }
+
base = of_iomap(np, 0);
if (WARN_ON(!base))
return;
@@ -225,6 +249,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
/* lock must already be initialized */
ctrl->lock = &ctrl_gating_lock;
+ ctrl->base = base;
+
/* Count, allocate, and register clock gates */
for (n = 0; desc[n].name;)
n++;
@@ -246,6 +272,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
of_clk_add_provider(np, clk_gating_get_src, ctrl);
+ register_syscore_ops(&clk_gate_syscore_ops);
+
return;
gates_out:
kfree(ctrl);
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
This commit adds suspend/resume support for the gatable clock driver
used on Marvell EBU platforms. When getting out of suspend, the
Marvell EBU platforms go through the bootloader, which re-enables all
gatable clocks. However, upon resume, the clock framework will not
disable again all gatable clocks that are not used.
Therefore, if the clock driver does not save/restore the state of the
gatable clocks, all gatable clocks that are not claimed by any device
driver will remain enabled after a resume. This is why this driver
saves and restores the state of those clocks.
Since clocks aren't real devices, we don't have the normal ->suspend()
and ->resume() of the device model, and have to use the ->suspend()
and ->resume() hooks of the syscore_ops mechanism. This mechanism has
the unfortunate idea of not providing a way of passing private data,
which requires us to change the driver to make the assumption that
there is only once instance of the gatable clock control structure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: linux-kernel at vger.kernel.org
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/clk/mvebu/common.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
index b7fcb46..0d4d121 100644
--- a/drivers/clk/mvebu/common.c
+++ b/drivers/clk/mvebu/common.c
@@ -19,6 +19,7 @@
#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/syscore_ops.h>
#include "common.h"
@@ -177,14 +178,17 @@ struct clk_gating_ctrl {
spinlock_t *lock;
struct clk **gates;
int num_gates;
+ void __iomem *base;
+ u32 saved_reg;
};
#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
+static struct clk_gating_ctrl *ctrl;
+
static struct clk *clk_gating_get_src(
struct of_phandle_args *clkspec, void *data)
{
- struct clk_gating_ctrl *ctrl = (struct clk_gating_ctrl *)data;
int n;
if (clkspec->args_count < 1)
@@ -199,15 +203,35 @@ static struct clk *clk_gating_get_src(
return ERR_PTR(-ENODEV);
}
+static int mvebu_clk_gating_suspend(void)
+{
+ ctrl->saved_reg = readl(ctrl->base);
+ return 0;
+}
+
+static void mvebu_clk_gating_resume(void)
+{
+ writel(ctrl->saved_reg, ctrl->base);
+}
+
+static struct syscore_ops clk_gate_syscore_ops = {
+ .suspend = mvebu_clk_gating_suspend,
+ .resume = mvebu_clk_gating_resume,
+};
+
void __init mvebu_clk_gating_setup(struct device_node *np,
const struct clk_gating_soc_desc *desc)
{
- struct clk_gating_ctrl *ctrl;
struct clk *clk;
void __iomem *base;
const char *default_parent = NULL;
int n;
+ if (ctrl) {
+ pr_err("mvebu-clk-gating: cannot instantiate more than one gatable clock device\n");
+ return;
+ }
+
base = of_iomap(np, 0);
if (WARN_ON(!base))
return;
@@ -225,6 +249,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
/* lock must already be initialized */
ctrl->lock = &ctrl_gating_lock;
+ ctrl->base = base;
+
/* Count, allocate, and register clock gates */
for (n = 0; desc[n].name;)
n++;
@@ -246,6 +272,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
of_clk_add_provider(np, clk_gating_get_src, ctrl);
+ register_syscore_ops(&clk_gate_syscore_ops);
+
return;
gates_out:
kfree(ctrl);
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas 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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/common.h | 2 +
arch/arm/mach-mvebu/pm.c | 218 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-mvebu/pmsu.h | 1 +
4 files changed, 222 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/pm.c
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index e24136b..e2bd96f 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -7,7 +7,7 @@ CFLAGS_pmsu.o := -march=armv7-a
obj-$(CONFIG_MACH_MVEBU_ANY) += system-controller.o mvebu-soc-id.o
ifeq ($(CONFIG_MACH_MVEBU_V7),y)
-obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o
+obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o pm.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o platsmp-a9.o headsmp-a9.o
endif
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 3ccb40c..3e0aca1 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -25,4 +25,6 @@ int mvebu_system_controller_get_soc_id(u32 *dev, u32 *rev);
void __iomem *mvebu_get_scu_base(void);
+int mvebu_pm_init(void (*board_pm_enter)(void __iomem *sdram_reg, u32 srcmd));
+
#endif
diff --git a/arch/arm/mach-mvebu/pm.c b/arch/arm/mach-mvebu/pm.c
new file mode 100644
index 0000000..6573a8f
--- /dev/null
+++ b/arch/arm/mach-mvebu/pm.c
@@ -0,0 +1,218 @@
+/*
+ * Suspend/resume support. Currently supporting Armada XP only.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * 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.
+ */
+
+#include <linux/cpu_pm.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mbus.h>
+#include <linux/of_address.h>
+#include <linux/suspend.h>
+#include <asm/cacheflush.h>
+#include <asm/outercache.h>
+#include <asm/suspend.h>
+
+#include "coherency.h"
+#include "pmsu.h"
+
+#define SDRAM_CONFIG_OFFS 0x0
+#define SDRAM_CONFIG_SR_MODE_BIT BIT(24)
+#define SDRAM_OPERATION_OFFS 0x18
+#define SDRAM_OPERATION_SELF_REFRESH 0x7
+#define SDRAM_DLB_EVICTION_OFFS 0x30c
+#define SDRAM_DLB_EVICTION_THRESHOLD_MASK 0xff
+
+static void (*mvebu_board_pm_enter)(void __iomem *sdram_reg, u32 srcmd);
+static void __iomem *sdram_ctrl;
+
+static int mvebu_pm_powerdown(unsigned long data)
+{
+ u32 reg, srcmd;
+
+ flush_cache_all();
+ outer_flush_all();
+
+ /*
+ * Issue a Data Synchronization Barrier instruction to ensure
+ * that all state saving has been completed.
+ */
+ dsb();
+
+ /* Flush the DLB and wait ~7 usec */
+ reg = readl(sdram_ctrl + SDRAM_DLB_EVICTION_OFFS);
+ reg &= ~SDRAM_DLB_EVICTION_THRESHOLD_MASK;
+ writel(reg, sdram_ctrl + SDRAM_DLB_EVICTION_OFFS);
+
+ udelay(7);
+
+ /* Set DRAM in battery backup mode */
+ reg = readl(sdram_ctrl + SDRAM_CONFIG_OFFS);
+ reg &= ~SDRAM_CONFIG_SR_MODE_BIT;
+ writel(reg, sdram_ctrl + SDRAM_CONFIG_OFFS);
+
+ /* Prepare to go to self-refresh */
+
+ srcmd = readl(sdram_ctrl + SDRAM_OPERATION_OFFS);
+ srcmd &= ~0x1F;
+ srcmd |= SDRAM_OPERATION_SELF_REFRESH;
+
+ mvebu_board_pm_enter(sdram_ctrl + SDRAM_OPERATION_OFFS, srcmd);
+
+ return 0;
+}
+
+#define BOOT_INFO_ADDR 0x3000
+#define BOOT_MAGIC_WORD 0xdeadb002
+#define BOOT_MAGIC_LIST_END 0xffffffff
+
+/*
+ * Those registers are accessed before switching the internal register
+ * base, which is why we hardcode the 0xd0000000 base address, the one
+ * used by the SoC out of reset.
+ */
+#define MBUS_WINDOW_12_CTRL 0xd00200b0
+#define MBUS_INTERNAL_REG_ADDRESS 0xd0020080
+
+#define SDRAM_WIN_BASE_REG(x) (0x20180 + (0x8*x))
+#define SDRAM_WIN_CTRL_REG(x) (0x20184 + (0x8*x))
+
+static phys_addr_t mvebu_internal_reg_base(void)
+{
+ struct device_node *np;
+ __be32 in_addr[2];
+
+ np = of_find_node_by_name(NULL, "internal-regs");
+ BUG_ON(!np);
+
+ /*
+ * Ask the DT what is the internal register address on this
+ * platform. In the mvebu-mbus DT binding, 0xf0010000
+ * corresponds to the internal register window.
+ */
+ in_addr[0] = cpu_to_be32(0xf0010000);
+ in_addr[1] = 0x0;
+
+ return of_translate_address(np, in_addr);
+}
+
+static void mvebu_pm_store_bootinfo(void)
+{
+ u32 *store_addr;
+ phys_addr_t resume_pc;
+
+ store_addr = phys_to_virt(BOOT_INFO_ADDR);
+ resume_pc = virt_to_phys(armada_370_xp_cpu_resume);
+
+ /*
+ * The bootloader expects the first two words to be a magic
+ * value (BOOT_MAGIC_WORD), followed by the address of the
+ * resume code to jump to. Then, it expects a sequence of
+ * (address, value) pairs, which can be used to restore the
+ * value of certain registers. This sequence must end with the
+ * BOOT_MAGIC_LIST_END magic value.
+ */
+
+ writel(BOOT_MAGIC_WORD, store_addr++);
+ writel(resume_pc, store_addr++);
+
+ /*
+ * Some platforms remap their internal register base address
+ * to 0xf1000000. However, out of reset, window 12 starts at
+ * 0xf0000000 and ends at 0xf7ffffff, which would overlap with
+ * the internal registers. Therefore, disable window 12.
+ */
+ writel(MBUS_WINDOW_12_CTRL, store_addr++);
+ writel(0x0, store_addr++);
+
+ /*
+ * Set the internal register base address to the value
+ * expected by Linux, as read from the Device Tree.
+ */
+ writel(MBUS_INTERNAL_REG_ADDRESS, store_addr++);
+ writel(mvebu_internal_reg_base(), store_addr++);
+
+ /*
+ * Ask the mvebu-mbus driver to store the SDRAM window
+ * configuration, which has to be restored by the bootloader
+ * before re-entering the kernel on resume.
+ */
+ store_addr += mvebu_mbus_save_cpu_target(store_addr);
+
+ writel(BOOT_MAGIC_LIST_END, store_addr);
+}
+
+static int mvebu_pm_enter(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ cpu_pm_enter();
+
+ mvebu_pm_store_bootinfo();
+ cpu_suspend(0, mvebu_pm_powerdown);
+
+ outer_resume();
+
+ mvebu_v7_pmsu_idle_exit();
+
+ set_cpu_coherent();
+
+ cpu_pm_exit();
+
+ return 0;
+}
+
+static const struct platform_suspend_ops mvebu_pm_ops = {
+ .enter = mvebu_pm_enter,
+ .valid = suspend_valid_only_mem,
+};
+
+int mvebu_pm_init(void (*board_pm_enter)(void __iomem *sdram_reg, u32 srcmd))
+{
+ struct device_node *np;
+ struct resource res;
+
+ if (!of_machine_is_compatible("marvell,armadaxp"))
+ return -ENODEV;
+
+ np = of_find_compatible_node(NULL, NULL,
+ "marvell,armada-xp-sdram-controller");
+ if (!np)
+ return -ENODEV;
+
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ if (!request_mem_region(res.start, resource_size(&res),
+ np->full_name)) {
+ of_node_put(np);
+ return -EBUSY;
+ }
+
+ sdram_ctrl = ioremap(res.start, resource_size(&res));
+ if (!sdram_ctrl) {
+ release_mem_region(res.start, resource_size(&res));
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
+ of_node_put(np);
+
+ mvebu_board_pm_enter = board_pm_enter;
+
+ suspend_set_ops(&mvebu_pm_ops);
+
+ return 0;
+}
diff --git a/arch/arm/mach-mvebu/pmsu.h b/arch/arm/mach-mvebu/pmsu.h
index 6b58c1f..a7c242d 100644
--- a/arch/arm/mach-mvebu/pmsu.h
+++ b/arch/arm/mach-mvebu/pmsu.h
@@ -17,5 +17,6 @@ int mvebu_setup_boot_addr_wa(unsigned int crypto_eng_target,
phys_addr_t resume_addr_reg);
void mvebu_v7_pmsu_idle_exit(void);
+void armada_370_xp_cpu_resume(void);
#endif /* __MACH_370_XP_PMSU_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/common.h | 2 +
arch/arm/mach-mvebu/pm.c | 218 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-mvebu/pmsu.h | 1 +
4 files changed, 222 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/pm.c
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index e24136b..e2bd96f 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -7,7 +7,7 @@ CFLAGS_pmsu.o := -march=armv7-a
obj-$(CONFIG_MACH_MVEBU_ANY) += system-controller.o mvebu-soc-id.o
ifeq ($(CONFIG_MACH_MVEBU_V7),y)
-obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o
+obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o pm.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o platsmp-a9.o headsmp-a9.o
endif
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 3ccb40c..3e0aca1 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -25,4 +25,6 @@ int mvebu_system_controller_get_soc_id(u32 *dev, u32 *rev);
void __iomem *mvebu_get_scu_base(void);
+int mvebu_pm_init(void (*board_pm_enter)(void __iomem *sdram_reg, u32 srcmd));
+
#endif
diff --git a/arch/arm/mach-mvebu/pm.c b/arch/arm/mach-mvebu/pm.c
new file mode 100644
index 0000000..6573a8f
--- /dev/null
+++ b/arch/arm/mach-mvebu/pm.c
@@ -0,0 +1,218 @@
+/*
+ * Suspend/resume support. Currently supporting Armada XP only.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * 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.
+ */
+
+#include <linux/cpu_pm.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mbus.h>
+#include <linux/of_address.h>
+#include <linux/suspend.h>
+#include <asm/cacheflush.h>
+#include <asm/outercache.h>
+#include <asm/suspend.h>
+
+#include "coherency.h"
+#include "pmsu.h"
+
+#define SDRAM_CONFIG_OFFS 0x0
+#define SDRAM_CONFIG_SR_MODE_BIT BIT(24)
+#define SDRAM_OPERATION_OFFS 0x18
+#define SDRAM_OPERATION_SELF_REFRESH 0x7
+#define SDRAM_DLB_EVICTION_OFFS 0x30c
+#define SDRAM_DLB_EVICTION_THRESHOLD_MASK 0xff
+
+static void (*mvebu_board_pm_enter)(void __iomem *sdram_reg, u32 srcmd);
+static void __iomem *sdram_ctrl;
+
+static int mvebu_pm_powerdown(unsigned long data)
+{
+ u32 reg, srcmd;
+
+ flush_cache_all();
+ outer_flush_all();
+
+ /*
+ * Issue a Data Synchronization Barrier instruction to ensure
+ * that all state saving has been completed.
+ */
+ dsb();
+
+ /* Flush the DLB and wait ~7 usec */
+ reg = readl(sdram_ctrl + SDRAM_DLB_EVICTION_OFFS);
+ reg &= ~SDRAM_DLB_EVICTION_THRESHOLD_MASK;
+ writel(reg, sdram_ctrl + SDRAM_DLB_EVICTION_OFFS);
+
+ udelay(7);
+
+ /* Set DRAM in battery backup mode */
+ reg = readl(sdram_ctrl + SDRAM_CONFIG_OFFS);
+ reg &= ~SDRAM_CONFIG_SR_MODE_BIT;
+ writel(reg, sdram_ctrl + SDRAM_CONFIG_OFFS);
+
+ /* Prepare to go to self-refresh */
+
+ srcmd = readl(sdram_ctrl + SDRAM_OPERATION_OFFS);
+ srcmd &= ~0x1F;
+ srcmd |= SDRAM_OPERATION_SELF_REFRESH;
+
+ mvebu_board_pm_enter(sdram_ctrl + SDRAM_OPERATION_OFFS, srcmd);
+
+ return 0;
+}
+
+#define BOOT_INFO_ADDR 0x3000
+#define BOOT_MAGIC_WORD 0xdeadb002
+#define BOOT_MAGIC_LIST_END 0xffffffff
+
+/*
+ * Those registers are accessed before switching the internal register
+ * base, which is why we hardcode the 0xd0000000 base address, the one
+ * used by the SoC out of reset.
+ */
+#define MBUS_WINDOW_12_CTRL 0xd00200b0
+#define MBUS_INTERNAL_REG_ADDRESS 0xd0020080
+
+#define SDRAM_WIN_BASE_REG(x) (0x20180 + (0x8*x))
+#define SDRAM_WIN_CTRL_REG(x) (0x20184 + (0x8*x))
+
+static phys_addr_t mvebu_internal_reg_base(void)
+{
+ struct device_node *np;
+ __be32 in_addr[2];
+
+ np = of_find_node_by_name(NULL, "internal-regs");
+ BUG_ON(!np);
+
+ /*
+ * Ask the DT what is the internal register address on this
+ * platform. In the mvebu-mbus DT binding, 0xf0010000
+ * corresponds to the internal register window.
+ */
+ in_addr[0] = cpu_to_be32(0xf0010000);
+ in_addr[1] = 0x0;
+
+ return of_translate_address(np, in_addr);
+}
+
+static void mvebu_pm_store_bootinfo(void)
+{
+ u32 *store_addr;
+ phys_addr_t resume_pc;
+
+ store_addr = phys_to_virt(BOOT_INFO_ADDR);
+ resume_pc = virt_to_phys(armada_370_xp_cpu_resume);
+
+ /*
+ * The bootloader expects the first two words to be a magic
+ * value (BOOT_MAGIC_WORD), followed by the address of the
+ * resume code to jump to. Then, it expects a sequence of
+ * (address, value) pairs, which can be used to restore the
+ * value of certain registers. This sequence must end with the
+ * BOOT_MAGIC_LIST_END magic value.
+ */
+
+ writel(BOOT_MAGIC_WORD, store_addr++);
+ writel(resume_pc, store_addr++);
+
+ /*
+ * Some platforms remap their internal register base address
+ * to 0xf1000000. However, out of reset, window 12 starts at
+ * 0xf0000000 and ends at 0xf7ffffff, which would overlap with
+ * the internal registers. Therefore, disable window 12.
+ */
+ writel(MBUS_WINDOW_12_CTRL, store_addr++);
+ writel(0x0, store_addr++);
+
+ /*
+ * Set the internal register base address to the value
+ * expected by Linux, as read from the Device Tree.
+ */
+ writel(MBUS_INTERNAL_REG_ADDRESS, store_addr++);
+ writel(mvebu_internal_reg_base(), store_addr++);
+
+ /*
+ * Ask the mvebu-mbus driver to store the SDRAM window
+ * configuration, which has to be restored by the bootloader
+ * before re-entering the kernel on resume.
+ */
+ store_addr += mvebu_mbus_save_cpu_target(store_addr);
+
+ writel(BOOT_MAGIC_LIST_END, store_addr);
+}
+
+static int mvebu_pm_enter(suspend_state_t state)
+{
+ if (state != PM_SUSPEND_MEM)
+ return -EINVAL;
+
+ cpu_pm_enter();
+
+ mvebu_pm_store_bootinfo();
+ cpu_suspend(0, mvebu_pm_powerdown);
+
+ outer_resume();
+
+ mvebu_v7_pmsu_idle_exit();
+
+ set_cpu_coherent();
+
+ cpu_pm_exit();
+
+ return 0;
+}
+
+static const struct platform_suspend_ops mvebu_pm_ops = {
+ .enter = mvebu_pm_enter,
+ .valid = suspend_valid_only_mem,
+};
+
+int mvebu_pm_init(void (*board_pm_enter)(void __iomem *sdram_reg, u32 srcmd))
+{
+ struct device_node *np;
+ struct resource res;
+
+ if (!of_machine_is_compatible("marvell,armadaxp"))
+ return -ENODEV;
+
+ np = of_find_compatible_node(NULL, NULL,
+ "marvell,armada-xp-sdram-controller");
+ if (!np)
+ return -ENODEV;
+
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ if (!request_mem_region(res.start, resource_size(&res),
+ np->full_name)) {
+ of_node_put(np);
+ return -EBUSY;
+ }
+
+ sdram_ctrl = ioremap(res.start, resource_size(&res));
+ if (!sdram_ctrl) {
+ release_mem_region(res.start, resource_size(&res));
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
+ of_node_put(np);
+
+ mvebu_board_pm_enter = board_pm_enter;
+
+ suspend_set_ops(&mvebu_pm_ops);
+
+ return 0;
+}
diff --git a/arch/arm/mach-mvebu/pmsu.h b/arch/arm/mach-mvebu/pmsu.h
index 6b58c1f..a7c242d 100644
--- a/arch/arm/mach-mvebu/pmsu.h
+++ b/arch/arm/mach-mvebu/pmsu.h
@@ -17,5 +17,6 @@ int mvebu_setup_boot_addr_wa(unsigned int crypto_eng_target,
phys_addr_t resume_addr_reg);
void mvebu_v7_pmsu_idle_exit(void);
+void armada_370_xp_cpu_resume(void);
#endif /* __MACH_370_XP_PMSU_H */
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 10/16] ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
When going out of suspend to RAM, the Marvell EBU platforms go through
the bootloader, which re-configures the DRAM controller. To achieve
this, the bootloader executes a piece of code called the "DDR3
training code". It does some reads/writes to the memory to find out
the optimal timings for the memory chip being used.
This has the nasty side effect that the first 10 KB of each DRAM
chip-select are overwritten by the bootloader when exiting the suspend
to RAM state.
Therefore, this commit implements the ->reserve() hook for the 'struct
machine_desc' used on Armada XP, to reserve the 10 KB of each DRAM
chip-select using the memblock API.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/mach-mvebu/board-v7.c | 51 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 6478626..bc52231 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -16,10 +16,12 @@
#include <linux/init.h>
#include <linux/clk-provider.h>
#include <linux/of_address.h>
+#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <linux/io.h>
#include <linux/clocksource.h>
#include <linux/dma-mapping.h>
+#include <linux/memblock.h>
#include <linux/mbus.h>
#include <linux/signal.h>
#include <linux/slab.h>
@@ -57,6 +59,54 @@ void __iomem *mvebu_get_scu_base(void)
}
/*
+ * When returning from suspend, the platform goes through the
+ * bootloader, which executes its DDR3 training code. This code has
+ * the unfortunate idea of using the first 10 KB of each DRAM bank to
+ * exercise the RAM and calculate the optimal timings. Therefore, this
+ * area of RAM is overwritten, and shouldn't be used by the kernel if
+ * suspend/resume is supported.
+ */
+
+#ifdef CONFIG_SUSPEND
+#define MVEBU_DDR_TRAINING_AREA_SZ (10 * SZ_1K)
+static int __init mvebu_scan_mem(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ const __be32 *reg, *endp;
+ int l;
+
+ if (type == NULL || strcmp(type, "memory"))
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
+ if (reg == NULL)
+ reg = of_get_flat_dt_prop(node, "reg", &l);
+ if (reg == NULL)
+ return 0;
+
+ endp = reg + (l / sizeof(__be32));
+ while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+ u64 base, size;
+
+ base = dt_mem_next_cell(dt_root_addr_cells, ®);
+ size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ memblock_reserve(base, MVEBU_DDR_TRAINING_AREA_SZ);
+ }
+
+ return 0;
+}
+
+static void __init mvebu_memblock_reserve(void)
+{
+ of_scan_flat_dt(mvebu_scan_mem, NULL);
+}
+#else
+static void __init mvebu_memblock_reserve(void) {}
+#endif
+
+/*
* Early versions of Armada 375 SoC have a bug where the BootROM
* leaves an external data abort pending. The kernel is hit by this
* data abort as soon as it enters userspace, because it unmasks the
@@ -210,6 +260,7 @@ DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.init_machine = mvebu_dt_init,
.init_irq = mvebu_init_irq,
.restart = mvebu_restart,
+ .reserve = mvebu_memblock_reserve,
.dt_compat = armada_370_xp_dt_compat,
MACHINE_END
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 10/16] ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
When going out of suspend to RAM, the Marvell EBU platforms go through
the bootloader, which re-configures the DRAM controller. To achieve
this, the bootloader executes a piece of code called the "DDR3
training code". It does some reads/writes to the memory to find out
the optimal timings for the memory chip being used.
This has the nasty side effect that the first 10 KB of each DRAM
chip-select are overwritten by the bootloader when exiting the suspend
to RAM state.
Therefore, this commit implements the ->reserve() hook for the 'struct
machine_desc' used on Armada XP, to reserve the 10 KB of each DRAM
chip-select using the memblock API.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/board-v7.c | 51 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 6478626..bc52231 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -16,10 +16,12 @@
#include <linux/init.h>
#include <linux/clk-provider.h>
#include <linux/of_address.h>
+#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <linux/io.h>
#include <linux/clocksource.h>
#include <linux/dma-mapping.h>
+#include <linux/memblock.h>
#include <linux/mbus.h>
#include <linux/signal.h>
#include <linux/slab.h>
@@ -57,6 +59,54 @@ void __iomem *mvebu_get_scu_base(void)
}
/*
+ * When returning from suspend, the platform goes through the
+ * bootloader, which executes its DDR3 training code. This code has
+ * the unfortunate idea of using the first 10 KB of each DRAM bank to
+ * exercise the RAM and calculate the optimal timings. Therefore, this
+ * area of RAM is overwritten, and shouldn't be used by the kernel if
+ * suspend/resume is supported.
+ */
+
+#ifdef CONFIG_SUSPEND
+#define MVEBU_DDR_TRAINING_AREA_SZ (10 * SZ_1K)
+static int __init mvebu_scan_mem(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ const __be32 *reg, *endp;
+ int l;
+
+ if (type == NULL || strcmp(type, "memory"))
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
+ if (reg == NULL)
+ reg = of_get_flat_dt_prop(node, "reg", &l);
+ if (reg == NULL)
+ return 0;
+
+ endp = reg + (l / sizeof(__be32));
+ while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+ u64 base, size;
+
+ base = dt_mem_next_cell(dt_root_addr_cells, ®);
+ size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ memblock_reserve(base, MVEBU_DDR_TRAINING_AREA_SZ);
+ }
+
+ return 0;
+}
+
+static void __init mvebu_memblock_reserve(void)
+{
+ of_scan_flat_dt(mvebu_scan_mem, NULL);
+}
+#else
+static void __init mvebu_memblock_reserve(void) {}
+#endif
+
+/*
* Early versions of Armada 375 SoC have a bug where the BootROM
* leaves an external data abort pending. The kernel is hit by this
* data abort as soon as it enters userspace, because it unmasks the
@@ -210,6 +260,7 @@ DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.init_machine = mvebu_dt_init,
.init_irq = mvebu_init_irq,
.restart = mvebu_restart,
+ .reserve = mvebu_memblock_reserve,
.dt_compat = armada_370_xp_dt_compat,
MACHINE_END
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 11/16] ARM: mvebu: Armada XP GP specific suspend/resume code
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
On the Armada XP GP platform, entering suspend to RAM state is
triggering by talking to an external PIC micro-controller connected to
the SoC using 3 GPIOs. There is then a small magic sequence of GPIO
toggling that needs to be used to tell the PIC to turn off the SoC.
The code uses the Device Tree to find out which GPIOs are used to
connect to the PIC micro-controller, and then registers its
mvebu_armada_xp_gp_pm_enter() callback to the SoC-level PM code. The
SoC PM code will call back into this registered function at the very
end of the suspend procedure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/pm-board.c | 141 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/pm-board.c
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index e2bd96f..b4f0149 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -7,7 +7,7 @@ CFLAGS_pmsu.o := -march=armv7-a
obj-$(CONFIG_MACH_MVEBU_ANY) += system-controller.o mvebu-soc-id.o
ifeq ($(CONFIG_MACH_MVEBU_V7),y)
-obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o pm.o
+obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o pm.o pm-board.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o platsmp-a9.o headsmp-a9.o
endif
diff --git a/arch/arm/mach-mvebu/pm-board.c b/arch/arm/mach-mvebu/pm-board.c
new file mode 100644
index 0000000..6dfd4ab
--- /dev/null
+++ b/arch/arm/mach-mvebu/pm-board.c
@@ -0,0 +1,141 @@
+/*
+ * Board-level suspend/resume support.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * 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.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_gpio.h>
+#include <linux/slab.h>
+#include "common.h"
+
+#define ARMADA_XP_GP_PIC_NR_GPIOS 3
+
+static void __iomem *gpio_ctrl;
+static int pic_gpios[ARMADA_XP_GP_PIC_NR_GPIOS];
+static int pic_raw_gpios[ARMADA_XP_GP_PIC_NR_GPIOS];
+
+static void mvebu_armada_xp_gp_pm_enter(void __iomem *sdram_reg, u32 srcmd)
+{
+ u32 reg, ackcmd;
+ int i;
+
+ /* Put 001 as value on the GPIOs */
+ reg = readl(gpio_ctrl);
+ for (i = 0; i < ARMADA_XP_GP_PIC_NR_GPIOS; i++)
+ reg &= ~BIT(pic_raw_gpios[i]);
+ reg |= BIT(pic_raw_gpios[0]);
+ writel(reg, gpio_ctrl);
+
+ /* Prepare writing 111 to the GPIOs */
+ ackcmd = readl(gpio_ctrl);
+ for (i = 0; i < ARMADA_XP_GP_PIC_NR_GPIOS; i++)
+ ackcmd |= BIT(pic_raw_gpios[i]);
+
+ /*
+ * Wait a while, the PIC needs quite a bit of time between the
+ * two GPIO commands.
+ */
+ mdelay(3000);
+
+ asm volatile (
+ /* Align to a cache line */
+ ".balign 32\n\t"
+
+ /* Enter self refresh */
+ "str %[srcmd], [%[sdram_reg]]\n\t"
+
+ /*
+ * Wait 100 cycles for DDR to enter self refresh, by
+ * doing 50 times two instructions.
+ */
+ "mov r1, #50\n\t"
+ "1: subs r1, r1, #1\n\t"
+ "bne 1b\n\t"
+
+ /* Issue the command ACK */
+ "str %[ackcmd], [%[gpio_ctrl]]\n\t"
+
+ /* Trap the processor */
+ "b .\n\t"
+ : : [srcmd] "r" (srcmd), [sdram_reg] "r" (sdram_reg),
+ [ackcmd] "r" (ackcmd), [gpio_ctrl] "r" (gpio_ctrl) : "r1");
+}
+
+static int mvebu_armada_xp_gp_pm_init(void)
+{
+ struct device_node *np;
+ struct device_node *gpio_ctrl_np;
+ int ret = 0, i;
+
+ if (!of_machine_is_compatible("marvell,axp-gp"))
+ return -ENODEV;
+
+ np = of_find_node_by_name(NULL, "pm_pic");
+ if (!np)
+ return -ENODEV;
+
+ for (i = 0; i < ARMADA_XP_GP_PIC_NR_GPIOS; i++) {
+ char *name;
+ struct of_phandle_args args;
+
+ pic_gpios[i] = of_get_named_gpio(np, "ctrl-gpios", i);
+ if (pic_gpios[i] < 0) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ name = kasprintf(GFP_KERNEL, "pic-pin%d", i);
+ if (!name) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = gpio_request(pic_gpios[i], name);
+ if (ret < 0) {
+ kfree(name);
+ goto out;
+ }
+
+ ret = gpio_direction_output(pic_gpios[i], 0);
+ if (ret < 0) {
+ gpio_free(pic_gpios[i]);
+ kfree(name);
+ goto out;
+ }
+
+ ret = of_parse_phandle_with_fixed_args(np, "ctrl-gpios", 2,
+ i, &args);
+ if (ret < 0) {
+ gpio_free(pic_gpios[i]);
+ kfree(name);
+ goto out;
+ }
+
+ gpio_ctrl_np = args.np;
+ pic_raw_gpios[i] = args.args[0];
+ }
+
+ gpio_ctrl = of_iomap(gpio_ctrl_np, 0);
+ if (!gpio_ctrl)
+ return -ENOMEM;
+
+ mvebu_pm_init(mvebu_armada_xp_gp_pm_enter);
+
+out:
+ of_node_put(np);
+ return ret;
+}
+
+late_initcall(mvebu_armada_xp_gp_pm_init);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 11/16] ARM: mvebu: Armada XP GP specific suspend/resume code
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
On the Armada XP GP platform, entering suspend to RAM state is
triggering by talking to an external PIC micro-controller connected to
the SoC using 3 GPIOs. There is then a small magic sequence of GPIO
toggling that needs to be used to tell the PIC to turn off the SoC.
The code uses the Device Tree to find out which GPIOs are used to
connect to the PIC micro-controller, and then registers its
mvebu_armada_xp_gp_pm_enter() callback to the SoC-level PM code. The
SoC PM code will call back into this registered function at the very
end of the suspend procedure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/pm-board.c | 141 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/pm-board.c
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index e2bd96f..b4f0149 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -7,7 +7,7 @@ CFLAGS_pmsu.o := -march=armv7-a
obj-$(CONFIG_MACH_MVEBU_ANY) += system-controller.o mvebu-soc-id.o
ifeq ($(CONFIG_MACH_MVEBU_V7),y)
-obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o pm.o
+obj-y += cpu-reset.o board-v7.o coherency.o coherency_ll.o pmsu.o pmsu_ll.o pm.o pm-board.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o platsmp-a9.o headsmp-a9.o
endif
diff --git a/arch/arm/mach-mvebu/pm-board.c b/arch/arm/mach-mvebu/pm-board.c
new file mode 100644
index 0000000..6dfd4ab
--- /dev/null
+++ b/arch/arm/mach-mvebu/pm-board.c
@@ -0,0 +1,141 @@
+/*
+ * Board-level suspend/resume support.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * 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.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_gpio.h>
+#include <linux/slab.h>
+#include "common.h"
+
+#define ARMADA_XP_GP_PIC_NR_GPIOS 3
+
+static void __iomem *gpio_ctrl;
+static int pic_gpios[ARMADA_XP_GP_PIC_NR_GPIOS];
+static int pic_raw_gpios[ARMADA_XP_GP_PIC_NR_GPIOS];
+
+static void mvebu_armada_xp_gp_pm_enter(void __iomem *sdram_reg, u32 srcmd)
+{
+ u32 reg, ackcmd;
+ int i;
+
+ /* Put 001 as value on the GPIOs */
+ reg = readl(gpio_ctrl);
+ for (i = 0; i < ARMADA_XP_GP_PIC_NR_GPIOS; i++)
+ reg &= ~BIT(pic_raw_gpios[i]);
+ reg |= BIT(pic_raw_gpios[0]);
+ writel(reg, gpio_ctrl);
+
+ /* Prepare writing 111 to the GPIOs */
+ ackcmd = readl(gpio_ctrl);
+ for (i = 0; i < ARMADA_XP_GP_PIC_NR_GPIOS; i++)
+ ackcmd |= BIT(pic_raw_gpios[i]);
+
+ /*
+ * Wait a while, the PIC needs quite a bit of time between the
+ * two GPIO commands.
+ */
+ mdelay(3000);
+
+ asm volatile (
+ /* Align to a cache line */
+ ".balign 32\n\t"
+
+ /* Enter self refresh */
+ "str %[srcmd], [%[sdram_reg]]\n\t"
+
+ /*
+ * Wait 100 cycles for DDR to enter self refresh, by
+ * doing 50 times two instructions.
+ */
+ "mov r1, #50\n\t"
+ "1: subs r1, r1, #1\n\t"
+ "bne 1b\n\t"
+
+ /* Issue the command ACK */
+ "str %[ackcmd], [%[gpio_ctrl]]\n\t"
+
+ /* Trap the processor */
+ "b .\n\t"
+ : : [srcmd] "r" (srcmd), [sdram_reg] "r" (sdram_reg),
+ [ackcmd] "r" (ackcmd), [gpio_ctrl] "r" (gpio_ctrl) : "r1");
+}
+
+static int mvebu_armada_xp_gp_pm_init(void)
+{
+ struct device_node *np;
+ struct device_node *gpio_ctrl_np;
+ int ret = 0, i;
+
+ if (!of_machine_is_compatible("marvell,axp-gp"))
+ return -ENODEV;
+
+ np = of_find_node_by_name(NULL, "pm_pic");
+ if (!np)
+ return -ENODEV;
+
+ for (i = 0; i < ARMADA_XP_GP_PIC_NR_GPIOS; i++) {
+ char *name;
+ struct of_phandle_args args;
+
+ pic_gpios[i] = of_get_named_gpio(np, "ctrl-gpios", i);
+ if (pic_gpios[i] < 0) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ name = kasprintf(GFP_KERNEL, "pic-pin%d", i);
+ if (!name) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = gpio_request(pic_gpios[i], name);
+ if (ret < 0) {
+ kfree(name);
+ goto out;
+ }
+
+ ret = gpio_direction_output(pic_gpios[i], 0);
+ if (ret < 0) {
+ gpio_free(pic_gpios[i]);
+ kfree(name);
+ goto out;
+ }
+
+ ret = of_parse_phandle_with_fixed_args(np, "ctrl-gpios", 2,
+ i, &args);
+ if (ret < 0) {
+ gpio_free(pic_gpios[i]);
+ kfree(name);
+ goto out;
+ }
+
+ gpio_ctrl_np = args.np;
+ pic_raw_gpios[i] = args.args[0];
+ }
+
+ gpio_ctrl = of_iomap(gpio_ctrl_np, 0);
+ if (!gpio_ctrl)
+ return -ENOMEM;
+
+ mvebu_pm_init(mvebu_armada_xp_gp_pm_enter);
+
+out:
+ of_node_put(np);
+ return ret;
+}
+
+late_initcall(mvebu_armada_xp_gp_pm_init);
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 12/16] ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
The armada_370_xp_cpu_resume() until now was used only as the function
called by the SoC when returning from a deep idle state (as used in
cpuidle, or when the CPU is brought offline using CPU hotplug).
However, it is now also used when exiting the suspend to RAM state. In
this case, it is the bootloader that calls back into this function,
with the MMU left enabled by the BootROM. Having the MMU enabled when
entering this function confuses the kerrnel because we are not using
the kernel page tables at this point, but in other mvebu functions we
use the information on whether the MMU is enabled or not to find out
whether we should talk to the coherency fabric using a physical
address or a virtual address. To fix that, we simply disable the MMU
when entering this function, so that the kernel is in an expected
situation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/mach-mvebu/pmsu_ll.S | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_ll.S
index a945756..ae7e6b0 100644
--- a/arch/arm/mach-mvebu/pmsu_ll.S
+++ b/arch/arm/mach-mvebu/pmsu_ll.S
@@ -18,6 +18,14 @@
*/
ENTRY(armada_370_xp_cpu_resume)
ARM_BE8(setend be ) @ go BE8 if entered LE
+ /*
+ * Disable the MMU that might have been enabled in BootROM if
+ * this code is used in the resume path of a suspend/resume
+ * cycle.
+ */
+ mrc p15, 0, r1, c1, c0, 0
+ bic r1, #1
+ mcr p15, 0, r1, c1, c0, 0
bl ll_add_cpu_to_smp_group
bl ll_enable_coherency
b cpu_resume
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 12/16] ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
The armada_370_xp_cpu_resume() until now was used only as the function
called by the SoC when returning from a deep idle state (as used in
cpuidle, or when the CPU is brought offline using CPU hotplug).
However, it is now also used when exiting the suspend to RAM state. In
this case, it is the bootloader that calls back into this function,
with the MMU left enabled by the BootROM. Having the MMU enabled when
entering this function confuses the kerrnel because we are not using
the kernel page tables at this point, but in other mvebu functions we
use the information on whether the MMU is enabled or not to find out
whether we should talk to the coherency fabric using a physical
address or a virtual address. To fix that, we simply disable the MMU
when entering this function, so that the kernel is in an expected
situation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/pmsu_ll.S | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_ll.S
index a945756..ae7e6b0 100644
--- a/arch/arm/mach-mvebu/pmsu_ll.S
+++ b/arch/arm/mach-mvebu/pmsu_ll.S
@@ -18,6 +18,14 @@
*/
ENTRY(armada_370_xp_cpu_resume)
ARM_BE8(setend be ) @ go BE8 if entered LE
+ /*
+ * Disable the MMU that might have been enabled in BootROM if
+ * this code is used in the resume path of a suspend/resume
+ * cycle.
+ */
+ mrc p15, 0, r1, c1, c0, 0
+ bic r1, #1
+ mcr p15, 0, r1, c1, c0, 0
bl ll_add_cpu_to_smp_group
bl ll_enable_coherency
b cpu_resume
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 13/16] ARM: mvebu: synchronize secondary CPU clocks on resume
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
The Armada XP has multiple cores clocked by independent clocks. The
SMP startup code contains a function called set_secondary_cpus_clock()
called in armada_xp_smp_prepare_cpus() to ensure the clocks of the
secondary CPUs match the clock of the boot CPU.
With the introduction of suspend/resume, this operation is no longer
needed when booting the system, but also when existing the suspend to
RAM state. Therefore this commit reworks a bit the logic: instead of
configuring the clock of all secondary CPUs in
armada_xp_smp_prepare_cpus(), we do it on a per-secondary CPU basis in
armada_xp_boot_secondary(), as this function gets called when existing
suspend to RAM for each secondary CPU.
Since the function now only takes care of one CPU, we rename it from
set_secondary_cpus_clock() to set_secondary_cpu_clock(), and it looses
its __init marker, as it is now used beyond the system initialization.
Note that we can't use smp_processor_id() directly, because when
exiting from suspend to RAM, the code is apparently executed with
preemption enabled, so smp_processor_id() is not happy (prints a
warning). We therefore switch to using get_cpu()/put_cpu(), even
though we pretty much have the guarantee that the code starting the
secondary CPUs is going to run on the boot CPU and will not be
migrated.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/mach-mvebu/platsmp.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 895dc37..e65e69a 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -33,7 +33,7 @@
#define AXP_BOOTROM_BASE 0xfff00000
#define AXP_BOOTROM_SIZE 0x100000
-static struct clk *__init get_cpu_clk(int cpu)
+static struct clk *get_cpu_clk(int cpu)
{
struct clk *cpu_clk;
struct device_node *np = of_get_cpu_node(cpu, NULL);
@@ -46,29 +46,28 @@ static struct clk *__init get_cpu_clk(int cpu)
return cpu_clk;
}
-static void __init set_secondary_cpus_clock(void)
+static void set_secondary_cpu_clock(unsigned int cpu)
{
- int thiscpu, cpu;
+ int thiscpu;
unsigned long rate;
struct clk *cpu_clk;
- thiscpu = smp_processor_id();
+ thiscpu = get_cpu();
+
cpu_clk = get_cpu_clk(thiscpu);
if (!cpu_clk)
- return;
+ goto out;
clk_prepare_enable(cpu_clk);
rate = clk_get_rate(cpu_clk);
- /* set all the other CPU clk to the same rate than the boot CPU */
- for_each_possible_cpu(cpu) {
- if (cpu == thiscpu)
- continue;
- cpu_clk = get_cpu_clk(cpu);
- if (!cpu_clk)
- return;
- clk_set_rate(cpu_clk, rate);
- clk_prepare_enable(cpu_clk);
- }
+ cpu_clk = get_cpu_clk(cpu);
+ if (!cpu_clk)
+ goto out;
+ clk_set_rate(cpu_clk, rate);
+ clk_prepare_enable(cpu_clk);
+
+out:
+ put_cpu();
}
static int armada_xp_boot_secondary(unsigned int cpu, struct task_struct *idle)
@@ -78,6 +77,7 @@ static int armada_xp_boot_secondary(unsigned int cpu, struct task_struct *idle)
pr_info("Booting CPU %d\n", cpu);
hw_cpu = cpu_logical_map(cpu);
+ set_secondary_cpu_clock(hw_cpu);
mvebu_pmsu_set_cpu_boot_addr(hw_cpu, armada_xp_secondary_startup);
/*
@@ -126,7 +126,6 @@ static void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
struct resource res;
int err;
- set_secondary_cpus_clock();
flush_cache_all();
set_cpu_coherent();
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 13/16] ARM: mvebu: synchronize secondary CPU clocks on resume
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
The Armada XP has multiple cores clocked by independent clocks. The
SMP startup code contains a function called set_secondary_cpus_clock()
called in armada_xp_smp_prepare_cpus() to ensure the clocks of the
secondary CPUs match the clock of the boot CPU.
With the introduction of suspend/resume, this operation is no longer
needed when booting the system, but also when existing the suspend to
RAM state. Therefore this commit reworks a bit the logic: instead of
configuring the clock of all secondary CPUs in
armada_xp_smp_prepare_cpus(), we do it on a per-secondary CPU basis in
armada_xp_boot_secondary(), as this function gets called when existing
suspend to RAM for each secondary CPU.
Since the function now only takes care of one CPU, we rename it from
set_secondary_cpus_clock() to set_secondary_cpu_clock(), and it looses
its __init marker, as it is now used beyond the system initialization.
Note that we can't use smp_processor_id() directly, because when
exiting from suspend to RAM, the code is apparently executed with
preemption enabled, so smp_processor_id() is not happy (prints a
warning). We therefore switch to using get_cpu()/put_cpu(), even
though we pretty much have the guarantee that the code starting the
secondary CPUs is going to run on the boot CPU and will not be
migrated.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/platsmp.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 895dc37..e65e69a 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -33,7 +33,7 @@
#define AXP_BOOTROM_BASE 0xfff00000
#define AXP_BOOTROM_SIZE 0x100000
-static struct clk *__init get_cpu_clk(int cpu)
+static struct clk *get_cpu_clk(int cpu)
{
struct clk *cpu_clk;
struct device_node *np = of_get_cpu_node(cpu, NULL);
@@ -46,29 +46,28 @@ static struct clk *__init get_cpu_clk(int cpu)
return cpu_clk;
}
-static void __init set_secondary_cpus_clock(void)
+static void set_secondary_cpu_clock(unsigned int cpu)
{
- int thiscpu, cpu;
+ int thiscpu;
unsigned long rate;
struct clk *cpu_clk;
- thiscpu = smp_processor_id();
+ thiscpu = get_cpu();
+
cpu_clk = get_cpu_clk(thiscpu);
if (!cpu_clk)
- return;
+ goto out;
clk_prepare_enable(cpu_clk);
rate = clk_get_rate(cpu_clk);
- /* set all the other CPU clk to the same rate than the boot CPU */
- for_each_possible_cpu(cpu) {
- if (cpu == thiscpu)
- continue;
- cpu_clk = get_cpu_clk(cpu);
- if (!cpu_clk)
- return;
- clk_set_rate(cpu_clk, rate);
- clk_prepare_enable(cpu_clk);
- }
+ cpu_clk = get_cpu_clk(cpu);
+ if (!cpu_clk)
+ goto out;
+ clk_set_rate(cpu_clk, rate);
+ clk_prepare_enable(cpu_clk);
+
+out:
+ put_cpu();
}
static int armada_xp_boot_secondary(unsigned int cpu, struct task_struct *idle)
@@ -78,6 +77,7 @@ static int armada_xp_boot_secondary(unsigned int cpu, struct task_struct *idle)
pr_info("Booting CPU %d\n", cpu);
hw_cpu = cpu_logical_map(cpu);
+ set_secondary_cpu_clock(hw_cpu);
mvebu_pmsu_set_cpu_boot_addr(hw_cpu, armada_xp_secondary_startup);
/*
@@ -126,7 +126,6 @@ static void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
struct resource res;
int err;
- set_secondary_cpus_clock();
flush_cache_all();
set_cpu_coherent();
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 14/16] ARM: mvebu: add suspend/resume DT information for Armada XP GP
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
This commit improves the Armada XP GP Device Tree description to
describe the 3 GPIOs that are used to connect the SoC to the PIC
micro-controller that we talk to shutdown the SoC when entering
suspend to RAM.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-xp-gp.dts | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 0478c55..ea86736 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -23,6 +23,7 @@
*/
/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
#include "armada-xp-mv78460.dtsi"
/ {
@@ -48,6 +49,14 @@
<0x00000001 0x00000000 0x00000001 0x00000000>;
};
+ cpus {
+ pm_pic {
+ ctrl-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>,
+ <&gpio0 17 GPIO_ACTIVE_LOW>,
+ <&gpio0 18 GPIO_ACTIVE_LOW>;
+ };
+ };
+
soc {
ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
@@ -115,7 +124,15 @@
serial@12300 {
status = "okay";
};
-
+ pinctrl {
+ pinctrl-0 = <&pic_pins>;
+ pinctrl-names = "default";
+ pic_pins: pic-pins-0 {
+ marvell,pins = "mpp16", "mpp17",
+ "mpp18";
+ marvell,function = "gpio";
+ };
+ };
sata@a0000 {
nr-ports = <2>;
status = "okay";
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 14/16] ARM: mvebu: add suspend/resume DT information for Armada XP GP
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
This commit improves the Armada XP GP Device Tree description to
describe the 3 GPIOs that are used to connect the SoC to the PIC
micro-controller that we talk to shutdown the SoC when entering
suspend to RAM.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-xp-gp.dts | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 0478c55..ea86736 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -23,6 +23,7 @@
*/
/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
#include "armada-xp-mv78460.dtsi"
/ {
@@ -48,6 +49,14 @@
<0x00000001 0x00000000 0x00000001 0x00000000>;
};
+ cpus {
+ pm_pic {
+ ctrl-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>,
+ <&gpio0 17 GPIO_ACTIVE_LOW>,
+ <&gpio0 18 GPIO_ACTIVE_LOW>;
+ };
+ };
+
soc {
ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
@@ -115,7 +124,15 @@
serial@12300 {
status = "okay";
};
-
+ pinctrl {
+ pinctrl-0 = <&pic_pins>;
+ pinctrl-names = "default";
+ pic_pins: pic-pins-0 {
+ marvell,pins = "mpp16", "mpp17",
+ "mpp18";
+ marvell,function = "gpio";
+ };
+ };
sata at a0000 {
nr-ports = <2>;
status = "okay";
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 15/16] ARM: mvebu: adjust mbus controller description on Armada 370/XP
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
In order to support suspend/resume on Armada XP, an additional set of
registers need to be described at the MBus controller level. This
commit therefore adjusts the Device Tree of the Armada 370/XP SoC to
include those registers in the MBus controller description;
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 83286ec..90dba78 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -180,7 +180,8 @@
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>,
+ <0x20250 0x8>;
};
mpic: interrupt-controller@20000 {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 15/16] ARM: mvebu: adjust mbus controller description on Armada 370/XP
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In order to support suspend/resume on Armada XP, an additional set of
registers need to be described at the MBus controller level. This
commit therefore adjusts the Device Tree of the Armada 370/XP SoC to
include those registers in the MBus controller description;
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 83286ec..90dba78 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -180,7 +180,8 @@
mbusc: mbus-controller at 20000 {
compatible = "marvell,mbus-controller";
- reg = <0x20000 0x100>, <0x20180 0x20>;
+ reg = <0x20000 0x100>, <0x20180 0x20>,
+ <0x20250 0x8>;
};
mpic: interrupt-controller at 20000 {
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 16/16] ARM: mvebu: add SDRAM controller description for Armada XP
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-21 16:00 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni
The suspend/resume sequence on Armada XP needs to modify a number of
registers in the SDRAM controller. Therefore, this commit updates the
Armada XP Device Tree description to include the SDRAM controller
Device Tree node.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/armada-xp.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index bff9f6c..2be244a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -35,6 +35,11 @@
};
internal-regs {
+ sdramc@1400 {
+ compatible = "marvell,armada-xp-sdram-controller";
+ reg = <0x1400 0x500>;
+ };
+
L2: l2-cache {
compatible = "marvell,aurora-system-cache";
reg = <0x08000 0x1000>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 66+ messages in thread
* [PATCHv3 16/16] ARM: mvebu: add SDRAM controller description for Armada XP
@ 2014-11-21 16:00 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
The suspend/resume sequence on Armada XP needs to modify a number of
registers in the SDRAM controller. Therefore, this commit updates the
Armada XP Device Tree description to include the SDRAM controller
Device Tree node.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-xp.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index bff9f6c..2be244a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -35,6 +35,11 @@
};
internal-regs {
+ sdramc at 1400 {
+ compatible = "marvell,armada-xp-sdram-controller";
+ reg = <0x1400 0x500>;
+ };
+
L2: l2-cache {
compatible = "marvell,aurora-system-cache";
reg = <0x08000 0x1000>;
--
2.1.0
^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-21 16:00 ` Thomas Petazzoni
@ 2014-11-21 16:41 ` Andrew Lunn
-1 siblings, 0 replies; 66+ messages in thread
From: Andrew Lunn @ 2014-11-21 16:41 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
> +static void mvebu_pm_store_bootinfo(void)
> +{
> + u32 *store_addr;
> + phys_addr_t resume_pc;
> +
> + store_addr = phys_to_virt(BOOT_INFO_ADDR);
> + resume_pc = virt_to_phys(armada_370_xp_cpu_resume);
> +
> + /*
> + * The bootloader expects the first two words to be a magic
> + * value (BOOT_MAGIC_WORD), followed by the address of the
> + * resume code to jump to. Then, it expects a sequence of
> + * (address, value) pairs, which can be used to restore the
> + * value of certain registers. This sequence must end with the
> + * BOOT_MAGIC_LIST_END magic value.
> + */
Hi Thomas
Is this a well defined mechanism supported by mainline uboot, barebox
etc. Or is it some Marvell extension to their uboot?
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-21 16:41 ` Andrew Lunn
0 siblings, 0 replies; 66+ messages in thread
From: Andrew Lunn @ 2014-11-21 16:41 UTC (permalink / raw)
To: linux-arm-kernel
> +static void mvebu_pm_store_bootinfo(void)
> +{
> + u32 *store_addr;
> + phys_addr_t resume_pc;
> +
> + store_addr = phys_to_virt(BOOT_INFO_ADDR);
> + resume_pc = virt_to_phys(armada_370_xp_cpu_resume);
> +
> + /*
> + * The bootloader expects the first two words to be a magic
> + * value (BOOT_MAGIC_WORD), followed by the address of the
> + * resume code to jump to. Then, it expects a sequence of
> + * (address, value) pairs, which can be used to restore the
> + * value of certain registers. This sequence must end with the
> + * BOOT_MAGIC_LIST_END magic value.
> + */
Hi Thomas
Is this a well defined mechanism supported by mainline uboot, barebox
etc. Or is it some Marvell extension to their uboot?
Thanks
Andrew
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-21 16:41 ` Andrew Lunn
@ 2014-11-21 16:59 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
Dear Andrew Lunn,
On Fri, 21 Nov 2014 17:41:42 +0100, Andrew Lunn wrote:
> > +static void mvebu_pm_store_bootinfo(void)
> > +{
> > + u32 *store_addr;
> > + phys_addr_t resume_pc;
> > +
> > + store_addr = phys_to_virt(BOOT_INFO_ADDR);
> > + resume_pc = virt_to_phys(armada_370_xp_cpu_resume);
> > +
> > + /*
> > + * The bootloader expects the first two words to be a magic
> > + * value (BOOT_MAGIC_WORD), followed by the address of the
> > + * resume code to jump to. Then, it expects a sequence of
> > + * (address, value) pairs, which can be used to restore the
> > + * value of certain registers. This sequence must end with the
> > + * BOOT_MAGIC_LIST_END magic value.
> > + */
>
> Hi Thomas
>
> 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.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-21 16:59 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-21 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Dear Andrew Lunn,
On Fri, 21 Nov 2014 17:41:42 +0100, Andrew Lunn wrote:
> > +static void mvebu_pm_store_bootinfo(void)
> > +{
> > + u32 *store_addr;
> > + phys_addr_t resume_pc;
> > +
> > + store_addr = phys_to_virt(BOOT_INFO_ADDR);
> > + resume_pc = virt_to_phys(armada_370_xp_cpu_resume);
> > +
> > + /*
> > + * The bootloader expects the first two words to be a magic
> > + * value (BOOT_MAGIC_WORD), followed by the address of the
> > + * resume code to jump to. Then, it expects a sequence of
> > + * (address, value) pairs, which can be used to restore the
> > + * value of certain registers. This sequence must end with the
> > + * BOOT_MAGIC_LIST_END magic value.
> > + */
>
> Hi Thomas
>
> 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.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-21 16:59 ` Thomas Petazzoni
@ 2014-11-21 17:20 ` Andrew Lunn
-1 siblings, 0 replies; 66+ messages in thread
From: Andrew Lunn @ 2014-11-21 17:20 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper, Sebastian Hesselbarth,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
> > Hi Thomas
> >
> > 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.
Ah, O.K. So i miss understood what you meant by bootloader. It is the
first stage boot loader as part of the BootROM that does this.
If i've got this wrong, probably others will as well. So could you
make the comments talk about BootROM bootloader?
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-21 17:20 ` Andrew Lunn
0 siblings, 0 replies; 66+ messages in thread
From: Andrew Lunn @ 2014-11-21 17:20 UTC (permalink / raw)
To: linux-arm-kernel
> > Hi Thomas
> >
> > 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.
Ah, O.K. So i miss understood what you meant by bootloader. It is the
first stage boot loader as part of the BootROM that does this.
If i've got this wrong, probably others will as well. So could you
make the comments talk about BootROM bootloader?
Thanks
Andrew
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-21 17:20 ` Andrew Lunn
@ 2014-11-22 0:50 ` Jason Cooper
-1 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-22 0:50 UTC (permalink / raw)
To: Andrew Lunn
Cc: Thomas Petazzoni, Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
On Fri, Nov 21, 2014 at 06:20:31PM +0100, Andrew Lunn wrote:
> > > Hi Thomas
> > >
> > > 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.
>
> Ah, O.K. So i miss understood what you meant by bootloader. It is the
> first stage boot loader as part of the BootROM that does this.
>
> If i've got this wrong, probably others will as well. So could you
> make the comments talk about BootROM bootloader?
No need to respin just for this, I'll quote Thomas' explanation in the
commit log.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-22 0:50 ` Jason Cooper
0 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-22 0:50 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Nov 21, 2014 at 06:20:31PM +0100, Andrew Lunn wrote:
> > > Hi Thomas
> > >
> > > 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.
>
> Ah, O.K. So i miss understood what you meant by bootloader. It is the
> first stage boot loader as part of the BootROM that does this.
>
> If i've got this wrong, probably others will as well. So could you
> make the comments talk about BootROM bootloader?
No need to respin just for this, I'll quote Thomas' explanation in the
commit log.
thx,
Jason.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-22 0:53 ` Jason Cooper
-1 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-22 0:53 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Russell King, stable
On Fri, Nov 21, 2014 at 04:59:59PM +0100, Thomas Petazzoni wrote:
> From: Nadav Haklai <nadavh@marvell.com>
>
> Under extremely rare conditions, in an MPCore node consisting of at
> least 3 CPUs, two CPUs trying to perform a STREX to data on the same
> shared cache line can enter a livelock situation.
>
> This patch enables the HW mechanism that overcomes the bug. This fixes
> the incorrect setup of the STREX backoff delay bit due to a wrong
> description in the specification.
>
> Note that enabling the STREX backoff delay mechanism is done by
> leaving the bit *cleared*, while the bit was currently being set by
> the proc-v7.S code.
>
> [Thomas: adapt to latest mainline, slightly reword the commit log, add
> stable markers.]
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: <stable@vger.kernel.org> # v3.8+
> Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
> Signed-off-by: Nadav Haklai <nadavh@marvell.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> This patch is submitted as part of the suspend/resume work, because
> the suspend/resume path is triggering this rare bug in a very
> reproducible fashion.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/mm/proc-v7.S | 2 --
> 1 file changed, 2 deletions(-)
Acked-by: Jason Cooper <jason@lakedaemon.net>
Please add to Russell's patch tracker.
thx,
Jason.
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay
@ 2014-11-22 0:53 ` Jason Cooper
0 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-22 0:53 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Nov 21, 2014 at 04:59:59PM +0100, Thomas Petazzoni wrote:
> From: Nadav Haklai <nadavh@marvell.com>
>
> Under extremely rare conditions, in an MPCore node consisting of at
> least 3 CPUs, two CPUs trying to perform a STREX to data on the same
> shared cache line can enter a livelock situation.
>
> This patch enables the HW mechanism that overcomes the bug. This fixes
> the incorrect setup of the STREX backoff delay bit due to a wrong
> description in the specification.
>
> Note that enabling the STREX backoff delay mechanism is done by
> leaving the bit *cleared*, while the bit was currently being set by
> the proc-v7.S code.
>
> [Thomas: adapt to latest mainline, slightly reword the commit log, add
> stable markers.]
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: <stable@vger.kernel.org> # v3.8+
> Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines")
> Signed-off-by: Nadav Haklai <nadavh@marvell.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> This patch is submitted as part of the suspend/resume work, because
> the suspend/resume path is triggering this rare bug in a very
> reproducible fashion.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/mm/proc-v7.S | 2 --
> 1 file changed, 2 deletions(-)
Acked-by: Jason Cooper <jason@lakedaemon.net>
Please add to Russell's patch tracker.
thx,
Jason.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 00/16] Suspend to RAM support for Armada XP
2014-11-21 15:59 ` Thomas Petazzoni
@ 2014-11-22 1:44 ` Jason Cooper
-1 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-22 1:44 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 00/16] Suspend to RAM support for Armada XP
@ 2014-11-22 1:44 ` Jason Cooper
0 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-22 1:44 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-21 17:20 ` Andrew Lunn
@ 2014-11-22 20:56 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-22 20:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
Dear Andrew Lunn,
On Fri, 21 Nov 2014 18:20:31 +0100, Andrew Lunn wrote:
> > > Hi Thomas
> > >
> > > 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.
>
> Ah, O.K. So i miss understood what you meant by bootloader. It is the
> first stage boot loader as part of the BootROM that does this.
>
> If i've got this wrong, probably others will as well. So could you
> make the comments talk about BootROM bootloader?
No, it is not the BootROM that does this. It is the binary header,
which is something different.
Essentially, the boot process is the following:
* BootROM runs. This one cannot be changed, it is set in stone in the
chip.
* It locates a bootable image from some media, and looks at its
header. Its header can contain several sections, some describing
some (address, value) pairs to write some values to some registers
(this was used on Kirkwood to configure the memory controller, for
example). Some other sections can contain binary code that will get
executed on the SoC, this is what is called a "binary header". It
gets executed before U-Boot starts, but it's really a piece of
software that can be changed.
* Then it loads and runs U-Boot.
The "binary header" is currently the piece of code that we extract
using the kwbimage tool from existing U-Boot images to build working
Barebox images, since we haven't yet written the equivalent code in
Barebox land.
So, the specification of where the "resume informations" is located and
how this information is organized is purely defined by software that
can potentially be changed, not by the BootROM. Though that if we
decided to use a different protocol, we would basically have a
suspend/resume in the kernel that would not work with any Marvell
platform that uses the default bootloader.
I hope that this clarifies how things are working.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-22 20:56 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-22 20:56 UTC (permalink / raw)
To: linux-arm-kernel
Dear Andrew Lunn,
On Fri, 21 Nov 2014 18:20:31 +0100, Andrew Lunn wrote:
> > > Hi Thomas
> > >
> > > 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.
>
> Ah, O.K. So i miss understood what you meant by bootloader. It is the
> first stage boot loader as part of the BootROM that does this.
>
> If i've got this wrong, probably others will as well. So could you
> make the comments talk about BootROM bootloader?
No, it is not the BootROM that does this. It is the binary header,
which is something different.
Essentially, the boot process is the following:
* BootROM runs. This one cannot be changed, it is set in stone in the
chip.
* It locates a bootable image from some media, and looks at its
header. Its header can contain several sections, some describing
some (address, value) pairs to write some values to some registers
(this was used on Kirkwood to configure the memory controller, for
example). Some other sections can contain binary code that will get
executed on the SoC, this is what is called a "binary header". It
gets executed before U-Boot starts, but it's really a piece of
software that can be changed.
* Then it loads and runs U-Boot.
The "binary header" is currently the piece of code that we extract
using the kwbimage tool from existing U-Boot images to build working
Barebox images, since we haven't yet written the equivalent code in
Barebox land.
So, the specification of where the "resume informations" is located and
how this information is organized is purely defined by software that
can potentially be changed, not by the BootROM. Though that if we
decided to use a different protocol, we would basically have a
suspend/resume in the kernel that would not work with any Marvell
platform that uses the default bootloader.
I hope that this clarifies how things are working.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-22 20:56 ` Thomas Petazzoni
@ 2014-11-23 3:36 ` Andrew Lunn
-1 siblings, 0 replies; 66+ messages in thread
From: Andrew Lunn @ 2014-11-23 3:36 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andrew Lunn, Jason Cooper, Sebastian Hesselbarth,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
On Sat, Nov 22, 2014 at 09:56:48PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Fri, 21 Nov 2014 18:20:31 +0100, Andrew Lunn wrote:
> > > > Hi Thomas
> > > >
> > > > 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.
> >
> > Ah, O.K. So i miss understood what you meant by bootloader. It is the
> > first stage boot loader as part of the BootROM that does this.
> >
> > If i've got this wrong, probably others will as well. So could you
> > make the comments talk about BootROM bootloader?
>
> No, it is not the BootROM that does this. It is the binary header,
> which is something different.
O.K, so this definitely needs documenting somewhere, since it is not
obvious. I'm not sure if it is sufficient to make this part of the
commit log, or if it should be documented in Documentation/power.
> Essentially, the boot process is the following:
>
> * BootROM runs. This one cannot be changed, it is set in stone in the
> chip.
>
> * It locates a bootable image from some media, and looks at its
> header. Its header can contain several sections, some describing
> some (address, value) pairs to write some values to some registers
> (this was used on Kirkwood to configure the memory controller, for
> example). Some other sections can contain binary code that will get
> executed on the SoC, this is what is called a "binary header". It
> gets executed before U-Boot starts, but it's really a piece of
> software that can be changed.
>
> * Then it loads and runs U-Boot.
>
>
> The "binary header" is currently the piece of code that we extract
> using the kwbimage tool from existing U-Boot images to build working
> Barebox images, since we haven't yet written the equivalent code in
> Barebox land.
Is it a binary blob in the uboot source tree?
> So, the specification of where the "resume informations" is located and
> how this information is organized is purely defined by software that
> can potentially be changed, not by the BootROM. Though that if we
> decided to use a different protocol, we would basically have a
> suspend/resume in the kernel that would not work with any Marvell
> platform that uses the default bootloader.
It also makes mainline suspend/resume dependent on Marvell not
changing the bootloader.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-23 3:36 ` Andrew Lunn
0 siblings, 0 replies; 66+ messages in thread
From: Andrew Lunn @ 2014-11-23 3:36 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Nov 22, 2014 at 09:56:48PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Fri, 21 Nov 2014 18:20:31 +0100, Andrew Lunn wrote:
> > > > Hi Thomas
> > > >
> > > > 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.
> >
> > Ah, O.K. So i miss understood what you meant by bootloader. It is the
> > first stage boot loader as part of the BootROM that does this.
> >
> > If i've got this wrong, probably others will as well. So could you
> > make the comments talk about BootROM bootloader?
>
> No, it is not the BootROM that does this. It is the binary header,
> which is something different.
O.K, so this definitely needs documenting somewhere, since it is not
obvious. I'm not sure if it is sufficient to make this part of the
commit log, or if it should be documented in Documentation/power.
> Essentially, the boot process is the following:
>
> * BootROM runs. This one cannot be changed, it is set in stone in the
> chip.
>
> * It locates a bootable image from some media, and looks at its
> header. Its header can contain several sections, some describing
> some (address, value) pairs to write some values to some registers
> (this was used on Kirkwood to configure the memory controller, for
> example). Some other sections can contain binary code that will get
> executed on the SoC, this is what is called a "binary header". It
> gets executed before U-Boot starts, but it's really a piece of
> software that can be changed.
>
> * Then it loads and runs U-Boot.
>
>
> The "binary header" is currently the piece of code that we extract
> using the kwbimage tool from existing U-Boot images to build working
> Barebox images, since we haven't yet written the equivalent code in
> Barebox land.
Is it a binary blob in the uboot source tree?
> So, the specification of where the "resume informations" is located and
> how this information is organized is purely defined by software that
> can potentially be changed, not by the BootROM. Though that if we
> decided to use a different protocol, we would basically have a
> suspend/resume in the kernel that would not work with any Marvell
> platform that uses the default bootloader.
It also makes mainline suspend/resume dependent on Marvell not
changing the bootloader.
Andrew
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-25 6:07 ` Mike Turquette
0 siblings, 0 replies; 66+ messages in thread
From: Mike Turquette @ 2014-11-25 6:07 UTC (permalink / raw)
To: Thomas Petazzoni, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel, Tawfik Bayouk, Nadav Haklai, Lior Amsalem,
Ezequiel Garcia, devicetree, Thomas Petazzoni, linux-kernel
Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> This commit adds suspend/resume support for the gatable clock driver
> used on Marvell EBU platforms. When getting out of suspend, the
> Marvell EBU platforms go through the bootloader, which re-enables all
> gatable clocks. However, upon resume, the clock framework will not
> disable again all gatable clocks that are not used.
>
> Therefore, if the clock driver does not save/restore the state of the
> gatable clocks, all gatable clocks that are not claimed by any device
> driver will remain enabled after a resume. This is why this driver
> saves and restores the state of those clocks.
>
> Since clocks aren't real devices, we don't have the normal ->suspend()
> and ->resume() of the device model, and have to use the ->suspend()
> and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> the unfortunate idea of not providing a way of passing private data,
> which requires us to change the driver to make the assumption that
> there is only once instance of the gatable clock control structure.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Looks good to me. Which tree do you plan to take this through?
Regards,
Mike
> ---
> drivers/clk/mvebu/common.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
> index b7fcb46..0d4d121 100644
> --- a/drivers/clk/mvebu/common.c
> +++ b/drivers/clk/mvebu/common.c
> @@ -19,6 +19,7 @@
> #include <linux/io.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include "common.h"
>
> @@ -177,14 +178,17 @@ struct clk_gating_ctrl {
> spinlock_t *lock;
> struct clk **gates;
> int num_gates;
> + void __iomem *base;
> + u32 saved_reg;
> };
>
> #define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
>
> +static struct clk_gating_ctrl *ctrl;
> +
> static struct clk *clk_gating_get_src(
> struct of_phandle_args *clkspec, void *data)
> {
> - struct clk_gating_ctrl *ctrl = (struct clk_gating_ctrl *)data;
> int n;
>
> if (clkspec->args_count < 1)
> @@ -199,15 +203,35 @@ static struct clk *clk_gating_get_src(
> return ERR_PTR(-ENODEV);
> }
>
> +static int mvebu_clk_gating_suspend(void)
> +{
> + ctrl->saved_reg = readl(ctrl->base);
> + return 0;
> +}
> +
> +static void mvebu_clk_gating_resume(void)
> +{
> + writel(ctrl->saved_reg, ctrl->base);
> +}
> +
> +static struct syscore_ops clk_gate_syscore_ops = {
> + .suspend = mvebu_clk_gating_suspend,
> + .resume = mvebu_clk_gating_resume,
> +};
> +
> void __init mvebu_clk_gating_setup(struct device_node *np,
> const struct clk_gating_soc_desc *desc)
> {
> - struct clk_gating_ctrl *ctrl;
> struct clk *clk;
> void __iomem *base;
> const char *default_parent = NULL;
> int n;
>
> + if (ctrl) {
> + pr_err("mvebu-clk-gating: cannot instantiate more than one gatable clock device\n");
> + return;
> + }
> +
> base = of_iomap(np, 0);
> if (WARN_ON(!base))
> return;
> @@ -225,6 +249,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
> /* lock must already be initialized */
> ctrl->lock = &ctrl_gating_lock;
>
> + ctrl->base = base;
> +
> /* Count, allocate, and register clock gates */
> for (n = 0; desc[n].name;)
> n++;
> @@ -246,6 +272,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
>
> of_clk_add_provider(np, clk_gating_get_src, ctrl);
>
> + register_syscore_ops(&clk_gate_syscore_ops);
> +
> return;
> gates_out:
> kfree(ctrl);
> --
> 2.1.0
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-25 6:07 ` Mike Turquette
0 siblings, 0 replies; 66+ messages in thread
From: Mike Turquette @ 2014-11-25 6:07 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA, Thomas Petazzoni,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> This commit adds suspend/resume support for the gatable clock driver
> used on Marvell EBU platforms. When getting out of suspend, the
> Marvell EBU platforms go through the bootloader, which re-enables all
> gatable clocks. However, upon resume, the clock framework will not
> disable again all gatable clocks that are not used.
>
> Therefore, if the clock driver does not save/restore the state of the
> gatable clocks, all gatable clocks that are not claimed by any device
> driver will remain enabled after a resume. This is why this driver
> saves and restores the state of those clocks.
>
> Since clocks aren't real devices, we don't have the normal ->suspend()
> and ->resume() of the device model, and have to use the ->suspend()
> and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> the unfortunate idea of not providing a way of passing private data,
> which requires us to change the driver to make the assumption that
> there is only once instance of the gatable clock control structure.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Looks good to me. Which tree do you plan to take this through?
Regards,
Mike
> ---
> drivers/clk/mvebu/common.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
> index b7fcb46..0d4d121 100644
> --- a/drivers/clk/mvebu/common.c
> +++ b/drivers/clk/mvebu/common.c
> @@ -19,6 +19,7 @@
> #include <linux/io.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include "common.h"
>
> @@ -177,14 +178,17 @@ struct clk_gating_ctrl {
> spinlock_t *lock;
> struct clk **gates;
> int num_gates;
> + void __iomem *base;
> + u32 saved_reg;
> };
>
> #define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
>
> +static struct clk_gating_ctrl *ctrl;
> +
> static struct clk *clk_gating_get_src(
> struct of_phandle_args *clkspec, void *data)
> {
> - struct clk_gating_ctrl *ctrl = (struct clk_gating_ctrl *)data;
> int n;
>
> if (clkspec->args_count < 1)
> @@ -199,15 +203,35 @@ static struct clk *clk_gating_get_src(
> return ERR_PTR(-ENODEV);
> }
>
> +static int mvebu_clk_gating_suspend(void)
> +{
> + ctrl->saved_reg = readl(ctrl->base);
> + return 0;
> +}
> +
> +static void mvebu_clk_gating_resume(void)
> +{
> + writel(ctrl->saved_reg, ctrl->base);
> +}
> +
> +static struct syscore_ops clk_gate_syscore_ops = {
> + .suspend = mvebu_clk_gating_suspend,
> + .resume = mvebu_clk_gating_resume,
> +};
> +
> void __init mvebu_clk_gating_setup(struct device_node *np,
> const struct clk_gating_soc_desc *desc)
> {
> - struct clk_gating_ctrl *ctrl;
> struct clk *clk;
> void __iomem *base;
> const char *default_parent = NULL;
> int n;
>
> + if (ctrl) {
> + pr_err("mvebu-clk-gating: cannot instantiate more than one gatable clock device\n");
> + return;
> + }
> +
> base = of_iomap(np, 0);
> if (WARN_ON(!base))
> return;
> @@ -225,6 +249,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
> /* lock must already be initialized */
> ctrl->lock = &ctrl_gating_lock;
>
> + ctrl->base = base;
> +
> /* Count, allocate, and register clock gates */
> for (n = 0; desc[n].name;)
> n++;
> @@ -246,6 +272,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
>
> of_clk_add_provider(np, clk_gating_get_src, ctrl);
>
> + register_syscore_ops(&clk_gate_syscore_ops);
> +
> return;
> gates_out:
> kfree(ctrl);
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-25 6:07 ` Mike Turquette
0 siblings, 0 replies; 66+ messages in thread
From: Mike Turquette @ 2014-11-25 6:07 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> This commit adds suspend/resume support for the gatable clock driver
> used on Marvell EBU platforms. When getting out of suspend, the
> Marvell EBU platforms go through the bootloader, which re-enables all
> gatable clocks. However, upon resume, the clock framework will not
> disable again all gatable clocks that are not used.
>
> Therefore, if the clock driver does not save/restore the state of the
> gatable clocks, all gatable clocks that are not claimed by any device
> driver will remain enabled after a resume. This is why this driver
> saves and restores the state of those clocks.
>
> Since clocks aren't real devices, we don't have the normal ->suspend()
> and ->resume() of the device model, and have to use the ->suspend()
> and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> the unfortunate idea of not providing a way of passing private data,
> which requires us to change the driver to make the assumption that
> there is only once instance of the gatable clock control structure.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: linux-kernel at vger.kernel.org
> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Looks good to me. Which tree do you plan to take this through?
Regards,
Mike
> ---
> drivers/clk/mvebu/common.c | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
> index b7fcb46..0d4d121 100644
> --- a/drivers/clk/mvebu/common.c
> +++ b/drivers/clk/mvebu/common.c
> @@ -19,6 +19,7 @@
> #include <linux/io.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/syscore_ops.h>
>
> #include "common.h"
>
> @@ -177,14 +178,17 @@ struct clk_gating_ctrl {
> spinlock_t *lock;
> struct clk **gates;
> int num_gates;
> + void __iomem *base;
> + u32 saved_reg;
> };
>
> #define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
>
> +static struct clk_gating_ctrl *ctrl;
> +
> static struct clk *clk_gating_get_src(
> struct of_phandle_args *clkspec, void *data)
> {
> - struct clk_gating_ctrl *ctrl = (struct clk_gating_ctrl *)data;
> int n;
>
> if (clkspec->args_count < 1)
> @@ -199,15 +203,35 @@ static struct clk *clk_gating_get_src(
> return ERR_PTR(-ENODEV);
> }
>
> +static int mvebu_clk_gating_suspend(void)
> +{
> + ctrl->saved_reg = readl(ctrl->base);
> + return 0;
> +}
> +
> +static void mvebu_clk_gating_resume(void)
> +{
> + writel(ctrl->saved_reg, ctrl->base);
> +}
> +
> +static struct syscore_ops clk_gate_syscore_ops = {
> + .suspend = mvebu_clk_gating_suspend,
> + .resume = mvebu_clk_gating_resume,
> +};
> +
> void __init mvebu_clk_gating_setup(struct device_node *np,
> const struct clk_gating_soc_desc *desc)
> {
> - struct clk_gating_ctrl *ctrl;
> struct clk *clk;
> void __iomem *base;
> const char *default_parent = NULL;
> int n;
>
> + if (ctrl) {
> + pr_err("mvebu-clk-gating: cannot instantiate more than one gatable clock device\n");
> + return;
> + }
> +
> base = of_iomap(np, 0);
> if (WARN_ON(!base))
> return;
> @@ -225,6 +249,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
> /* lock must already be initialized */
> ctrl->lock = &ctrl_gating_lock;
>
> + ctrl->base = base;
> +
> /* Count, allocate, and register clock gates */
> for (n = 0; desc[n].name;)
> n++;
> @@ -246,6 +272,8 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
>
> of_clk_add_provider(np, clk_gating_get_src, ctrl);
>
> + register_syscore_ops(&clk_gate_syscore_ops);
> +
> return;
> gates_out:
> kfree(ctrl);
> --
> 2.1.0
>
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
2014-11-25 6:07 ` Mike Turquette
(?)
@ 2014-11-25 6:48 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 6:48 UTC (permalink / raw)
To: Mike Turquette
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Tawfik Bayouk, Nadav Haklai,
Lior Amsalem, Ezequiel Garcia, devicetree, linux-kernel
Mike,
On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > This commit adds suspend/resume support for the gatable clock driver
> > used on Marvell EBU platforms. When getting out of suspend, the
> > Marvell EBU platforms go through the bootloader, which re-enables all
> > gatable clocks. However, upon resume, the clock framework will not
> > disable again all gatable clocks that are not used.
> >
> > Therefore, if the clock driver does not save/restore the state of the
> > gatable clocks, all gatable clocks that are not claimed by any device
> > driver will remain enabled after a resume. This is why this driver
> > saves and restores the state of those clocks.
> >
> > Since clocks aren't real devices, we don't have the normal ->suspend()
> > and ->resume() of the device model, and have to use the ->suspend()
> > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > the unfortunate idea of not providing a way of passing private data,
> > which requires us to change the driver to make the assumption that
> > there is only once instance of the gatable clock control structure.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Cc: Mike Turquette <mturquette@linaro.org>
> > Cc: linux-kernel@vger.kernel.org
> > Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Looks good to me. Which tree do you plan to take this through?
I don't have any specific plans. Jason, do you have other clk changes
for 3.19, which justify a pull request from you to Mike? Or could Mike
just take this patch in his tree? There is no build dependency between
this patch and the other patches in the series, so it can go through
whatever tree.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-25 6:48 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 6:48 UTC (permalink / raw)
To: Mike Turquette
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Mike,
On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > This commit adds suspend/resume support for the gatable clock driver
> > used on Marvell EBU platforms. When getting out of suspend, the
> > Marvell EBU platforms go through the bootloader, which re-enables all
> > gatable clocks. However, upon resume, the clock framework will not
> > disable again all gatable clocks that are not used.
> >
> > Therefore, if the clock driver does not save/restore the state of the
> > gatable clocks, all gatable clocks that are not claimed by any device
> > driver will remain enabled after a resume. This is why this driver
> > saves and restores the state of those clocks.
> >
> > Since clocks aren't real devices, we don't have the normal ->suspend()
> > and ->resume() of the device model, and have to use the ->suspend()
> > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > the unfortunate idea of not providing a way of passing private data,
> > which requires us to change the driver to make the assumption that
> > there is only once instance of the gatable clock control structure.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Cc: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Looks good to me. Which tree do you plan to take this through?
I don't have any specific plans. Jason, do you have other clk changes
for 3.19, which justify a pull request from you to Mike? Or could Mike
just take this patch in his tree? There is no build dependency between
this patch and the other patches in the series, so it can go through
whatever tree.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-25 6:48 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 6:48 UTC (permalink / raw)
To: linux-arm-kernel
Mike,
On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > This commit adds suspend/resume support for the gatable clock driver
> > used on Marvell EBU platforms. When getting out of suspend, the
> > Marvell EBU platforms go through the bootloader, which re-enables all
> > gatable clocks. However, upon resume, the clock framework will not
> > disable again all gatable clocks that are not used.
> >
> > Therefore, if the clock driver does not save/restore the state of the
> > gatable clocks, all gatable clocks that are not claimed by any device
> > driver will remain enabled after a resume. This is why this driver
> > saves and restores the state of those clocks.
> >
> > Since clocks aren't real devices, we don't have the normal ->suspend()
> > and ->resume() of the device model, and have to use the ->suspend()
> > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > the unfortunate idea of not providing a way of passing private data,
> > which requires us to change the driver to make the assumption that
> > there is only once instance of the gatable clock control structure.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Cc: Mike Turquette <mturquette@linaro.org>
> > Cc: linux-kernel at vger.kernel.org
> > Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Looks good to me. Which tree do you plan to take this through?
I don't have any specific plans. Jason, do you have other clk changes
for 3.19, which justify a pull request from you to Mike? Or could Mike
just take this patch in his tree? There is no build dependency between
this patch and the other patches in the series, so it can go through
whatever tree.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
2014-11-23 3:36 ` Andrew Lunn
@ 2014-11-25 6:51 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 6:51 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jason Cooper, Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA
Dear Andrew Lunn,
On Sun, 23 Nov 2014 04:36:03 +0100, Andrew Lunn wrote:
> > No, it is not the BootROM that does this. It is the binary header,
> > which is something different.
>
> O.K, so this definitely needs documenting somewhere, since it is not
> obvious. I'm not sure if it is sufficient to make this part of the
> commit log, or if it should be documented in Documentation/power.
I can send a follow-up patch that adds a more detailed comment in
arch/arm/mach-mvebu/pm.c maybe?
> > The "binary header" is currently the piece of code that we extract
> > using the kwbimage tool from existing U-Boot images to build working
> > Barebox images, since we haven't yet written the equivalent code in
> > Barebox land.
>
> Is it a binary blob in the uboot source tree?
Originally, parts of it were available in the form of source code, and
only the code doing the DDR3 training to calculate the optimal timings
was provided as a binary blob. However, in order to allow the U-Boot
folks to add complete support for Armada XP, Marvell opened this part
as well. See
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/marvell-armada-xp-2014-09-29-spl.
> > So, the specification of where the "resume informations" is located and
> > how this information is organized is purely defined by software that
> > can potentially be changed, not by the BootROM. Though that if we
> > decided to use a different protocol, we would basically have a
> > suspend/resume in the kernel that would not work with any Marvell
> > platform that uses the default bootloader.
>
> It also makes mainline suspend/resume dependent on Marvell not
> changing the bootloader.
Yes, absolutely. Just like the suspend/resume mechanism also depends on
which firmware was installed in the PIC micro-controller that controls
the power rails.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP
@ 2014-11-25 6:51 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 6:51 UTC (permalink / raw)
To: linux-arm-kernel
Dear Andrew Lunn,
On Sun, 23 Nov 2014 04:36:03 +0100, Andrew Lunn wrote:
> > No, it is not the BootROM that does this. It is the binary header,
> > which is something different.
>
> O.K, so this definitely needs documenting somewhere, since it is not
> obvious. I'm not sure if it is sufficient to make this part of the
> commit log, or if it should be documented in Documentation/power.
I can send a follow-up patch that adds a more detailed comment in
arch/arm/mach-mvebu/pm.c maybe?
> > The "binary header" is currently the piece of code that we extract
> > using the kwbimage tool from existing U-Boot images to build working
> > Barebox images, since we haven't yet written the equivalent code in
> > Barebox land.
>
> Is it a binary blob in the uboot source tree?
Originally, parts of it were available in the form of source code, and
only the code doing the DDR3 training to calculate the optimal timings
was provided as a binary blob. However, in order to allow the U-Boot
folks to add complete support for Armada XP, Marvell opened this part
as well. See
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/marvell-armada-xp-2014-09-29-spl.
> > So, the specification of where the "resume informations" is located and
> > how this information is organized is purely defined by software that
> > can potentially be changed, not by the BootROM. Though that if we
> > decided to use a different protocol, we would basically have a
> > suspend/resume in the kernel that would not work with any Marvell
> > platform that uses the default bootloader.
>
> It also makes mainline suspend/resume dependent on Marvell not
> changing the bootloader.
Yes, absolutely. Just like the suspend/resume mechanism also depends on
which firmware was installed in the PIC micro-controller that controls
the power rails.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay
2014-11-22 0:53 ` Jason Cooper
@ 2014-11-25 17:44 ` Thomas Petazzoni
-1 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 17:44 UTC (permalink / raw)
To: Jason Cooper
Cc: Lior Amsalem, Andrew Lunn, Russell King, Tawfik Bayouk,
devicetree, stable, Nadav Haklai, Ezequiel Garcia,
Gregory Clement, linux-arm-kernel, Sebastian Hesselbarth
Dear Jason Cooper,
On Fri, 21 Nov 2014 19:53:38 -0500, Jason Cooper wrote:
> > arch/arm/mm/proc-v7.S | 2 --
> > 1 file changed, 2 deletions(-)
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
>
> Please add to Russell's patch tracker.
Thanks, done in
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8222/1.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay
@ 2014-11-25 17:44 ` Thomas Petazzoni
0 siblings, 0 replies; 66+ messages in thread
From: Thomas Petazzoni @ 2014-11-25 17:44 UTC (permalink / raw)
To: linux-arm-kernel
Dear Jason Cooper,
On Fri, 21 Nov 2014 19:53:38 -0500, Jason Cooper wrote:
> > arch/arm/mm/proc-v7.S | 2 --
> > 1 file changed, 2 deletions(-)
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
>
> Please add to Russell's patch tracker.
Thanks, done in
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8222/1.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-26 4:03 ` Jason Cooper
0 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-26 4:03 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mike Turquette, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Tawfik Bayouk, Nadav Haklai,
Lior Amsalem, Ezequiel Garcia, devicetree, linux-kernel
On Tue, Nov 25, 2014 at 07:48:01AM +0100, Thomas Petazzoni wrote:
> Mike,
>
> On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> > Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > > This commit adds suspend/resume support for the gatable clock driver
> > > used on Marvell EBU platforms. When getting out of suspend, the
> > > Marvell EBU platforms go through the bootloader, which re-enables all
> > > gatable clocks. However, upon resume, the clock framework will not
> > > disable again all gatable clocks that are not used.
> > >
> > > Therefore, if the clock driver does not save/restore the state of the
> > > gatable clocks, all gatable clocks that are not claimed by any device
> > > driver will remain enabled after a resume. This is why this driver
> > > saves and restores the state of those clocks.
> > >
> > > Since clocks aren't real devices, we don't have the normal ->suspend()
> > > and ->resume() of the device model, and have to use the ->suspend()
> > > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > > the unfortunate idea of not providing a way of passing private data,
> > > which requires us to change the driver to make the assumption that
> > > there is only once instance of the gatable clock control structure.
> > >
> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > > Cc: Mike Turquette <mturquette@linaro.org>
> > > Cc: linux-kernel@vger.kernel.org
> > > Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> > Looks good to me. Which tree do you plan to take this through?
>
> I don't have any specific plans. Jason, do you have other clk changes
> for 3.19, which justify a pull request from you to Mike? Or could Mike
> just take this patch in his tree? There is no build dependency between
> this patch and the other patches in the series, so it can go through
> whatever tree.
Well, I pulled the whole series into mvebu/soc-suspend to give it some
time in -next. It'd be easiest, with my current schedule, to send a
PR for it as-is. If that's ok with Mike, I'd appreciate it. Obviously,
I wouldn't make a habit of it... :-P
thx,
Jason.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-26 4:03 ` Jason Cooper
0 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-26 4:03 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mike Turquette, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Tawfik Bayouk,
Nadav Haklai, Lior Amsalem, Ezequiel Garcia,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Tue, Nov 25, 2014 at 07:48:01AM +0100, Thomas Petazzoni wrote:
> Mike,
>
> On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> > Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > > This commit adds suspend/resume support for the gatable clock driver
> > > used on Marvell EBU platforms. When getting out of suspend, the
> > > Marvell EBU platforms go through the bootloader, which re-enables all
> > > gatable clocks. However, upon resume, the clock framework will not
> > > disable again all gatable clocks that are not used.
> > >
> > > Therefore, if the clock driver does not save/restore the state of the
> > > gatable clocks, all gatable clocks that are not claimed by any device
> > > driver will remain enabled after a resume. This is why this driver
> > > saves and restores the state of those clocks.
> > >
> > > Since clocks aren't real devices, we don't have the normal ->suspend()
> > > and ->resume() of the device model, and have to use the ->suspend()
> > > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > > the unfortunate idea of not providing a way of passing private data,
> > > which requires us to change the driver to make the assumption that
> > > there is only once instance of the gatable clock control structure.
> > >
> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > Cc: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >
> > Looks good to me. Which tree do you plan to take this through?
>
> I don't have any specific plans. Jason, do you have other clk changes
> for 3.19, which justify a pull request from you to Mike? Or could Mike
> just take this patch in his tree? There is no build dependency between
> this patch and the other patches in the series, so it can go through
> whatever tree.
Well, I pulled the whole series into mvebu/soc-suspend to give it some
time in -next. It'd be easiest, with my current schedule, to send a
PR for it as-is. If that's ok with Mike, I'd appreciate it. Obviously,
I wouldn't make a habit of it... :-P
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks
@ 2014-11-26 4:03 ` Jason Cooper
0 siblings, 0 replies; 66+ messages in thread
From: Jason Cooper @ 2014-11-26 4:03 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Nov 25, 2014 at 07:48:01AM +0100, Thomas Petazzoni wrote:
> Mike,
>
> On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> > Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > > This commit adds suspend/resume support for the gatable clock driver
> > > used on Marvell EBU platforms. When getting out of suspend, the
> > > Marvell EBU platforms go through the bootloader, which re-enables all
> > > gatable clocks. However, upon resume, the clock framework will not
> > > disable again all gatable clocks that are not used.
> > >
> > > Therefore, if the clock driver does not save/restore the state of the
> > > gatable clocks, all gatable clocks that are not claimed by any device
> > > driver will remain enabled after a resume. This is why this driver
> > > saves and restores the state of those clocks.
> > >
> > > Since clocks aren't real devices, we don't have the normal ->suspend()
> > > and ->resume() of the device model, and have to use the ->suspend()
> > > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > > the unfortunate idea of not providing a way of passing private data,
> > > which requires us to change the driver to make the assumption that
> > > there is only once instance of the gatable clock control structure.
> > >
> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > > Cc: Mike Turquette <mturquette@linaro.org>
> > > Cc: linux-kernel at vger.kernel.org
> > > Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> > Looks good to me. Which tree do you plan to take this through?
>
> I don't have any specific plans. Jason, do you have other clk changes
> for 3.19, which justify a pull request from you to Mike? Or could Mike
> just take this patch in his tree? There is no build dependency between
> this patch and the other patches in the series, so it can go through
> whatever tree.
Well, I pulled the whole series into mvebu/soc-suspend to give it some
time in -next. It'd be easiest, with my current schedule, to send a
PR for it as-is. If that's ok with Mike, I'd appreciate it. Obviously,
I wouldn't make a habit of it... :-P
thx,
Jason.
^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [PATCHv3 05/16] gpio: mvebu: add suspend/resume support
2014-11-21 16:00 ` Thomas Petazzoni
@ 2014-11-28 11:55 ` Linus Walleij
-1 siblings, 0 replies; 66+ messages in thread
From: Linus Walleij @ 2014-11-28 11:55 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Tawfik Bayouk, Nadav Haklai,
Lior Amsalem, Ezequiel Garcia, devicetree, Alexandre Courbot,
linux-gpio
On Fri, Nov 21, 2014 at 5:00 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds the implementation of ->suspend() and ->resume()
> platform_driver hooks in order to save and restore the state of the
> GPIO configuration. In order to achieve that, additional fields are
> added to the mvebu_gpio_chip structure.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio@vger.kernel.org
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
I already have this patch applied to the GPIO tree, I guess you're
just resending the whole set on routine...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 66+ messages in thread
* [PATCHv3 05/16] gpio: mvebu: add suspend/resume support
@ 2014-11-28 11:55 ` Linus Walleij
0 siblings, 0 replies; 66+ messages in thread
From: Linus Walleij @ 2014-11-28 11:55 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Nov 21, 2014 at 5:00 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This commit adds the implementation of ->suspend() and ->resume()
> platform_driver hooks in order to save and restore the state of the
> GPIO configuration. In order to achieve that, additional fields are
> added to the mvebu_gpio_chip structure.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio at vger.kernel.org
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
I already have this patch applied to the GPIO tree, I guess you're
just resending the whole set on routine...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2014-11-28 11:55 UTC | newest]
Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-21 15:59 [PATCHv3 00/16] Suspend to RAM support for Armada XP Thomas Petazzoni
2014-11-21 15:59 ` Thomas Petazzoni
2014-11-21 15:59 ` [PATCHv3 02/16] ARM: mvebu: enable strex backoff delay Thomas Petazzoni
2014-11-21 15:59 ` Thomas Petazzoni
2014-11-22 0:53 ` Jason Cooper
2014-11-22 0:53 ` Jason Cooper
2014-11-25 17:44 ` Thomas Petazzoni
2014-11-25 17:44 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 03/16] irqchip: irq-armada-370-xp: suspend/resume support Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 04/16] clocksource: time-armada-370-xp: add " Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 05/16] gpio: mvebu: " Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-28 11:55 ` Linus Walleij
2014-11-28 11:55 ` Linus Walleij
2014-11-21 16:00 ` [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-25 6:07 ` Mike Turquette
2014-11-25 6:07 ` Mike Turquette
2014-11-25 6:07 ` Mike Turquette
2014-11-25 6:48 ` Thomas Petazzoni
2014-11-25 6:48 ` Thomas Petazzoni
2014-11-25 6:48 ` Thomas Petazzoni
2014-11-26 4:03 ` Jason Cooper
2014-11-26 4:03 ` Jason Cooper
2014-11-26 4:03 ` Jason Cooper
[not found] ` <1416585613-2113-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-11-21 15:59 ` [PATCHv3 01/16] Documentation: dt-bindings: minimal documentation for MVEBU SDRAM controller Thomas Petazzoni
2014-11-21 15:59 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 06/16] bus: mvebu-mbus: suspend/resume support Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 07/16] bus: mvebu-mbus: provide a mechanism to save SDRAM window configuration Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 09/16] ARM: mvebu: implement suspend/resume support for Armada XP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
[not found] ` <1416585613-2113-10-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-11-21 16:41 ` Andrew Lunn
2014-11-21 16:41 ` Andrew Lunn
[not found] ` <20141121164142.GB20238-g2DYL2Zd6BY@public.gmane.org>
2014-11-21 16:59 ` Thomas Petazzoni
2014-11-21 16:59 ` Thomas Petazzoni
[not found] ` <20141121175957.6ef4f26d-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-11-21 17:20 ` Andrew Lunn
2014-11-21 17:20 ` Andrew Lunn
[not found] ` <20141121172031.GC20238-g2DYL2Zd6BY@public.gmane.org>
2014-11-22 0:50 ` Jason Cooper
2014-11-22 0:50 ` Jason Cooper
2014-11-22 20:56 ` Thomas Petazzoni
2014-11-22 20:56 ` Thomas Petazzoni
[not found] ` <20141122215648.771225f2-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-11-23 3:36 ` Andrew Lunn
2014-11-23 3:36 ` Andrew Lunn
[not found] ` <20141123033603.GA9801-g2DYL2Zd6BY@public.gmane.org>
2014-11-25 6:51 ` Thomas Petazzoni
2014-11-25 6:51 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 10/16] ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resume Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 11/16] ARM: mvebu: Armada XP GP specific suspend/resume code Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 12/16] ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resume Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 13/16] ARM: mvebu: synchronize secondary CPU clocks on resume Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 14/16] ARM: mvebu: add suspend/resume DT information for Armada XP GP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 15/16] ARM: mvebu: adjust mbus controller description on Armada 370/XP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-21 16:00 ` [PATCHv3 16/16] ARM: mvebu: add SDRAM controller description for Armada XP Thomas Petazzoni
2014-11-21 16:00 ` Thomas Petazzoni
2014-11-22 1:44 ` [PATCHv3 00/16] Suspend to RAM support " Jason Cooper
2014-11-22 1:44 ` Jason Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.