Support for Fujitsu MB86S7X SoCs

Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
  .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
  drivers/mailbox/Kconfig                            |   7 +
  drivers/mailbox/Makefile                           |   2 +
  drivers/mailbox/arm_mhu.c                          | 196 +++++++++++++++++++++
  4 files changed, 238 insertions(+)

create mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt create mode 100644 drivers/mailbox/arm_mhu.c

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +0 -0

new file mode 100644
index 0000000..b1b9888

Quoted 27 lines · Vincent Yang

Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
  .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
  drivers/mailbox/Kconfig                            |   7 +
  drivers/mailbox/Makefile                           |   2 +
  drivers/mailbox/arm_mhu.c                          | 196
+++++++++++++++++++++
  4 files changed, 238 insertions(+)

create mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt create mode 100644 drivers/mailbox/arm_mhu.c

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +3 -0

new file mode 100644
index 0000000..b1b9888
@@ -0,0 +1,33 @@
+ARM MHU Mailbox Driver
+======================
+

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 5

Quoted 2 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +2 -0

+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has
+3 independent channels/links to communicate with remote processor(s).

I had reviewed this before and I see not all the comments are addressed. I had mentioned that you can't add support to _SECURE_ channel in Linux as you need to assume Linux runs in non-secure privilege(and I gather that's the case even on this platform from other email in the thread)

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 9

Quoted 4 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +4 -0

+ MHU links are hardwired on a platform. A link raises interrupt for any
+received data. However, there is no specified way of knowing if the sent
+data has been read by the remote. This driver assumes the sender polls
+STAT register and the remote clears it after having read the data.

That could be design, interrupt support could be present on some systems. The bindings should be flexible to add that support in future if needed along with necessary code.

Quoted 30 lines · Sudeep Holla

Quoted 27 lines · Vincent Yang

Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
   .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
   drivers/mailbox/Kconfig                            |   7 +
   drivers/mailbox/Makefile                           |   2 +
   drivers/mailbox/arm_mhu.c                          | 196
+++++++++++++++++++++
   4 files changed, 238 insertions(+)

create mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt create mode 100644 drivers/mailbox/arm_mhu.c

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +3 -0

new file mode 100644
index 0000000..b1b9888
@@ -0,0 +1,33 @@
+ARM MHU Mailbox Driver
+======================
+

Quoted 9 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 5

Quoted 2 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +2 -0

+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has
+3 independent channels/links to communicate with remote processor(s).

I had reviewed this before and I see not all the comments are addressed. I had mentioned that you can't add support to _SECURE_ channel in Linux as you need to assume Linux runs in non-secure privilege(and I gather that's the case even on this platform from other email in the thread)

Please revisit the old thread. After some discussion you had graciously allowed me to keep the secure channel ;)
[
... Even though I don't like you have secure channel access in Linux, you have valid reasons. In case you decide to support it ....
]

It seems you still don't get my point that the driver should manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Quoted 45 lines · Jassi Brar

Quoted 34 lines · Sudeep Holla

Quoted 30 lines · Vincent Yang

Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
   .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
   drivers/mailbox/Kconfig                            |   7 +
   drivers/mailbox/Makefile                           |   2 +
   drivers/mailbox/arm_mhu.c                          | 196
+++++++++++++++++++++
   4 files changed, 238 insertions(+)

create mode 100644
Documentation/devicetree/bindings/mailbox/arm-mhu.txt
create mode 100644 drivers/mailbox/arm_mhu.c

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +4 -0

new file mode 100644
index 0000000..b1b9888
@@ -0,0 +1,33 @@
+ARM MHU Mailbox Driver
+======================
+
+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has

Quoted 9 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 5

Quoted 1 line

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +1 -0

+3 independent channels/links to communicate with remote processor(s).

I had reviewed this before and I see not all the comments are addressed. I had mentioned that you can't add support to _SECURE_ channel in Linux as you need to assume Linux runs in non-secure privilege(and I gather that's the case even on this platform from other email in the thread)

Quoted 6 lines

Please revisit the old thread. After some discussion you had graciously allowed me to keep the secure channel ;)
[
... Even though I don't like you have secure channel access in Linux, you have valid reasons. In case you decide to support it ....
]

Agreed but based on the other email in the same thread it looks like you want to run the same kernel both in secure and no-secure mode on this platform, in which case you _have_to_assume_ it's *non-secure only* always unless you come up with some DT magic.

Quoted 6 lines

It seems you still don't get my point that the driver should manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

Quoted 5 lines · Sudeep Holla

Quoted 2 lines · Jassi Brar

On 25 November 2014 at 20:07, Sudeep Holla <[email protected]>

Quoted 23 lines

Quoted 23 lines

Quoted 23 lines · Vincent Yang

Quoted 19 lines

Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
   .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
   drivers/mailbox/Kconfig                            |   7 +
   drivers/mailbox/Makefile                           |   2 +
   drivers/mailbox/arm_mhu.c                          | 196
+++++++++++++++++++++
   4 files changed, 238 insertions(+)

create mode 100644
Documentation/devicetree/bindings/mailbox/arm-mhu.txt
create mode 100644 drivers/mailbox/arm_mhu.c

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 4

Quoted 11 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +4 -0

new file mode 100644
index 0000000..b1b9888
@@ -0,0 +1,33 @@
+ARM MHU Mailbox Driver
+======================
+
+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that

Quoted 1 line

Quoted 1 line

Quoted 1 line

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 5

Quoted 1 line

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +1 -0

+3 independent channels/links to communicate with remote

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

I had reviewed this before and I see not all the comments are

Quoted 1 line

Quoted 1 line

Quoted 1 line

I had mentioned that you can't add support to _SECURE_ channel in

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

as you need to assume Linux runs in non-secure privilege(and I gather that's the case even on this platform from other email in the thread)

Please revisit the old thread. After some discussion you had graciously allowed me to keep the secure channel ;)
[
... Even though I don't like you have secure channel access in Linux,

Quoted 7 lines

Quoted 2 lines

have valid reasons. In case you decide to support it .... ]

Agreed but based on the other email in the same thread it looks like you want to run the same kernel both in secure and no-secure mode on this platform, in which case you _have_to_assume_ it's *non-secure only*

Quoted 2 lines

unless you come up with some DT magic.

Yes, the S vs NS mode should ideally be defined in DT. The kernel image should remain the same.

Quoted 11 lines

Quoted 6 lines

It seems you still don't get my point that the driver should manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

No. Please look at the dtsi again ....

        mhu: mailbox@2b1f0000 {
                #mbox-cells = <1>;
                compatible = "arm,mbox-mhu";
                reg = <0 0x2b1f0000 0x1000>;
                interrupts = <0 36 4>, /* LP Non-Sec */
                             <0 35 4>, /* HP Non-Sec */
                             <0 37 4>; /* Secure */
        };

        mhu_client: scb@2e000000 {
                compatible = "fujitsu,mb86s70-scb-1.0";
                reg = <0 0x2e000000 0x4000>; /* SHM for IPC */
                mboxes = <&mhu 1>;
        };

See the DT for mbox client specifies that it uses channel-1 which is High-Priority_Non-Secure channel.

-jassi

Quoted 56 lines · Sudeep Holla

Quoted 51 lines · Jassi Brar

Quoted 34 lines · Sudeep Holla

Quoted 30 lines · Vincent Yang

Add driver for the ARM Message-Handling-Unit (MHU).

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
    .../devicetree/bindings/mailbox/arm-mhu.txt        |  33 ++++
    drivers/mailbox/Kconfig                            |   7 +
    drivers/mailbox/Makefile                           |   2 +
    drivers/mailbox/arm_mhu.c                          | 196
+++++++++++++++++++++
    4 files changed, 238 insertions(+)
    create mode 100644

Documentation/devicetree/bindings/mailbox/arm-mhu.txt
create mode 100644 drivers/mailbox/arm_mhu.c

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +4 -0

new file mode 100644
index 0000000..b1b9888
@@ -0,0 +1,33 @@
+ARM MHU Mailbox Driver
+======================
+
+The ARM's Message-Handling-Unit (MHU) is a mailbox controller that has

Quoted 9 lines

Documentation/devicetree/bindings/mailbox/arm-mhu.txt line 5

Quoted 1 line

Documentation/devicetree/bindings/mailbox/arm-mhu.txt new file +1 -0

+3 independent channels/links to communicate with remote processor(s).

I had reviewed this before and I see not all the comments are addressed. I had mentioned that you can't add support to _SECURE_ channel in Linux as you need to assume Linux runs in non-secure privilege(and I gather that's the case even on this platform from other email in the thread)

Please revisit the old thread. After some discussion you had graciously allowed me to keep the secure channel ;)
[
... Even though I don't like you have secure channel access in Linux, you have valid reasons. In case you decide to support it ....
]

Quoted 5 lines

Agreed but based on the other email in the same thread it looks like you want to run the same kernel both in secure and no-secure mode on this platform, in which case you _have_to_assume_ it's *non-secure only* always unless you come up with some DT magic.

Yes, the S vs NS mode should ideally be defined in DT. The kernel image should remain the same.

Quoted 11 lines

Quoted 6 lines

It seems you still don't get my point that the driver should manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

No. Please look at the dtsi again ....

         mhu: mailbox at 2b1f0000 {
                 #mbox-cells = <1>;
                 compatible = "arm,mbox-mhu";
                 reg = <0 0x2b1f0000 0x1000>;
                 interrupts = <0 36 4>, /* LP Non-Sec */
                              <0 35 4>, /* HP Non-Sec */
                              <0 37 4>; /* Secure */

         };

         mhu_client: scb at 2e000000 {
                 compatible = "fujitsu,mb86s70-scb-1.0";
                 reg = <0 0x2e000000 0x4000>; /* SHM for IPC */
                 mboxes = <&mhu 1>;
         };

See the DT for mbox client specifies that it uses channel-1 which is High-Priority_Non-Secure channel.

Quoted 15 lines · Jassi Brar

Quoted 9 lines

Quoted 8 lines

It seems you still don't get my point that the driver should manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Quoted 4 lines

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

No. Please look at the dtsi again ....

Quoted 7 lines

         mhu: mailbox at 2b1f0000 {
                 #mbox-cells = <1>;
                 compatible = "arm,mbox-mhu";
                 reg = <0 0x2b1f0000 0x1000>;
                 interrupts = <0 36 4>, /* LP Non-Sec */
                              <0 35 4>, /* HP Non-Sec */
                              <0 37 4>; /* Secure */

One possible issue I can think of(though current driver design requests irq only on channel startup, it could be moved to probe for optimization in which case you need a way to make sure secure channel or irq is not accessed)

Quoted 11 lines

         };

         mhu_client: scb at 2e000000 {
                 compatible = "fujitsu,mb86s70-scb-1.0";
                 reg = <0 0x2e000000 0x4000>; /* SHM for IPC */
                 mboxes = <&mhu 1>;
         };

See the DT for mbox client specifies that it uses channel-1 which is High-Priority_Non-Secure channel.

