linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).