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: 58+ 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:30 ` [PATCH 1/9] ARM: Add platform support " Vincent Yang
2014-11-20 12:34 ` [PATCH 2/9] mailbox: arm_mhu: add driver for ARM MHU controller Vincent Yang
2014-11-25 14:37 ` Sudeep Holla
2014-11-25 16:51 ` Jassi Brar
2014-11-25 18:01 ` Sudeep Holla
2014-11-26 5:37 ` Jassi Brar
2014-11-26 14:00 ` Sudeep Holla
2014-11-26 16:20 ` Jassi Brar
2014-11-26 16:38 ` Sudeep Holla
2014-11-27 5:11 ` Jassi Brar
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-21 13:03 ` Arnd Bergmann
2014-11-21 13:22 ` Jassi Brar
2014-11-21 14:34 ` Arnd Bergmann
2014-11-21 16:36 ` Jassi Brar
2014-11-21 17:15 ` Arnd Bergmann
2014-11-21 17:58 ` Jassi Brar
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-27 7:33 ` Alexandre Courbot
2014-12-11 16:00 ` Jassi Brar
2014-12-03 13:32 ` Linus Walleij
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 15:22 ` Rob Herring
2014-11-20 16:59 ` Vincent Yang
2014-11-20 18:18 ` Rob Herring
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-21 14:26 ` Arnd Bergmann
2014-11-21 16:49 ` Jassi Brar
2014-11-21 17:09 ` Arnd Bergmann
2014-11-21 17:35 ` Jassi Brar
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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).