Yes I noticed that, but still a wrong entry of another mhu_client with secure channel might end up crashing MHU driver or even whole system. Not sure but still probably one could try to play around with DT overlays in future, just a thought. So you need to ensure that's handled properly in the MHU driver.

Quoted 25 lines · Sudeep Holla

Quoted 22 lines · Jassi Brar

Quoted 9 lines

Quoted 8 lines

It seems you still don't get my point that the driver should manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Quoted 4 lines

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

No. Please look at the dtsi again ....

          mhu: mailbox at 2b1f0000 {
                  #mbox-cells = <1>;
                  compatible = "arm,mbox-mhu";
                  reg = <0 0x2b1f0000 0x1000>;
                  interrupts = <0 36 4>, /* LP Non-Sec */
                               <0 35 4>, /* HP Non-Sec */
                               <0 37 4>; /* Secure */

Quoted 5 lines

One possible issue I can think of(though current driver design requests irq only on channel startup, it could be moved to probe for optimization in which case you need a way to make sure secure channel or irq is not accessed)

As you see it is fine as such.

Quoted 31 lines · Jassi Brar

Quoted 29 lines · Sudeep Holla

Quoted 24 lines · Jassi Brar

Quoted 11 lines

Quoted 10 lines

It seems you still don't get my point that the driver should
manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Quoted 4 lines

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

No. Please look at the dtsi again ....

          mhu: mailbox at 2b1f0000 {
                  #mbox-cells = <1>;
                  compatible = "arm,mbox-mhu";
                  reg = <0 0x2b1f0000 0x1000>;
                  interrupts = <0 36 4>, /* LP Non-Sec */
                               <0 35 4>, /* HP Non-Sec */
                               <0 37 4>; /* Secure */

Quoted 6 lines

Quoted 5 lines

One possible issue I can think of(though current driver design requests irq only on channel startup, it could be moved to probe for optimization in which case you need a way to make sure secure channel or irq is not accessed)

As you see it is fine as such.

Agreed, but assuming some driver logic. I would like to see some way of identifying that from DT if we adding the support for secure channel in the driver else I prefer not to add it unless there is a real user of it(which is not the case with your current patch set). That will be handy if there's any issue in future due to some firmware that can't be changed or upgraded.

Quoted 42 lines · Sudeep Holla

Quoted 31 lines · Jassi Brar

Quoted 29 lines · Sudeep Holla

Quoted 24 lines · Jassi Brar

Quoted 11 lines

Quoted 10 lines

It seems you still don't get my point that the driver should
manage
all channels - S & NS. If Linux is running in NS mode on a platform, the DT will specify only some NS channel to be used. The controller driver shouldn't be crippled just because you think Linux will never be run in Secure mode.

Quoted 4 lines

Ok how do you handle that, I don't see that in the DT binding. As it stands, you can unconditionally try to access the secure channel and cause aborts if the platform is running in non-secure mode.

No. Please look at the dtsi again ....

           mhu: mailbox at 2b1f0000 {
                   #mbox-cells = <1>;
                   compatible = "arm,mbox-mhu";
                   reg = <0 0x2b1f0000 0x1000>;
                   interrupts = <0 36 4>, /* LP Non-Sec */
                                <0 35 4>, /* HP Non-Sec */
                                <0 37 4>; /* Secure */

Quoted 6 lines

Quoted 5 lines

One possible issue I can think of(though current driver design requests irq only on channel startup, it could be moved to probe for optimization in which case you need a way to make sure secure channel or irq is not accessed)

As you see it is fine as such.

Quoted 7 lines

Agreed, but assuming some driver logic. I would like to see some way of identifying that from DT if we adding the support for secure channel in the driver else I prefer not to add it unless there is a real user of it(which is not the case with your current patch set). That will be handy if there's any issue in future due to some firmware that can't be changed or upgraded.

Could you please suggest some way of identifying that from DT if we adding the support for secure channel in the driver?

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   2 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 3 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +0 -0

index 97640b6..b0fa34b 100644

arch/arm/mach-mb86s7x/Makefile +8 -0

+#define mb86s70evb_exit_coherency_flush(level) { \
+	asm volatile( \
+	"stmfd	sp!, {fp, ip}\n\t" \
+	"mrc	p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \
+	"bic	r0, r0, #"__stringify(CR_C)"\n\t" \
+	"mcr	p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+	"isb\n\t" \
+	"bl	v7_flush_dcache_"__stringify(level)"\n\t" \

Quoted 20 lines · On Thursday 20 November 2014 20:35:20 Vincent Yang wrote:

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   2 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 3 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +0 -0

index 97640b6..b0fa34b 100644

arch/arm/mach-mb86s7x/Makefile line 1

Quoted 2 lines

arch/arm/mach-mb86s7x/Makefile +1 -1

@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

The two files are using ARMv7-only instructions in inline assembly, which means that you will get a compile error for a combined arvm6+armv7 kernel. Please add the appropriate 'CFLAGS_mcpm.o += -march=armv7-a' statements in the Makefile for each file with this problem.

arch/arm/mach-mb86s7x/Makefile

Quoted 4 lines

arch/arm/mach-mb86s7x/Makefile +4 -0

+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;

Out of principle, you should never put an 'extern' declaration into .c file. Better put this into a header file that is shared between all files accessing the variable. In this particular case, I think it would be better to just move the mb86s7x_set_wficolor() implementation into drivers/soc/mb86s7x/scb_mhu.c and add an exported symbol for that, so you can keep the variable local to the mhu implementation.

Quoted 8 lines

arch/arm/mach-mb86s7x/Makefile +8 -0

+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \
+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \

arch/arm/mach-mb86s7x/Makefile

Quoted 10 lines

arch/arm/mach-mb86s7x/Makefile +10 -0

+     "bl     mb86s70evb_outer_flush_all\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 1   @ get ACTLR\n\t" \
+     "bic    r0, r0, #(1 << 6)       @ disable local coherency\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 1   @ set ACTLR\n\t" \
+     "isb\n\t" \
+     "dsb\n\t" \
+     "ldmfd  sp!, {fp, ip}" \
+             : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", \
+             "r9", "r10", "lr", "memory"); \
+     }

Please make this an inline function instead of a macro.

arch/arm/mach-mb86s7x/Makefile

Quoted 2 lines

arch/arm/mach-mb86s7x/Makefile +2 -0

+
+extern void mb86s7x_cpu_entry(unsigned long secondary_entry);

Same comment about the extern declaration here. The header won't be used by the implementation file as that is written in assembly, but it's better to be consistent.

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
  arch/arm/mach-mb86s7x/Makefile |   2 +-
  arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-mb86s7x/smc.S    |  27 ++++
  3 files changed, 388 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/smc.S new file +14 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+

Quoted 31 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

arch/arm/mach-mb86s7x/smc.S new file +20 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+       stmfd   sp!, {r1-r11, lr}
+       mov r1, r0
+       ldr r0, =1
+       mrc p15, 0, r3, c1, c0, 0

arch/arm/mach-mb86s7x/smc.S line 24

Quoted 4 lines

arch/arm/mach-mb86s7x/smc.S new file +4 -0

+       mov r4, r3
+       and r3, #0xbfffffff
+       mcr p15, 0, r3, c1, c0, 0
+       smc #0

Interesting, it looks like you have some secure entity running on your platform.

1. While the CPU is powered down who is taking care of saving it's state as you are doing it in the Linux itself ?

2. Is Linux running in Secure or Non-secure mode ?

3. Why do you need this smc call for secondary boot only ?

Regards,
Sudeep

Quoted 32 lines · Sudeep Holla

Quoted 31 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

arch/arm/mach-mb86s7x/smc.S new file +20 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+       stmfd   sp!, {r1-r11, lr}
+       mov r1, r0
+       ldr r0, =1
+       mrc p15, 0, r3, c1, c0, 0

Quoted 8 lines

arch/arm/mach-mb86s7x/smc.S line 24

Quoted 4 lines

arch/arm/mach-mb86s7x/smc.S new file +4 -0

+       mov r4, r3
+       and r3, #0xbfffffff
+       mcr p15, 0, r3, c1, c0, 0
+       smc #0

Interesting, it looks like you have some secure entity running on your platform.

Yes, we have a stub "secure firmware" that implements a few critical functions to allow us to operate the kernel as nonsecure. It's part of the bootloader for this platform which is also GPL'd.

Quoted 2 lines

1. While the CPU is powered down who is taking care of saving it's state as you are doing it in the Linux itself ?

Nothing. The secure firmware is in a bootloader that is copied to and runs from secure sram. When the cpu is reset, he comes back up in secure mode and gets initialized in the secure firmware, before entering Non-secure mode and the kernel's secondary entry point.

Quoted 1 line

2. Is Linux running in Secure or Non-secure mode ?

Another firmware (unfortunately not GPL) running on an on-die M3 informs the secure firmware on the AP whether he should set the AP cpu to nonsecure or not before jumping to the kernel... basically it's decided at runtime and the same kernel binary serves in both modes.

Quoted 1 line

3. Why do you need this smc call for secondary boot only ?

The call sets the secondary entry point stored in the secure sram.

The bootloader heuristic is if that's unset (0), and it's what the

bootloader decided should be regarded as the primary cpu, then we do the real onetime cold boot flow, load the kernel etc. Non-primary cpus wait at WFI in the bootloader. When the primary cpu runs the code above, he sets the secondary entry point, and later starts to

bring up the other cores who jump to the secondary entry that was set.

Quoted 47 lines · Andy Green

Quoted 34 lines · Sudeep Holla

Quoted 33 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

arch/arm/mach-mb86s7x/smc.S new file +21 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+       stmfd   sp!, {r1-r11, lr}
+       mov r1, r0
+       ldr r0, =1
+       mrc p15, 0, r3, c1, c0, 0
+       mov r4, r3

Quoted 8 lines

arch/arm/mach-mb86s7x/smc.S line 24

Quoted 3 lines

arch/arm/mach-mb86s7x/smc.S new file +3 -0

+       and r3, #0xbfffffff
+       mcr p15, 0, r3, c1, c0, 0
+       smc #0

Interesting, it looks like you have some secure entity running on your platform.

Quoted 4 lines

Yes, we have a stub "secure firmware" that implements a few critical functions to allow us to operate the kernel as nonsecure. It's part of the bootloader for this platform which is also GPL'd.

OK, thanks for clarifying.

Quoted 9 lines

Quoted 2 lines

1. While the CPU is powered down who is taking care of saving it's state as you are doing it in the Linux itself ?

Nothing. The secure firmware is in a bootloader that is copied to and runs from secure sram. When the cpu is reset, he comes back up in secure mode and gets initialized in the secure firmware, before entering Non-secure mode and the kernel's secondary entry point.

So you do have live secure firmware stub on secure sram at any time, right ? When the CPUs are powered down especially for low power states, how is the secure state of the CPUs preserved ?

Quoted 8 lines

Quoted 1 line

2. Is Linux running in Secure or Non-secure mode ?

Another firmware (unfortunately not GPL) running on an on-die M3 informs the secure firmware on the AP whether he should set the AP cpu to nonsecure or not before jumping to the kernel... basically it's decided at runtime and the same kernel binary serves in both modes.

OK that's fine as along as you assume that kernel *always* runs in *non-secure* mode and never attempts any *secure access*.

Quoted 5 lines

Quoted 1 line

3. Why do you need this smc call for secondary boot only ?

The call sets the secondary entry point stored in the secure sram.

So IIUC, you run Linux in non-secure mode, PSCI would be more suitable than MCPM when you start thinking/implementing CPUIdle otherwise I think you will end up duplicating some logic(last man and race management) both in Linux as well as your secure firmware.

Quoted 1 line

The bootloader heuristic is if that's unset (0), and it's what the

This could be problem as when the CPU is hotplugged out, ideally it should be set to 0 to avoid spurious wakeup and entry into Linux.

Yes MCPM does manage it, but IMO you are mixing up secure and non-secure methods which might become issue later when implementing low power CPU states.

Quoted 4 lines

bootloader decided should be regarded as the primary cpu, then we do the real onetime cold boot flow, load the kernel etc. Non-primary cpus wait at WFI in the bootloader. When the primary cpu runs the code above, he sets the secondary entry point, and later starts to

I assume it's not done when primary boots, but by primary cpu when bringing up the secondaries.

Quoted 2 lines

bring up the other cores who jump to the secondary entry that was set.

I assume primary sends IPI to wake up secondaries, but if the SGIs are configured as secure, then it will _not_ be delivered. If not it *might*

work but I can't understand the need of running Linux non-secure with all secure access given to it.

Regards,
Sudeep

Quoted 4 lines · Sudeep Holla

So IIUC, you run Linux in non-secure mode, PSCI would be more suitable than MCPM when you start thinking/implementing CPUIdle otherwise I think you will end up duplicating some logic(last man and race management) both in Linux as well as your secure firmware.

As I mentioned our secure firmware is not what you're imagining.

MCPM works very well for us. Are you saying we can't use MCPM and must reimplement with PSCI on both sides?

Quoted 67 lines · Sudeep Holla

Quoted 47 lines · Andy Green

Quoted 34 lines · Sudeep Holla

Quoted 33 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

arch/arm/mach-mb86s7x/smc.S new file +21 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+       stmfd   sp!, {r1-r11, lr}
+       mov r1, r0
+       ldr r0, =1
+       mrc p15, 0, r3, c1, c0, 0
+       mov r4, r3

Quoted 8 lines

arch/arm/mach-mb86s7x/smc.S line 24

Quoted 3 lines

arch/arm/mach-mb86s7x/smc.S new file +3 -0

+       and r3, #0xbfffffff
+       mcr p15, 0, r3, c1, c0, 0
+       smc #0

Interesting, it looks like you have some secure entity running on your platform.

Quoted 4 lines

Yes, we have a stub "secure firmware" that implements a few critical functions to allow us to operate the kernel as nonsecure. It's part of the bootloader for this platform which is also GPL'd.

OK, thanks for clarifying.

Quoted 9 lines

Quoted 2 lines

1. While the CPU is powered down who is taking care of saving it's state as you are doing it in the Linux itself ?

Nothing. The secure firmware is in a bootloader that is copied to and runs from secure sram. When the cpu is reset, he comes back up in secure mode and gets initialized in the secure firmware, before entering Non-secure mode and the kernel's secondary entry point.

Quoted 3 lines

So you do have live secure firmware stub on secure sram at any time, right ? When the CPUs are powered down especially for low power states, how is the secure state of the CPUs preserved ?

There isn't any 'secure state' like you are thinking.

Our secure firmware is a rudimentary stub that provides a handful of stateless secure services to the kernel.

There's nothing to save or restore.

Quoted 11 lines

Quoted 8 lines

Quoted 1 line

2. Is Linux running in Secure or Non-secure mode ?

Another firmware (unfortunately not GPL) running on an on-die M3 informs the secure firmware on the AP whether he should set the AP cpu to nonsecure or not before jumping to the kernel... basically it's decided at runtime and the same kernel binary serves in both modes.

OK that's fine as along as you assume that kernel *always* runs in *non-secure* mode and never attempts any *secure access*.

Yes that's how it's set up.

When this M3 tells the bootloader to make us nonsecure before going to the kernel, he marks up all the IPs that have dynamic access control to allow access in nonsecure. That's because we have complete BSP support out of tree and we want to prove that it can all work from nonsecure directly.

When Fujitsu want to restrict an IP from nonsecure access for a particular customer they will add support to manage the IP either on the M3 or the AP secure firmware and disable the IP support in DT. But that does not exist yet.

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

3. Why do you need this smc call for secondary boot only ?

The call sets the secondary entry point stored in the secure sram.

Quoted 4 lines

So IIUC, you run Linux in non-secure mode, PSCI would be more suitable than MCPM when you start thinking/implementing CPUIdle otherwise I think you will end up duplicating some logic(last man and race management) both in Linux as well as your secure firmware.

As I mentioned our secure firmware is not what you're imagining.

MCPM works very well for us. Are you saying we can't use MCPM and must reimplement with PSCI on both sides?

Quoted 5 lines

Quoted 1 line

The bootloader heuristic is if that's unset (0), and it's what the

This could be problem as when the CPU is hotplugged out, ideally it should be set to 0 to avoid spurious wakeup and entry into Linux.

... I think you are talking about something else.

This is a PA stored in secure SRAM that holds the kernel's secondary entry point. It's 0 when the bootloader is copied to the secure SRAM by the M3 at cold reset. If anybody set it, it means Linux booted.

The M3 manages AP core state and either depowers the cluster or holds them in reset. So there can be no 'spurious wakeup and entry into Linux'.

Quoted 3 lines

Yes MCPM does manage it, but IMO you are mixing up secure and non-secure methods which might become issue later when implementing low power CPU states.

Can you explain where you see the problem? All we are doing is storing the kernel secondary entry point. The bootloader / secure firmware always receives any started core first and decides when and how to jump to it.

Quoted 6 lines

Quoted 4 lines

bootloader decided should be regarded as the primary cpu, then we do the real onetime cold boot flow, load the kernel etc. Non-primary cpus wait at WFI in the bootloader. When the primary cpu runs the code above, he sets the secondary entry point, and later starts to

Quoted 2 lines

I assume it's not done when primary boots, but by primary cpu when bringing up the secondaries.

Yes the point is the primary sets the secondary entry at the secure firmware using the SMC and then the IPIs can start flying.

Quoted 5 lines

Quoted 2 lines

bring up the other cores who jump to the secondary entry that was set.

I assume primary sends IPI to wake up secondaries, but if the SGIs are configured as secure, then it will _not_ be delivered. If not it *might*

Well, it is coordinated between M3 and AP bootloader / secure firmware if we should run nonsecure or not, and it configures a bunch of stuff like GIC accordingly so it works. And it does work.

Quoted 2 lines

work but I can't understand the need of running Linux non-secure with all secure access given to it.

Fujitsu's goal with this was confirm the SoC + kernel can work in nonsecure for the whole BSP stack. Then as customers want particular IPs secure-only, implement the behaviour they need in the AP secure firmware or M3. But as yet, no support for that is implemented.

Quoted 83 lines · Andy Green

Quoted 74 lines · Sudeep Holla

Quoted 52 lines · Andy Green

Quoted 37 lines · Sudeep Holla

Quoted 36 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

arch/arm/mach-mb86s7x/smc.S new file +6 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or

modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */

arch/arm/mach-mb86s7x/smc.S new file +13 -0

+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+       stmfd   sp!, {r1-r11, lr}
+       mov r1, r0
+       ldr r0, =1
+       mrc p15, 0, r3, c1, c0, 0
+       mov r4, r3
+       and r3, #0xbfffffff

Quoted 8 lines

arch/arm/mach-mb86s7x/smc.S line 24

Quoted 2 lines

arch/arm/mach-mb86s7x/smc.S new file +2 -0

+       mcr p15, 0, r3, c1, c0, 0
+       smc #0

Interesting, it looks like you have some secure entity running on your platform.

Quoted 4 lines

Yes, we have a stub "secure firmware" that implements a few critical functions to allow us to operate the kernel as nonsecure. It's part of the bootloader for this platform which is also GPL'd.

OK, thanks for clarifying.

Quoted 10 lines

Quoted 2 lines

1. While the CPU is powered down who is taking care of saving it's state as you are doing it in the Linux itself ?

Nothing. The secure firmware is in a bootloader that is copied to and runs from secure sram. When the cpu is reset, he comes back up in secure mode and gets initialized in the secure firmware, before entering Non-secure mode and the kernel's secondary entry point.

Quoted 3 lines

So you do have live secure firmware stub on secure sram at any time, right ? When the CPUs are powered down especially for low power states, how is the secure state of the CPUs preserved ?

There isn't any 'secure state' like you are thinking.

Quoted 5 lines

Our secure firmware is a rudimentary stub that provides a handful of stateless secure services to the kernel.

There's nothing to save or restore.

Ok that clarifies, but I assume some customers would like to extend that beyond the stub.

Quoted 22 lines

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

2. Is Linux running in Secure or Non-secure mode ?

Quoted 8 lines

Quoted 5 lines

Another firmware (unfortunately not GPL) running on an on-die M3 informs the secure firmware on the AP whether he should set the AP cpu to nonsecure or not before jumping to the kernel... basically it's decided at runtime and the same kernel binary serves in both modes.

OK that's fine as along as you assume that kernel *always* runs in *non-secure* mode and never attempts any *secure access*.

Yes that's how it's set up.

When this M3 tells the bootloader to make us nonsecure before going to the kernel, he marks up all the IPs that have dynamic access control to allow access in nonsecure. That's because we have complete BSP support out of tree and we want to prove that it can all work from nonsecure directly.

Quoted 5 lines

When Fujitsu want to restrict an IP from nonsecure access for a particular customer they will add support to manage the IP either on the M3 or the AP secure firmware and disable the IP support in DT. But that does not exist yet.

Yes this was what I was trying to tell. From what I understand now, if the customer implements secure firmware which might need to save and restore the state, then he needs to manage.(He might end up with

duplication of this last man algorithm in the secure firmware too, I was just trying to mention this)

Quoted 13 lines

Quoted 11 lines

Quoted 6 lines

Quoted 1 line

3. Why do you need this smc call for secondary boot only ?

The call sets the secondary entry point stored in the secure sram.

So IIUC, you run Linux in non-secure mode, PSCI would be more suitable than MCPM when you start thinking/implementing CPUIdle otherwise I think you will end up duplicating some logic(last man and race management) both in Linux as well as your secure firmware.

Quoted 2 lines

As I mentioned our secure firmware is not what you're imagining.

Understood, that?s about the current stub secure firmware and I was talking about non-existent full blown secure firmware. If that's not the case, then it's fine.

Quoted 3 lines

MCPM works very well for us. Are you saying we can't use MCPM and must reimplement with PSCI on both sides?

No I never said that, I wanted to understand what's the scope of your or any secure firmware of your customer.

Quoted 10 lines

Quoted 6 lines

Quoted 1 line

The bootloader heuristic is if that's unset (0), and it's what the

This could be problem as when the CPU is hotplugged out, ideally it should be set to 0 to avoid spurious wakeup and entry into Linux.

... I think you are talking about something else.

Quoted 8 lines

This is a PA stored in secure SRAM that holds the kernel's secondary entry point. It's 0 when the bootloader is copied to the secure SRAM by the M3 at cold reset. If anybody set it, it means Linux booted.

The M3 manages AP core state and either depowers the cluster or holds them in reset. So there can be no 'spurious wakeup and entry into Linux'.

Ok, good that you can guarantee that.

Quoted 21 lines

Quoted 3 lines

Yes MCPM does manage it, but IMO you are mixing up secure and non-secure methods which might become issue later when implementing low power CPU states.

Can you explain where you see the problem? All we are doing is storing the kernel secondary entry point. The bootloader / secure firmware always receives any started core first and decides when and how to jump to it.

Quoted 9 lines

Quoted 4 lines

bootloader decided should be regarded as the primary cpu, then we do the real onetime cold boot flow, load the kernel etc. Non-primary cpus wait at WFI in the bootloader. When the primary cpu runs the code above, he sets the secondary entry point, and later starts to

I assume it's not done when primary boots, but by primary cpu when bringing up the secondaries.

Quoted 3 lines

Yes the point is the primary sets the secondary entry at the secure firmware using the SMC and then the IPIs can start flying.

Only if GIC is properly configured for that though I don't see the point in giving non-secure entity secure access. If any secure firmware wants to change that in future that could be issue.

Quoted 15 lines

Quoted 5 lines

Quoted 2 lines

bring up the other cores who jump to the secondary entry that was set.

I assume primary sends IPI to wake up secondaries, but if the SGIs are configured as secure, then it will _not_ be delivered. If not it *might*

Well, it is coordinated between M3 and AP bootloader / secure firmware if we should run nonsecure or not, and it configures a bunch of stuff like GIC accordingly so it works. And it does work.

Quoted 2 lines

work but I can't understand the need of running Linux non-secure with all secure access given to it.

Quoted 5 lines

Fujitsu's goal with this was confirm the SoC + kernel can work in nonsecure for the whole BSP stack. Then as customers want particular IPs secure-only, implement the behaviour they need in the AP secure firmware or M3. But as yet, no support for that is implemented.

I never said you *must implement* PSCI and *not use* MCPM. Since you

mentioned that you will be providing option to run Linux in non-secure mode, which means there can be _secure_entity_ which does more than your current stub, I just wanted to mention the possible issues you may need to resolve then.

Regards,
Sudeep

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   2 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 3 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)	+= board.o
+obj-$(CONFIG_ARCH_MB86S7X)	+= board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +63 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:	(C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:	(C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER	2
+#define S7X_MAX_CPU	2
+
+#define MHU_SHM_OFFSET		0x3800
+#define WFI_COLOR_OFFSET	0x3f00
+#define TRAMPOLINE_OFFSET	0x3c00
+#define RESET_OFFSET		(TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING	0x0
+#define AT_WFI_DO_SUSPEND	0x1
+#define AT_WFI_DO_POWEROFF	0x2
+#define AT_WFI_COLOR_MASK	0x3
+
+struct mb86s7x_cpu_gate {
+	u32 payload_size;
+	u32 cluster_class;
+	u32 cluster_id;
+	u32 cpu_id;
+#define SCB_CPU_STATE_OFF	0x0
+#define SCB_CPU_STATE_ON	0x1
+#define SCB_CPU_STATE_SUSP	0x2
+	u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+	outer_flush_all();
+}

arch/arm/mach-mb86s7x/mcpm.c new file +7 -0

+	"mrc	p15, 0, r0, c1, c0, 1   @ get ACTLR\n\t" \
+	"bic	r0, r0, #(1 << 6)       @ disable local coherency\n\t" \
+	"mcr	p15, 0, r0, c1, c0, 1   @ set ACTLR\n\t" \
+	"isb\n\t" \
+	"dsb\n\t" \
+	"ldmfd	sp!, {fp, ip}" \
+		: : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", \

arch/arm/mach-mb86s7x/mcpm.c new file +28 -0

+
+	val = readb_relaxed(mb86s7x_shm_base
+			    + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+	val &= ~AT_WFI_COLOR_MASK;
+	val |= clr;
+	writeb_relaxed(val, mb86s7x_shm_base
+		       + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+}
+
+static int mb86s7x_pm_power_up(unsigned int cpu, unsigned int cluster)
+{
+	int ret = 0;
+
+	if (cluster >= S7X_MAX_CLUSTER || cpu >= S7X_MAX_CPU)
+		return -EINVAL;
+
+	pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+
+	local_irq_disable();
+	arch_spin_lock(&mb86s7x_pm_lock);
+
+	mb86s7x_pm_use_count[cluster][cpu]++;
+
+	if (mb86s7x_pm_use_count[cluster][cpu] == 1) {
+		struct mb86s7x_cpu_gate cmd;
+
+		arch_spin_unlock(&mb86s7x_pm_lock);
+		local_irq_enable();

From that point onward, nothing prevents concurrent execution in

arch/arm/mach-mb86s7x/mcpm.c new file +104 -0

+		cmd.payload_size = sizeof(cmd);
+		cmd.cluster_class = 0;
+		cmd.cluster_id = cluster;
+		cmd.cpu_id = cpu;
+		cmd.cpu_state = SCB_CPU_STATE_ON;
+
+		pr_debug("%s:%d CMD Cl_Class-%u CL_ID-%u CPU_ID-%u STATE-%u}\n",
+			 __func__, __LINE__, cmd.cluster_class,
+			 cmd.cluster_id, cmd.cpu_id, cmd.cpu_state);
+
+		mb86s7x_set_wficolor(cluster, cpu, AT_WFI_DO_NOTHING);
+		ret = mb86s7x_send_packet(CMD_CPU_CLOCK_GATE_SET_REQ,
+					  &cmd, sizeof(cmd));
+		if (ret < 0) {
+			pr_err("%s:%d failed!\n", __func__, __LINE__);
+			return ret;
+		}
+
+		pr_debug("%s:%d REP Cl_Class-%u CL_ID-%u CPU_ID-%u STATE-%u}\n",
+			 __func__, __LINE__, cmd.cluster_class,
+			 cmd.cluster_id, cmd.cpu_id, cmd.cpu_state);
+
+		if (cmd.cpu_state != SCB_CPU_STATE_ON)
+			return -ENODEV;
+	} else if (mb86s7x_pm_use_count[cluster][cpu] != 2) {
+		/*
+		 * The only possible values are:
+		 * 0 = CPU down
+		 * 1 = CPU (still) up
+		 * 2 = CPU requested to be up before it had a chance
+		 *     to actually make itself down.
+		 * Any other value is a bug.
+		 */
+		BUG();
+	}
+
+	return 0;
+}
+
+static void mb86s7x_pm_suspend(u64 ignored)
+{
+	unsigned int mpidr, cpu, cluster;
+	bool last_man = false, skip_wfi = false;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+	pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+	__mcpm_cpu_going_down(cpu, cluster);
+
+	arch_spin_lock(&mb86s7x_pm_lock);
+	BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
+
+	mb86s7x_pm_use_count[cluster][cpu]--;
+
+	if (mb86s7x_pm_use_count[cluster][cpu] == 0) {
+		if (!mb86s7x_pm_use_count[cluster][0] &&
+		    !mb86s7x_pm_use_count[cluster][1])
+			last_man = true;
+		mb86s7x_set_wficolor(cluster, cpu, AT_WFI_DO_POWEROFF);
+	} else if (mb86s7x_pm_use_count[cluster][cpu] == 1) {
+		skip_wfi = true; /* Overtaken by a power up */
+	} else {
+		BUG();
+	}
+
+	if (!skip_wfi)
+		gic_cpu_if_down();
+
+	if (last_man && __mcpm_outbound_enter_critical(cpu, cluster)) {
+		arch_spin_unlock(&mb86s7x_pm_lock);
+
+		if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A15) {
+			/*
+			 * On the Cortex-A15 we need to disable
+			 * L2 prefetching before flushing the cache.
+			 */
+			asm volatile(
+			"mcr p15, 1, %0, c15, c0, 3\n\t"
+			"isb\n\t"
+			"dsb"
+			: : "r" (0x400));
+		}
+
+		mb86s70evb_exit_coherency_flush(all);
+
+		cci_disable_port_by_cpu(mpidr);
+
+		__mcpm_outbound_leave_critical(cluster, CLUSTER_DOWN);
+	} else {
+		arch_spin_unlock(&mb86s7x_pm_lock);
+		mb86s70evb_exit_coherency_flush(louis);
+	}
+
+	__mcpm_cpu_down(cpu, cluster);
+
+	/* Now we are prepared for power-down, do it: */
+	if (!skip_wfi)
+		wfi();
+}
+
+static void mb86s7x_pm_power_down(void)
+{

arch/arm/mach-mb86s7x/mcpm.c new file +127 -0

+	cmd.payload_size = sizeof(cmd);
+	cmd.cluster_class = 0;
+	cmd.cluster_id = cluster;
+	cmd.cpu_id = cpu;
+	cmd.cpu_state = SCB_CPU_STATE_ON;
+
+	for (i = 0; i < 50; i++) {
+		ret = mb86s7x_send_packet(CMD_CPU_CLOCK_GATE_GET_REQ,
+					  &cmd, sizeof(cmd));
+		if (ret < 0) {
+			pr_err("%s:%d failed to get CPU status\n",
+			       __func__, __LINE__);
+			return ret;
+		}
+
+		pr_debug("%s:%d Cl_Class-%u CL_ID-%u CPU_ID-%u STATE-%u\n",
+			 __func__, __LINE__,
+			 cmd.cluster_class, cmd.cluster_id,
+			 cmd.cpu_id, cmd.cpu_state);
+
+		if (cmd.cpu_state == SCB_CPU_STATE_OFF)
+			return 0;
+
+		msleep(20);
+	}
+
+	return -ETIMEDOUT;
+}
+
+static void mb86s7x_pm_powered_up(void)
+{
+	unsigned int mpidr, cpu, cluster;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+	arch_spin_lock(&mb86s7x_pm_lock);
+	if (!mb86s7x_pm_use_count[cluster][cpu])
+		mb86s7x_pm_use_count[cluster][cpu] = 1;
+	arch_spin_unlock(&mb86s7x_pm_lock);
+}
+
+static const struct mcpm_platform_ops mb86s7x_pm_power_ops = {
+	.power_up		= mb86s7x_pm_power_up,
+	.power_down		= mb86s7x_pm_power_down,
+	.wait_for_powerdown	= mb86s7x_wait_for_powerdown,
+	.suspend		= mb86s7x_pm_suspend,
+	.powered_up		= mb86s7x_pm_powered_up,
+};
+
+/*
+ * Enable cluster-level coherency, in preparation for turning on the MMU.
+ */
+static void __naked mb86s7x_pm_power_up_setup(unsigned int affinity_level)
+{
+	asm volatile ("\n"
+"	cmp	r0, #1\n"
+"	bxne	lr\n"
+"	b	cci_enable_port_for_self");
+}
+
+static void __init mb86s7x_cache_off(void)
+{
+	if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A15) {
+		/* disable L2 prefetching on the Cortex-A15 */
+		asm volatile(
+		"mcr	p15, 1, %0, c15, c0, 3\n\t"
+		"isb\n\t"
+		"dsb"
+		: : "r" (0x400));
+	}
+	mb86s70evb_exit_coherency_flush(all);
+}
+
+struct mb86s7x_scb_version {
+	u32 payload_size;
+	u32 version;
+	u32 config_version;
+};
+
+extern void mb86s7x_cpu_entry(unsigned long secondary_entry);
+
+static int __init mb86s7x_mcpm_init(void)
+{
+	unsigned int mpidr, cpu, cluster;
+	struct mb86s7x_scb_version cmd;
+	int ret;
+
+	if (!cci_probed())
+		return -ENODEV;
+
+	mpidr = read_cpuid_mpidr();
+	cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+	cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+	pr_info("Booting on cpu_%u cluster_%u\n", cpu, cluster);
+	mb86s7x_pm_use_count[cluster][cpu] = 1;
+
+	/* reset the wfi 'color' for primary cpu */
+	mb86s7x_set_wficolor(cluster, cpu, AT_WFI_DO_NOTHING);
+
+	/* Do SMC to set entry address for CPUs coming online */
+	mb86s7x_cpu_entry(virt_to_phys(mcpm_entry_point));
+
+	cmd.payload_size = sizeof(cmd);
+	cmd.version = 0;
+	cmd.config_version = 0;
+	ret = mb86s7x_send_packet(CMD_SCB_CAPABILITY_GET_REQ,
+				  &cmd, sizeof(cmd));
+	if (ret < 0)
+		pr_err("%s:%d failed to get SCB version\n",
+		       __func__, __LINE__);
+
+	pr_info("MB86S7x MCPM initialized: SCB version 0x%x:0x%x\n",
+		cmd.version, cmd.config_version);
+
+	ret = mcpm_platform_register(&mb86s7x_pm_power_ops);
+	if (!ret)
+		ret = mcpm_sync_init(mb86s7x_pm_power_up_setup);
+	if (!ret)
+		ret = mcpm_loopback(mb86s7x_cache_off); /* turn on the CCI */
+	mcpm_smp_set_ops();
+
+	return ret;
+}
+early_initcall(mb86s7x_mcpm_init);

arch/arm/mach-mb86s7x/smc.S new file +27 -0

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+	stmfd   sp!, {r1-r11, lr}
+	mov r1, r0
+	ldr r0, =1
+	mrc p15, 0, r3, c1, c0, 0
+	mov r4, r3
+	and r3, #0xbfffffff
+	mcr p15, 0, r3, c1, c0, 0
+	smc #0
+	mcr p15, 0, r4, c1, c0, 0
+	ldmfd   sp!, {r1-r11, pc}
+ENDPROC(mb86s7x_cpu_entry)

Signature · 1 line

1.9.0

Quoted 96 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
  arch/arm/mach-mb86s7x/Makefile |   2 +-
  arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-mb86s7x/smc.S    |  27 ++++
  3 files changed, 388 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +68 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:        (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:        (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER      2
+#define S7X_MAX_CPU  2
+
+#define MHU_SHM_OFFSET               0x3800
+#define WFI_COLOR_OFFSET     0x3f00
+#define TRAMPOLINE_OFFSET    0x3c00
+#define RESET_OFFSET         (TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING    0x0
+#define AT_WFI_DO_SUSPEND    0x1
+#define AT_WFI_DO_POWEROFF   0x2
+#define AT_WFI_COLOR_MASK    0x3
+
+struct mb86s7x_cpu_gate {
+     u32 payload_size;
+     u32 cluster_class;
+     u32 cluster_id;
+     u32 cpu_id;
+#define SCB_CPU_STATE_OFF    0x0
+#define SCB_CPU_STATE_ON     0x1
+#define SCB_CPU_STATE_SUSP   0x2
+     u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}
+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 5 lines

arch/arm/mach-mb86s7x/mcpm.c new file +5 -0

+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

Quoted 100 lines · Nicolas Pitre

Quoted 98 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
  arch/arm/mach-mb86s7x/Makefile |   2 +-
  arch/arm/mach-mb86s7x/mcpm.c   | 360
  +++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-mb86s7x/smc.S    |  27 ++++
  3 files changed, 388 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +68 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:        (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:        (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER      2
+#define S7X_MAX_CPU  2
+
+#define MHU_SHM_OFFSET               0x3800
+#define WFI_COLOR_OFFSET     0x3f00
+#define TRAMPOLINE_OFFSET    0x3c00
+#define RESET_OFFSET         (TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING    0x0
+#define AT_WFI_DO_SUSPEND    0x1
+#define AT_WFI_DO_POWEROFF   0x2
+#define AT_WFI_COLOR_MASK    0x3
+
+struct mb86s7x_cpu_gate {
+     u32 payload_size;
+     u32 cluster_class;
+     u32 cluster_id;
+     u32 cpu_id;
+#define SCB_CPU_STATE_OFF    0x0
+#define SCB_CPU_STATE_ON     0x1
+#define SCB_CPU_STATE_SUSP   0x2
+     u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}
+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \

Quoted 9 lines

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 5 lines

arch/arm/mach-mb86s7x/mcpm.c new file +5 -0

+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

IIUC the external/outer cache needs to be flushed only if it's last cluster going down. It would be suboptimal to flush it when one cluster is going down while other is still active. So it's not always correct for even "all" case too.

Quoted 96 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   2 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 3 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +68 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:        (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:        (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER      2
+#define S7X_MAX_CPU  2
+
+#define MHU_SHM_OFFSET               0x3800
+#define WFI_COLOR_OFFSET     0x3f00
+#define TRAMPOLINE_OFFSET    0x3c00
+#define RESET_OFFSET         (TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING    0x0
+#define AT_WFI_DO_SUSPEND    0x1
+#define AT_WFI_DO_POWEROFF   0x2
+#define AT_WFI_COLOR_MASK    0x3
+
+struct mb86s7x_cpu_gate {
+     u32 payload_size;
+     u32 cluster_class;
+     u32 cluster_id;
+     u32 cpu_id;
+#define SCB_CPU_STATE_OFF    0x0
+#define SCB_CPU_STATE_ON     0x1
+#define SCB_CPU_STATE_SUSP   0x2
+     u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}
+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 5 lines

arch/arm/mach-mb86s7x/mcpm.c new file +5 -0

+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

Furthermore, the safety of this macro is ensured by not having any memory writes in the middle of the whole sequence. By calling mb86s70evb_outer_flush_all() there could be the return address pushed onto the stack before calling outer_flush_all() if some tail call optimization is not applied. And this is without saying what outer_flush_all() actually does.

Why can't you simply do this instead:

        v7_exit_coherency_flush(all);
        outer_flush_all();

Of course you'll have to audit everything in the outer_flush_all() path to make sure no atomic instructions such as LDREX/STREX are invoked. Those have undefined behavior after CR_C is cleared.

Quoted 8 lines

arch/arm/mach-mb86s7x/mcpm.c new file +7 -0

+     "mrc    p15, 0, r0, c1, c0, 1   @ get ACTLR\n\t" \
+     "bic    r0, r0, #(1 << 6)       @ disable local coherency\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 1   @ set ACTLR\n\t" \
+     "isb\n\t" \
+     "dsb\n\t" \
+     "ldmfd  sp!, {fp, ip}" \
+             : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", \

arch/arm/mach-mb86s7x/mcpm.c line 90

Quoted 10 lines

arch/arm/mach-mb86s7x/mcpm.c new file +10 -0

+             "r9", "r10", "lr", "memory"); \
+     }
+
+static void
+mb86s7x_set_wficolor(unsigned clstr, unsigned cpu, unsigned clr)
+{
+     u8 val;
+
+     if (clr & ~AT_WFI_COLOR_MASK)
+             return;

Shouldn't this be a BUG() rather than a return?

Quoted 18 lines

arch/arm/mach-mb86s7x/mcpm.c new file +18 -0

+
+     val = readb_relaxed(mb86s7x_shm_base
+                         + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+     val &= ~AT_WFI_COLOR_MASK;
+     val |= clr;
+     writeb_relaxed(val, mb86s7x_shm_base
+                    + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+}
+
+static int mb86s7x_pm_power_up(unsigned int cpu, unsigned int cluster)
+{
+     int ret = 0;
+
+     if (cluster >= S7X_MAX_CLUSTER || cpu >= S7X_MAX_CPU)
+             return -EINVAL;
+
+     pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+

arch/arm/mach-mb86s7x/mcpm.c line 118

Quoted 10 lines

arch/arm/mach-mb86s7x/mcpm.c new file +10 -0

+     local_irq_disable();
+     arch_spin_lock(&mb86s7x_pm_lock);
+
+     mb86s7x_pm_use_count[cluster][cpu]++;
+
+     if (mb86s7x_pm_use_count[cluster][cpu] == 1) {
+             struct mb86s7x_cpu_gate cmd;
+
+             arch_spin_unlock(&mb86s7x_pm_lock);
+             local_irq_enable();

From that point onward, nothing prevents concurrent execution in mb86s7x_pm_suspend() racing to call mb86s7x_set_wficolor() resulting in an incoherent state depending on who wins the race.

Quoted 104 lines

arch/arm/mach-mb86s7x/mcpm.c new file +104 -0

+             cmd.payload_size = sizeof(cmd);
+             cmd.cluster_class = 0;
+             cmd.cluster_id = cluster;
+             cmd.cpu_id = cpu;
+             cmd.cpu_state = SCB_CPU_STATE_ON;
+
+             pr_debug("%s:%d CMD Cl_Class-%u CL_ID-%u CPU_ID-%u STATE-%u}\n",
+                      __func__, __LINE__, cmd.cluster_class,
+                      cmd.cluster_id, cmd.cpu_id, cmd.cpu_state);
+
+             mb86s7x_set_wficolor(cluster, cpu, AT_WFI_DO_NOTHING);
+             ret = mb86s7x_send_packet(CMD_CPU_CLOCK_GATE_SET_REQ,
+                                       &cmd, sizeof(cmd));
+             if (ret < 0) {
+                     pr_err("%s:%d failed!\n", __func__, __LINE__);
+                     return ret;
+             }
+
+             pr_debug("%s:%d REP Cl_Class-%u CL_ID-%u CPU_ID-%u STATE-%u}\n",
+                      __func__, __LINE__, cmd.cluster_class,
+                      cmd.cluster_id, cmd.cpu_id, cmd.cpu_state);
+
+             if (cmd.cpu_state != SCB_CPU_STATE_ON)
+                     return -ENODEV;
+     } else if (mb86s7x_pm_use_count[cluster][cpu] != 2) {
+             /*
+              * The only possible values are:
+              * 0 = CPU down
+              * 1 = CPU (still) up
+              * 2 = CPU requested to be up before it had a chance
+              *     to actually make itself down.
+              * Any other value is a bug.
+              */
+             BUG();
+     }
+
+     return 0;
+}
+
+static void mb86s7x_pm_suspend(u64 ignored)
+{
+     unsigned int mpidr, cpu, cluster;
+     bool last_man = false, skip_wfi = false;
+
+     mpidr = read_cpuid_mpidr();
+     cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+     cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+     pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+     __mcpm_cpu_going_down(cpu, cluster);
+
+     arch_spin_lock(&mb86s7x_pm_lock);
+     BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
+
+     mb86s7x_pm_use_count[cluster][cpu]--;
+
+     if (mb86s7x_pm_use_count[cluster][cpu] == 0) {
+             if (!mb86s7x_pm_use_count[cluster][0] &&
+                 !mb86s7x_pm_use_count[cluster][1])
+                     last_man = true;
+             mb86s7x_set_wficolor(cluster, cpu, AT_WFI_DO_POWEROFF);
+     } else if (mb86s7x_pm_use_count[cluster][cpu] == 1) {
+             skip_wfi = true; /* Overtaken by a power up */
+     } else {
+             BUG();
+     }
+
+     if (!skip_wfi)
+             gic_cpu_if_down();
+
+     if (last_man && __mcpm_outbound_enter_critical(cpu, cluster)) {
+             arch_spin_unlock(&mb86s7x_pm_lock);
+
+             if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A15) {
+                     /*
+                      * On the Cortex-A15 we need to disable
+                      * L2 prefetching before flushing the cache.
+                      */
+                     asm volatile(
+                     "mcr p15, 1, %0, c15, c0, 3\n\t"
+                     "isb\n\t"
+                     "dsb"
+                     : : "r" (0x400));
+             }
+
+             mb86s70evb_exit_coherency_flush(all);
+
+             cci_disable_port_by_cpu(mpidr);
+
+             __mcpm_outbound_leave_critical(cluster, CLUSTER_DOWN);
+     } else {
+             arch_spin_unlock(&mb86s7x_pm_lock);
+             mb86s70evb_exit_coherency_flush(louis);
+     }
+
+     __mcpm_cpu_down(cpu, cluster);
+
+     /* Now we are prepared for power-down, do it: */
+     if (!skip_wfi)
+             wfi();
+}
+
+static void mb86s7x_pm_power_down(void)
+{

arch/arm/mach-mb86s7x/mcpm.c line 232

Quoted 10 lines

arch/arm/mach-mb86s7x/mcpm.c new file +10 -0

+     mb86s7x_pm_suspend(0);
+}
+
+static int mb86s7x_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
+{
+     struct mb86s7x_cpu_gate cmd;
+     int i, ret;
+
+     if (cluster >= S7X_MAX_CLUSTER || cpu >= S7X_MAX_CPU)
+             return 0;

This should return an error or BUG().

Quoted 161 lines

arch/arm/mach-mb86s7x/mcpm.c new file +127 -0

+     cmd.payload_size = sizeof(cmd);
+     cmd.cluster_class = 0;
+     cmd.cluster_id = cluster;
+     cmd.cpu_id = cpu;
+     cmd.cpu_state = SCB_CPU_STATE_ON;
+
+     for (i = 0; i < 50; i++) {
+             ret = mb86s7x_send_packet(CMD_CPU_CLOCK_GATE_GET_REQ,
+                                       &cmd, sizeof(cmd));
+             if (ret < 0) {
+                     pr_err("%s:%d failed to get CPU status\n",
+                            __func__, __LINE__);
+                     return ret;
+             }
+
+             pr_debug("%s:%d Cl_Class-%u CL_ID-%u CPU_ID-%u STATE-%u\n",
+                      __func__, __LINE__,
+                      cmd.cluster_class, cmd.cluster_id,
+                      cmd.cpu_id, cmd.cpu_state);
+
+             if (cmd.cpu_state == SCB_CPU_STATE_OFF)
+                     return 0;
+
+             msleep(20);
+     }
+
+     return -ETIMEDOUT;
+}
+
+static void mb86s7x_pm_powered_up(void)
+{
+     unsigned int mpidr, cpu, cluster;
+
+     mpidr = read_cpuid_mpidr();
+     cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+     cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+     arch_spin_lock(&mb86s7x_pm_lock);
+     if (!mb86s7x_pm_use_count[cluster][cpu])
+             mb86s7x_pm_use_count[cluster][cpu] = 1;
+     arch_spin_unlock(&mb86s7x_pm_lock);
+}
+
+static const struct mcpm_platform_ops mb86s7x_pm_power_ops = {
+     .power_up               = mb86s7x_pm_power_up,
+     .power_down             = mb86s7x_pm_power_down,
+     .wait_for_powerdown     = mb86s7x_wait_for_powerdown,
+     .suspend                = mb86s7x_pm_suspend,
+     .powered_up             = mb86s7x_pm_powered_up,
+};
+
+/*
+ * Enable cluster-level coherency, in preparation for turning on the MMU.
+ */
+static void __naked mb86s7x_pm_power_up_setup(unsigned int affinity_level)
+{
+     asm volatile ("\n"
+"    cmp     r0, #1\n"
+"    bxne    lr\n"
+"    b       cci_enable_port_for_self");
+}
+
+static void __init mb86s7x_cache_off(void)
+{
+     if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A15) {
+             /* disable L2 prefetching on the Cortex-A15 */
+             asm volatile(
+             "mcr    p15, 1, %0, c15, c0, 3\n\t"
+             "isb\n\t"
+             "dsb"
+             : : "r" (0x400));
+     }
+     mb86s70evb_exit_coherency_flush(all);
+}
+
+struct mb86s7x_scb_version {
+     u32 payload_size;
+     u32 version;
+     u32 config_version;
+};
+
+extern void mb86s7x_cpu_entry(unsigned long secondary_entry);
+
+static int __init mb86s7x_mcpm_init(void)
+{
+     unsigned int mpidr, cpu, cluster;
+     struct mb86s7x_scb_version cmd;
+     int ret;
+
+     if (!cci_probed())
+             return -ENODEV;
+
+     mpidr = read_cpuid_mpidr();
+     cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+     cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+     pr_info("Booting on cpu_%u cluster_%u\n", cpu, cluster);
+     mb86s7x_pm_use_count[cluster][cpu] = 1;
+
+     /* reset the wfi 'color' for primary cpu */
+     mb86s7x_set_wficolor(cluster, cpu, AT_WFI_DO_NOTHING);
+
+     /* Do SMC to set entry address for CPUs coming online */
+     mb86s7x_cpu_entry(virt_to_phys(mcpm_entry_point));
+
+     cmd.payload_size = sizeof(cmd);
+     cmd.version = 0;
+     cmd.config_version = 0;
+     ret = mb86s7x_send_packet(CMD_SCB_CAPABILITY_GET_REQ,
+                               &cmd, sizeof(cmd));
+     if (ret < 0)
+             pr_err("%s:%d failed to get SCB version\n",
+                    __func__, __LINE__);
+
+     pr_info("MB86S7x MCPM initialized: SCB version 0x%x:0x%x\n",
+             cmd.version, cmd.config_version);
+
+     ret = mcpm_platform_register(&mb86s7x_pm_power_ops);
+     if (!ret)
+             ret = mcpm_sync_init(mb86s7x_pm_power_up_setup);
+     if (!ret)
+             ret = mcpm_loopback(mb86s7x_cache_off); /* turn on the CCI */
+     mcpm_smp_set_ops();
+
+     return ret;
+}
+early_initcall(mb86s7x_mcpm_init);

arch/arm/mach-mb86s7x/smc.S new file +27 -1

new file mode 100644
index 0000000..a14330b
@@ -0,0 +1,27 @@
+/*
+ * SMC command interface to set secondary entry point
+ * Copyright: (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright: (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+.arch_extension sec
+
+/* void mb86s7x_cpu_entry(unsigned long secondary_entry); */
+ENTRY(mb86s7x_cpu_entry)
+     stmfd   sp!, {r1-r11, lr}
+     mov r1, r0
+     ldr r0, =1
+     mrc p15, 0, r3, c1, c0, 0
+     mov r4, r3
+     and r3, #0xbfffffff
+     mcr p15, 0, r3, c1, c0, 0
+     smc #0
+     mcr p15, 0, r4, c1, c0, 0
+     ldmfd   sp!, {r1-r11, pc}
+ENDPROC(mb86s7x_cpu_entry)
--

Quoted 3 lines

1.9.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 98 lines · Nicolas Pitre

Quoted 96 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   2 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 3 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +68 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:        (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:        (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER      2
+#define S7X_MAX_CPU  2
+
+#define MHU_SHM_OFFSET               0x3800
+#define WFI_COLOR_OFFSET     0x3f00
+#define TRAMPOLINE_OFFSET    0x3c00
+#define RESET_OFFSET         (TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING    0x0
+#define AT_WFI_DO_SUSPEND    0x1
+#define AT_WFI_DO_POWEROFF   0x2
+#define AT_WFI_COLOR_MASK    0x3
+
+struct mb86s7x_cpu_gate {
+     u32 payload_size;
+     u32 cluster_class;
+     u32 cluster_id;
+     u32 cpu_id;
+#define SCB_CPU_STATE_OFF    0x0
+#define SCB_CPU_STATE_ON     0x1
+#define SCB_CPU_STATE_SUSP   0x2
+     u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}
+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \

Quoted 8 lines

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 5 lines

arch/arm/mach-mb86s7x/mcpm.c new file +5 -0

+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

Is this a bL system with unified and architected L2s ? I think so, so what's the outercache for ?

Quoted 7 lines

Furthermore, the safety of this macro is ensured by not having any memory writes in the middle of the whole sequence. By calling mb86s70evb_outer_flush_all() there could be the return address pushed onto the stack before calling outer_flush_all() if some tail call optimization is not applied. And this is without saying what outer_flush_all() actually does.

Quoted 8 lines

Why can't you simply do this instead:

        v7_exit_coherency_flush(all);
        outer_flush_all();

Of course you'll have to audit everything in the outer_flush_all() path to make sure no atomic instructions such as LDREX/STREX are invoked. Those have undefined behavior after CR_C is cleared.

What you are saying is correct but first of all I would like to understand what outercache we are talking about here.

Code snippet above is fragile, as you said, and I'd rather disable the outercache before executing the power down sequence (which implies cache is cleaned/invalidated and quiescent before we clear the C bit) if there is an outercache to be managed.

Quoted 130 lines · Lorenzo Pieralisi

Quoted 98 lines · Nicolas Pitre

Quoted 96 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
  arch/arm/mach-mb86s7x/Makefile |   2 +-
  arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
  arch/arm/mach-mb86s7x/smc.S    |  27 ++++
  3 files changed, 388 insertions(+), 1 deletion(-)

create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +68 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:        (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:        (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER      2
+#define S7X_MAX_CPU  2
+
+#define MHU_SHM_OFFSET               0x3800
+#define WFI_COLOR_OFFSET     0x3f00
+#define TRAMPOLINE_OFFSET    0x3c00
+#define RESET_OFFSET         (TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING    0x0
+#define AT_WFI_DO_SUSPEND    0x1
+#define AT_WFI_DO_POWEROFF   0x2
+#define AT_WFI_COLOR_MASK    0x3
+
+struct mb86s7x_cpu_gate {
+     u32 payload_size;
+     u32 cluster_class;
+     u32 cluster_id;
+     u32 cpu_id;
+#define SCB_CPU_STATE_OFF    0x0
+#define SCB_CPU_STATE_ON     0x1
+#define SCB_CPU_STATE_SUSP   0x2
+     u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}
+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \

Quoted 8 lines

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 5 lines

arch/arm/mach-mb86s7x/mcpm.c new file +5 -0

+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

Is this a bL system with unified and architected L2s ? I think so, so what's the outercache for ?

Quoted 7 lines

Furthermore, the safety of this macro is ensured by not having any memory writes in the middle of the whole sequence. By calling mb86s70evb_outer_flush_all() there could be the return address pushed onto the stack before calling outer_flush_all() if some tail call optimization is not applied. And this is without saying what outer_flush_all() actually does.

Quoted 8 lines

Why can't you simply do this instead:

         v7_exit_coherency_flush(all);
         outer_flush_all();

Of course you'll have to audit everything in the outer_flush_all() path to make sure no atomic instructions such as LDREX/STREX are invoked. Those have undefined behavior after CR_C is cleared.

What you are saying is correct but first of all I would like to understand what outercache we are talking about here.

Quoted 4 lines

Code snippet above is fragile, as you said, and I'd rather disable the outercache before executing the power down sequence (which implies cache is cleaned/invalidated and quiescent before we clear the C bit) if there is an outercache to be managed.

Good question. That opens the potential for an even simpler fix! ;-)

Quoted 98 lines · Nicolas Pitre

Quoted 96 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 arch/arm/mach-mb86s7x/Makefile |   2 +-
 arch/arm/mach-mb86s7x/mcpm.c   | 360 +++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-mb86s7x/smc.S    |  27 ++++
 3 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mb86s7x/mcpm.c
 create mode 100644 arch/arm/mach-mb86s7x/smc.S

arch/arm/mach-mb86s7x/Makefile +1 -1

index 97640b6..b0fa34b 100644
@@ -1 +1 @@
-obj-$(CONFIG_ARCH_MB86S7X)   += board.o
+obj-$(CONFIG_ARCH_MB86S7X)   += board.o mcpm.o smc.o

arch/arm/mach-mb86s7x/mcpm.c new file +68 -0

new file mode 100644
index 0000000..bf1b50a
@@ -0,0 +1,360 @@
+/*
+ * arch/arm/mach-mb86s7x/mcpm.c
+ * Copyright:        (C) 2013-2014 Fujitsu Semiconductor Limited
+ * Copyright:        (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/pm.h>
+#include <linux/delay.h>
+#include <linux/cpu_pm.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/arm-cci.h>
+#include <linux/spinlock.h>
+#include <linux/suspend.h>
+#include <linux/of_device.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/platform_device.h>
+
+#include <soc/mb86s7x/scb_mhu.h>
+
+#include <asm/mcpm.h>
+#include <asm/cp15.h>
+#include <asm/cputype.h>
+#include <asm/suspend.h>
+#include <asm/idmap.h>
+
+#define S7X_MAX_CLUSTER      2
+#define S7X_MAX_CPU  2
+
+#define MHU_SHM_OFFSET               0x3800
+#define WFI_COLOR_OFFSET     0x3f00
+#define TRAMPOLINE_OFFSET    0x3c00
+#define RESET_OFFSET         (TRAMPOLINE_OFFSET + 0x3fc)
+
+static arch_spinlock_t mb86s7x_pm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int mb86s7x_pm_use_count[S7X_MAX_CLUSTER][S7X_MAX_CPU];
+extern void __iomem *mb86s7x_shm_base;
+
+#define AT_WFI_DO_NOTHING    0x0
+#define AT_WFI_DO_SUSPEND    0x1
+#define AT_WFI_DO_POWEROFF   0x2
+#define AT_WFI_COLOR_MASK    0x3
+
+struct mb86s7x_cpu_gate {
+     u32 payload_size;
+     u32 cluster_class;
+     u32 cluster_id;
+     u32 cpu_id;
+#define SCB_CPU_STATE_OFF    0x0
+#define SCB_CPU_STATE_ON     0x1
+#define SCB_CPU_STATE_SUSP   0x2
+     u32 cpu_state;
+};
+
+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}
+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \

Quoted 8 lines

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 5 lines

arch/arm/mach-mb86s7x/mcpm.c new file +5 -0

+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

Is this a bL system with unified and architected L2s ? I think so, so what's the outercache for ?

Quoted 11 lines · Lorenzo Pieralisi

Quoted 10 lines · Nicolas Pitre

Quoted 8 lines · Vincent Yang

The remote firmware(SCB) owns the SMP control. This MCPM driver gets CPU/CLUSTER power up/down done by SCB over mailbox.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---

Quoted 18 lines

Quoted 17 lines

Quoted 4 lines

arch/arm/mach-mb86s7x/mcpm.c new file +4 -0

+asmlinkage void mb86s70evb_outer_flush_all(void)
+{
+     outer_flush_all();
+}

arch/arm/mach-mb86s7x/mcpm.c line 73

Quoted 10 lines

arch/arm/mach-mb86s7x/mcpm.c new file +10 -0

+
+#define mb86s70evb_exit_coherency_flush(level) { \
+     asm volatile( \
+     "stmfd  sp!, {fp, ip}\n\t" \
+     "mrc    p15, 0, r0, c1, c0, 0   @ get SCTLR\n\t" \
+     "bic    r0, r0, #"__stringify(CR_C)"\n\t" \
+     "mcr    p15, 0, r0, c1, c0, 0   @ set SCTLR\n\t" \
+     "isb\n\t" \
+     "bl     v7_flush_dcache_"__stringify(level)"\n\t" \
+     "bl     mb86s70evb_outer_flush_all\n\t" \

This is wrong. As mentioned already, this unconditionally flushes L2 in all cases which shouldn't be necessary in the "louis" case.

Quoted 3 lines

Is this a bL system with unified and architected L2s ? I think so, so what's the outercache for ?

Yes, the CA15 has 1MB and CA7 256KB L2 cache, that's it. This thing sneaked in via a patch from someone desperate to make Suspend-To-Ram (not yet submitted) work and I failed to spot it. We should remove the mb86s70evb_outer_flush_all()

arch/arm/mach-mb86s7x/mcpm.c line 90

Quoted 9 lines

arch/arm/mach-mb86s7x/mcpm.c new file +8 -0

+
+static void
+mb86s7x_set_wficolor(unsigned clstr, unsigned cpu, unsigned clr)
+{
+     u8 val;
+
+     if (clr & ~AT_WFI_COLOR_MASK)
+             return;

Shouldn't this be a BUG() rather than a return?

Quoted 24 lines

arch/arm/mach-mb86s7x/mcpm.c new file +24 -0

+
+     val = readb_relaxed(mb86s7x_shm_base
+                         + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+     val &= ~AT_WFI_COLOR_MASK;
+     val |= clr;
+     writeb_relaxed(val, mb86s7x_shm_base
+                    + WFI_COLOR_OFFSET + clstr * 2 + cpu);
+}
+
+static int mb86s7x_pm_power_up(unsigned int cpu, unsigned int cluster)
+{
+     int ret = 0;
+
+     if (cluster >= S7X_MAX_CLUSTER || cpu >= S7X_MAX_CPU)
+             return -EINVAL;
+
+     pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+
+     local_irq_disable();
+     arch_spin_lock(&mb86s7x_pm_lock);
+
+     mb86s7x_pm_use_count[cluster][cpu]++;
+
+     if (mb86s7x_pm_use_count[cluster][cpu] == 1) {

arch/arm/mach-mb86s7x/mcpm.c line 118

Quoted 4 lines

arch/arm/mach-mb86s7x/mcpm.c new file +4 -0

+             struct mb86s7x_cpu_gate cmd;
+
+             arch_spin_unlock(&mb86s7x_pm_lock);
+             local_irq_enable();

From that point onward, nothing prevents concurrent execution in mb86s7x_pm_suspend() racing to call mb86s7x_set_wficolor() resulting in an incoherent state depending on who wins the race.

include/dt-bindings/clock/mb86s70-clk.h line 20

Quoted 11 lines · On Thursday 20 November 2014 20:36:15 Vincent Yang wrote:

include/dt-bindings/clock/mb86s70-clk.h new file +10 -0

+#define __DTS_MB86S70_CLK_H
+
+#define MB86S70_CRG11_ALW      0
+#define MB86S70_CRG11_DDR3     1
+#define MB86S70_CRG11_MAIN     2
+#define MB86S70_CRG11_CA15     3
+#define MB86S70_CRG11_HDMI     4
+#define MB86S70_CRG11_DPHY     5
+
+#define MB86S70_CRG11_UNGPRT   8

The clock driver doesn't seem to use those macros at all, how does the driver know which clock you are referring to?

Quoted 16 lines · Arnd Bergmann

include/dt-bindings/clock/mb86s70-clk.h line 20

Quoted 11 lines · On Thursday 20 November 2014 20:36:15 Vincent Yang wrote:

include/dt-bindings/clock/mb86s70-clk.h new file +10 -0

+#define __DTS_MB86S70_CLK_H
+
+#define MB86S70_CRG11_ALW      0
+#define MB86S70_CRG11_DDR3     1
+#define MB86S70_CRG11_MAIN     2
+#define MB86S70_CRG11_CA15     3
+#define MB86S70_CRG11_HDMI     4
+#define MB86S70_CRG11_DPHY     5
+
+#define MB86S70_CRG11_UNGPRT   8

The clock driver doesn't seem to use those macros at all, how does the driver know which clock you are referring to?

That was just an attempt to make a bit verbose the controller instance. Instead of specifying controller:=4, it reads better controller:=MB86S70_CRG11_HDMI in the clock DT nodes. The clock driver simply fills in controller+domain+port of the given clock into mailbox payload.

Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable) port on the controller, which the clock driver does make use of.

Quoted 17 lines · On Friday 21 November 2014 18:52:47 Jassi Brar wrote:

Quoted 16 lines · Arnd Bergmann

include/dt-bindings/clock/mb86s70-clk.h line 20

Quoted 11 lines · On Thursday 20 November 2014 20:36:15 Vincent Yang wrote:

include/dt-bindings/clock/mb86s70-clk.h new file +10 -0

+#define __DTS_MB86S70_CLK_H
+
+#define MB86S70_CRG11_ALW      0
+#define MB86S70_CRG11_DDR3     1
+#define MB86S70_CRG11_MAIN     2
+#define MB86S70_CRG11_CA15     3
+#define MB86S70_CRG11_HDMI     4
+#define MB86S70_CRG11_DPHY     5
+
+#define MB86S70_CRG11_UNGPRT   8

The clock driver doesn't seem to use those macros at all, how does the driver know which clock you are referring to?

Quoted 5 lines

That was just an attempt to make a bit verbose the controller instance. Instead of specifying controller:=4, it reads better controller:=MB86S70_CRG11_HDMI in the clock DT nodes. The clock driver simply fills in controller+domain+port of the given clock into mailbox payload.

See my other comments on the clock nodes. If these are hardware properties, just leave them as numbers in the DT, the header files are only used to establish an interface between the binding and the driver in case there is no sensible way to express which one you have.

Quoted 2 lines

Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable) port on the controller, which the clock driver does make use of.

Is this the actual port number that is known to be non-maskable?

How about adding a property to the clock node to mark the logical controller nonmaskable (in case you go for #clock-cells=2)?

For the #clock-cells=3 case, you should probably just hardcode this in the driver based on the compatible string.

Quoted 24 lines · Arnd Bergmann

Quoted 17 lines · On Friday 21 November 2014 18:52:47 Jassi Brar wrote:

Quoted 16 lines · Arnd Bergmann

include/dt-bindings/clock/mb86s70-clk.h line 20

Quoted 11 lines · On Thursday 20 November 2014 20:36:15 Vincent Yang wrote:

include/dt-bindings/clock/mb86s70-clk.h new file +10 -0

+#define __DTS_MB86S70_CLK_H
+
+#define MB86S70_CRG11_ALW      0
+#define MB86S70_CRG11_DDR3     1
+#define MB86S70_CRG11_MAIN     2
+#define MB86S70_CRG11_CA15     3
+#define MB86S70_CRG11_HDMI     4
+#define MB86S70_CRG11_DPHY     5
+
+#define MB86S70_CRG11_UNGPRT   8

The clock driver doesn't seem to use those macros at all, how does the driver know which clock you are referring to?

Quoted 5 lines

That was just an attempt to make a bit verbose the controller instance. Instead of specifying controller:=4, it reads better controller:=MB86S70_CRG11_HDMI in the clock DT nodes. The clock driver simply fills in controller+domain+port of the given clock into mailbox payload.

Quoted 5 lines

See my other comments on the clock nodes. If these are hardware properties, just leave them as numbers in the DT, the header files are only used to establish an interface between the binding and the driver in case there is no sensible way to express which one you have.

OK, I'll hardcode numbers there.

Quoted 5 lines

Quoted 2 lines

Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable) port on the controller, which the clock driver does make use of.

Is this the actual port number that is known to be non-maskable?

Yes the clock comes out of the controller and is also the parent of other 8 independently maskable clock ports of the domain.

The firmware on remote master, lets say, don't wanna be bothered by
the clock topology. Even for set-rate the onus is on Linux to request only appropriate rates at appropriate times so that other devices are not messed up.

Quoted 6 lines

How about adding a property to the clock node to mark the logical controller nonmaskable (in case you go for #clock-cells=2)?

For the #clock-cells=3 case, you should probably just hardcode this in the driver based on the compatible string.

The SoC has 6 controllers, each controller has 16domains and each domain has 8+1 ports. Instead of 864 clocks, we wanted to populate only clocks that some device actually use (some clocks seem unused in this patchset but we have users that will be upstreamed later). The remote f/w can't manage inter-dependencies and expect Linux to send only appropriate requests on port basis, so we populate ports as tiny independent clock controllers with single clock output.

Quoted 3 lines · On Friday 21 November 2014 22:06:51 Jassi Brar wrote:

Quoted 3 lines

Quoted 2 lines

Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable) port on the controller, which the clock driver does make use of.

Quoted 4 lines

Quoted 2 lines

Is this the actual port number that is known to be non-maskable?

Yes the clock comes out of the controller and is also the parent of other 8 independently maskable clock ports of the domain.

I'm getting confused by the terminology here. Is MB86S70_CRG11_ALW a port or a controller?

Quoted 4 lines

The firmware on remote master, lets say, don't wanna be bothered by
the clock topology. Even for set-rate the onus is on Linux to request only appropriate rates at appropriate times so that other devices are not messed up.

Is there any code to validate that, or does Linux just treat all clocks transparently?

Quoted 10 lines · Arnd Bergmann

Quoted 7 lines · On Friday 21 November 2014 22:06:51 Jassi Brar wrote:

Quoted 5 lines

Quoted 2 lines

Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable) port on the controller, which the clock driver does make use of.

Is this the actual port number that is known to be non-maskable?

Yes the clock comes out of the controller and is also the parent of other 8 independently maskable clock ports of the domain.

Quoted 3 lines

I'm getting confused by the terminology here. Is MB86S70_CRG11_ALW a port or a controller?

Sorry, bad symbols. ALW..DPHY are controllers. UNGPRT is the ninth parent clock (port) of a domain that can't be masked.
FYKI, there are 6 instances, of some CRG11 clock controller, under control of the remote f/w. The Mailbox protocol between remote f/w and Linux assigned indices [0-5] to these controllers.

Quoted 8 lines

Quoted 4 lines

The firmware on remote master, lets say, don't wanna be bothered by
the clock topology. Even for set-rate the onus is on Linux to request only appropriate rates at appropriate times so that other devices are not messed up.

Is there any code to validate that, or does Linux just treat all clocks transparently?

The remote does not expose the clock topology and only accepts requests on port-basis. The remote f/w is supposed to keep track of which ports are used by Linux and then work out inter-dependencies upon receiving a request from Linux. So for Linux there are N independent 'root' clocks, ops on which may or may not succeed at any given time.

Driver for Fujitsu MB86S7x SoCs that have a memory mapped GPIO controller.

Signed-off-by Andy Green <[email protected]>

Signed-off-by Jassi Brar <[email protected]>

Signed-off-by Vincent Yang <[email protected]>

Signed-off-by Tetsuya Nuriya <[email protected]>

---
 .../bindings/gpio/fujitsu,mb86s70-gpio.txt         |  18 ++
 drivers/gpio/Kconfig                               |   6 +
 drivers/gpio/Makefile                              |   1 +
 drivers/gpio/gpio-mb86s7x.c                        | 211 +++++++++++++++++++++
 4 files changed, 236 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt
 create mode 100644 drivers/gpio/gpio-mb86s7x.c

Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt new file +0 -0

new file mode 100644
index 0000000..38300ee

Documentation/devicetree/bindings/gpio/fujitsu,mb86s70-gpio.txt new file +1 -0

+       };

drivers/gpio/Kconfig +6 -0

index 0959ca9..493b7fe 100644
@@ -181,6 +181,12 @@ config GPIO_F7188X
          To compile this driver as a module, choose M here: the module will
          be called f7188x-gpio.
 
+config GPIO_MB86S7X
+       bool "GPIO support for Fujitsu MB86S7x Platforms"
+       depends on ARCH_MB86S7X
+       help
+         Say yes here to support the GPIO controller in LSI ZEVIO SoCs.
+
 config GPIO_MOXART
        bool "MOXART GPIO support"
        depends on ARCH_MOXART

drivers/gpio/Makefile +1 -0

index e5d346c..eec0664 100644
@@ -46,6 +46,7 @@ obj-$(CONFIG_GPIO_MAX730X)    += gpio-max730x.o
 obj-$(CONFIG_GPIO_MAX7300)     += gpio-max7300.o
 obj-$(CONFIG_GPIO_MAX7301)     += gpio-max7301.o
 obj-$(CONFIG_GPIO_MAX732X)     += gpio-max732x.o
+obj-$(CONFIG_GPIO_MB86S7X)     += gpio-mb86s7x.o
 obj-$(CONFIG_GPIO_MC33880)     += gpio-mc33880.o
 obj-$(CONFIG_GPIO_MC9S08DZ60)  += gpio-mc9s08dz60.o
 obj-$(CONFIG_GPIO_MCP23S08)    += gpio-mcp23s08.o

drivers/gpio/gpio-mb86s7x.c new file +22 -0

new file mode 100644
index 0000000..f0b2dc0
@@ -0,0 +1,211 @@
+/*
+ *  linux/drivers/gpio/gpio-mb86s7x.c
+ *
+ *  Copyright (C) 2014 Fujitsu Semiconductor Limited
+ *  Copyright (C) 2014 Linaro Ltd.
+ *
+ *  This program is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ */
+
+#include <linux/io.h>
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/err.h>

drivers/gpio/gpio-mb86s7x.c new file +61 -0

+       writel(val, gchip->base + PFR(offset / 8 * 4));
+       spin_unlock_irqrestore(&gchip->lock, flags);
+
+       return 0;
+}
+
+static void mb86s70_gpio_free(struct gpio_chip *gc, unsigned offset)
+{
+       struct mb86s70_gpio_chip *gchip = container_of(gc,
+                                       struct mb86s70_gpio_chip, gc);
+       unsigned long flags;
+       u32 val;
+
+       spin_lock_irqsave(&gchip->lock, flags);
+       val = readl(gchip->base + PFR(offset / 8 * 4));
+       val |= (1 << (offset % 8)); /* as peri-port */
+       writel(val, gchip->base + PFR(offset / 8 * 4));
+       spin_unlock_irqrestore(&gchip->lock, flags);
+}
+
+static int mb86s70_gpio_direction_input(struct gpio_chip *gc, unsigned offset)
+{
+       struct mb86s70_gpio_chip *gchip =
+                       container_of(gc, struct mb86s70_gpio_chip, gc);
+       unsigned long flags;
+       unsigned char val;
+
+       spin_lock_irqsave(&gchip->lock, flags);
+       val = readl(gchip->base + DDR(offset / 8 * 4));
+       val &= ~(1 << (offset % 8));
+       writel(val, gchip->base + DDR(offset / 8 * 4));
+       spin_unlock_irqrestore(&gchip->lock, flags);
+
+       return 0;
+}
+
+static int mb86s70_gpio_direction_output(struct gpio_chip *gc,
+                                        unsigned offset, int value)
+{
+       struct mb86s70_gpio_chip *gchip =
+                       container_of(gc, struct mb86s70_gpio_chip, gc);
+       unsigned long flags;
+       unsigned char val;
+
+       spin_lock_irqsave(&gchip->lock, flags);
+
+       val = readl(gchip->base + PDR(offset / 8 * 4));
+       if (value)
+               val |= (1 << (offset % 8));
+       else
+               val &= ~(1 << (offset % 8));
+       writel(val, gchip->base + PDR(offset / 8 * 4));
+
+       val = readl(gchip->base + DDR(offset / 8 * 4));
+       val |= (1 << (offset % 8));
+       writel(val, gchip->base + DDR(offset / 8 * 4));
+
+       spin_unlock_irqrestore(&gchip->lock, flags);
+
+       return 0;
+}