public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] [PATCH 2/2] ARM: sun6i: Add SMP support for the Allwinner A31
Date: Fri, 8 Nov 2013 09:40:56 +0100	[thread overview]
Message-ID: <20131108084056.GB26440@lukather> (raw)
In-Reply-To: <1383583997.8826.123.camel@kazak.uk.xensource.com>

Hi Ian,

On Mon, Nov 04, 2013 at 04:53:17PM +0000, Ian Campbell wrote:
> Not a comment on the patch, or even A31, but a question about how the
> SMP boot process works on sunxi generally...
> 
> On Sun, 2013-11-03 at 10:30 +0100, Maxime Ripard wrote:
> > The A31 is a quad Cortex-A7. Add the logic to use the IPs used to
> > control the CPU configuration and the CPU power so that we can bring up
> > secondary CPUs at boot.
> > [...]
> > +	/* Set CPU boot address */
> > +	writel(virt_to_phys(sun6i_secondary_startup),
> > +	       cpucfg_membase + CPUCFG_PRIVATE0_REG);
> 
> Does the secondary CPU jump straight here from the lowlevel firmware or
> does it go through the bootloader which reads the reg and does the jump?
> I can't see any reference to this reg in u-boot so I guess the former?

There's no reference of this either in the A31 datasheet (or at least,
none I could find), so I assume the former too.

> I'm trying to work out if we can make this work with the requirement
> which both Xen and KVM have to enter the kernel in NS-HYP mode.
> 
> The way this works on e.g. vexpress is (roughly) that u-boot wakes up
> the secondary CPUs from the lowlevel firmware and places them into its
> own holding pen, which has the same wake up protocol as the firmware so
> the kernel can just use the same code. If u-boot never gets to run on
> secondary CPUs that isn't going to help much. 
> 
> My concern is that the sequence here appears to involve resetting the
> secondary CPU, which I figure will probably defeat that strategy by
> kicking the CPU back into the lowlevel firmware in the reset state,
> meaning it can't be done by a u-boot only change.

I think this is where we're headed for the A20, Marc was interested in
doing that, since we already have pretty much this in u-boot already,
however, this is not the case for the A31.

As far as I know, the Allwinner's bootloader that we currently use
isn't bringing up the secondary CPUs, and we don't have any port of
some sort of u-boot yet that we could work on.

So, I guess we don't really have much choice in that case, even though
eventually I'd like to have this for the A31 too.

> Hrm, what to do ... perhaps a DT driven selection between this mechanism
> and sev to kick a wfe loop reading the private register?

We can discuss this whenever we will actually have that choice to
make, but maybe a kernel parameter would be better?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131108/cdb8410f/attachment.sig>

  reply	other threads:[~2013-11-08  8:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-03  9:30 [PATCH 0/2] Add SMP support for the Allwinner A31 SoCs Maxime Ripard
2013-11-03  9:30 ` [PATCH 1/2] ARM: sun6i: dt: Add IP needed to bring up the additional cores Maxime Ripard
2013-11-03  9:30 ` [PATCH 2/2] ARM: sun6i: Add SMP support for the Allwinner A31 Maxime Ripard
2013-11-04 16:53   ` [linux-sunxi] " Ian Campbell
2013-11-08  8:40     ` Maxime Ripard [this message]
2013-11-08 10:25       ` Ian Campbell
2013-11-08 11:08         ` Marc Zyngier
2013-11-10 10:03         ` Maxime Ripard
2013-11-11 16:48           ` Ian Campbell
2013-11-13 21:45             ` Maxime Ripard
2013-12-16 20:38 ` [PATCH 0/2] Add SMP support for the Allwinner A31 SoCs Maxime Ripard

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=20131108084056.GB26440@lukather \
    --to=maxime.ripard@free-electrons.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