From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/9] ARM: MB86S7X: Add MCPM support
Date: Tue, 25 Nov 2014 14:24:22 +0000 [thread overview]
Message-ID: <54749116.2050307@arm.com> (raw)
In-Reply-To: <CAAfg0W4ntf+yRZnipO+w7beN+EsZcryXCuD1eUJo1RYQNkJ2hQ@mail.gmail.com>
On 25/11/14 13:42, Andy Green wrote:
> On 25 November 2014 at 19:48, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> On 20/11/14 12:35, 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.
>>>
>>
>>> diff --git a/arch/arm/mach-mb86s7x/smc.S b/arch/arm/mach-mb86s7x/smc.S
>>> new file mode 100644
>>> index 0000000..a14330b
>>> --- /dev/null
>>> +++ b/arch/arm/mach-mb86s7x/smc.S
>>> @@ -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
>>
>>
>> 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.
>
OK, thanks for clarifying.
>> 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 ?
>> 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*.
>> 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.
> 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.
> 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.
> 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
next prev parent reply other threads:[~2014-11-25 14:24 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 12:27 [PATCH 0/9] Support for Fujitsu MB86S7X SoCs Vincent Yang
2014-11-20 12:27 ` Vincent Yang
2014-11-20 12:30 ` [PATCH 1/9] ARM: Add platform support " Vincent Yang
2014-11-20 12:30 ` Vincent Yang
2014-11-20 12:34 ` [PATCH 2/9] mailbox: arm_mhu: add driver for ARM MHU controller Vincent Yang
2014-11-20 12:34 ` Vincent Yang
2014-11-25 14:37 ` Sudeep Holla
2014-11-25 14:37 ` Sudeep Holla
2014-11-25 16:51 ` Jassi Brar
2014-11-25 16:51 ` Jassi Brar
2014-11-25 18:01 ` Sudeep Holla
2014-11-25 18:01 ` Sudeep Holla
2014-11-26 5:37 ` Jassi Brar
2014-11-26 5:37 ` Jassi Brar
2014-11-26 5:44 ` Andy Green
2014-11-26 14:00 ` Sudeep Holla
2014-11-26 14:00 ` Sudeep Holla
2014-11-26 16:20 ` Jassi Brar
2014-11-26 16:20 ` Jassi Brar
2014-11-26 16:38 ` Sudeep Holla
2014-11-26 16:38 ` Sudeep Holla
2014-11-27 5:11 ` Jassi Brar
2014-11-27 5:11 ` Jassi Brar
2014-11-27 13:25 ` Sudeep Holla
2014-11-27 13:25 ` Sudeep Holla
2014-11-20 12:35 ` [PATCH 3/9] ARM: MB86S7X: Add MCPM support Vincent Yang
2014-11-21 13:02 ` Arnd Bergmann
2014-11-21 13:24 ` Jassi Brar
2014-11-25 11:48 ` Sudeep Holla
2014-11-25 13:42 ` Andy Green
2014-11-25 14:24 ` Sudeep Holla [this message]
2014-11-25 16:43 ` Andy Green
2014-11-25 17:00 ` Nicolas Pitre
2014-11-25 17:39 ` Sudeep Holla
2014-11-25 20:31 ` Andy Green
2014-11-25 17:42 ` Nicolas Pitre
2014-11-25 18:06 ` Sudeep Holla
2014-11-25 18:55 ` Nicolas Pitre
2014-11-25 18:46 ` Lorenzo Pieralisi
2014-11-25 18:59 ` Nicolas Pitre
2014-11-25 19:21 ` Sudeep Holla
2014-11-26 16:29 ` Jassi Brar
2014-11-26 17:18 ` Sudeep Holla
2014-11-27 4:59 ` Jassi Brar
2014-11-20 12:36 ` [PATCH 4/9] clk: Add clock driver for mb86s7x Vincent Yang
2014-11-20 12:36 ` Vincent Yang
2014-11-21 13:03 ` Arnd Bergmann
2014-11-21 13:03 ` Arnd Bergmann
2014-11-21 13:22 ` Jassi Brar
2014-11-21 13:22 ` Jassi Brar
2014-11-21 14:34 ` Arnd Bergmann
2014-11-21 14:34 ` Arnd Bergmann
2014-11-21 16:36 ` Jassi Brar
2014-11-21 16:36 ` Jassi Brar
2014-11-21 17:15 ` Arnd Bergmann
2014-11-21 17:15 ` Arnd Bergmann
2014-11-21 17:58 ` Jassi Brar
2014-11-21 17:58 ` Jassi Brar
2014-11-21 20:12 ` Arnd Bergmann
2014-11-21 20:12 ` Arnd Bergmann
2014-11-20 12:37 ` [PATCH 5/9] gpio: Add Fujitsu MB86S7x GPIO driver Vincent Yang
2014-11-20 12:37 ` Vincent Yang
2014-11-27 7:33 ` Alexandre Courbot
2014-11-27 7:33 ` Alexandre Courbot
2014-12-11 16:00 ` Jassi Brar
2014-12-11 16:00 ` Jassi Brar
2014-12-03 13:32 ` Linus Walleij
2014-12-03 13:32 ` Linus Walleij
2014-12-11 16:01 ` Jassi Brar
2014-12-11 16:01 ` Jassi Brar
2014-11-20 12:38 ` [PATCH 6/9] mmc: sdhci: host: add new f_sdh30 Vincent Yang
2014-11-20 12:38 ` Vincent Yang
2014-11-20 15:22 ` Rob Herring
2014-11-20 15:22 ` Rob Herring
2014-11-20 16:59 ` Vincent Yang
2014-11-20 16:59 ` Vincent Yang
2014-11-20 18:18 ` Rob Herring
2014-11-20 18:18 ` Rob Herring
2014-11-21 1:18 ` Vincent Yang
2014-11-21 1:18 ` Vincent Yang
2014-11-20 12:38 ` [PATCH 7/9] dt: mb86s7x: add dt files for MB86S7x evbs Vincent Yang
2014-11-20 12:38 ` Vincent Yang
2014-11-21 14:26 ` Arnd Bergmann
2014-11-21 14:26 ` Arnd Bergmann
2014-11-21 16:49 ` Jassi Brar
2014-11-21 16:49 ` Jassi Brar
2014-11-21 17:09 ` Arnd Bergmann
2014-11-21 17:09 ` Arnd Bergmann
2014-11-21 17:35 ` Jassi Brar
2014-11-21 17:35 ` Jassi Brar
2014-11-21 20:14 ` Arnd Bergmann
2014-11-21 20:14 ` Arnd Bergmann
2014-11-20 12:39 ` [PATCH 8/9] of: add Fujitsu vendor prefix Vincent Yang
2014-11-20 12:39 ` Vincent Yang
2014-11-20 15:07 ` Rob Herring
2014-11-20 15:07 ` Rob Herring
2014-11-20 12:40 ` [PATCH 9/9] ARM: MB86S7x: Add configs Vincent Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54749116.2050307@arm.com \
--to=sudeep.holla@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.