All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Suriyan Ramasami <suriyan.r@gmail.com>
Cc: stefano.stabellini@citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support
Date: Wed, 10 Feb 2016 10:03:44 +0000	[thread overview]
Message-ID: <1455098624.19857.135.camel@citrix.com> (raw)
In-Reply-To: <CANoR_OCgb_7T-NH2ri4Z7=fuachoEUwJu1ZqK2expYiVXaUEcw@mail.gmail.com>

On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami wrote:
>  I agree on the first two paragraphs.
> > > For the third paragraph, the rebuttal is that the exynos5800 and
> > > exynos5422 based SoCs can have both clusters on at the same time. Hence,
> > > the third paragrapah comment will have to be tweaked further. Possibly
> > > reading:
> > > The exynos5800 and exynos5422 can have both clusters on at the same time.
> > > The exynos5800 boots up with cpu0 on cluster0 (A15). The exynos5422 can
> > > boot up on either clusters as its pin controlled. In this case the DTS
> > > should properly reflect the cpu order.
> > 
> > Does the OS need to be aware of all these combinations though? Is it not
> > sufficient to know how to bring up an A15 core and how to bring up an A7
> > core and then just do so based on the information in the DTS, without
> > needing to worry about which sort of core we happened to have booted on?
> > 
> > 
> Unfortunately, at least looking at the boot up code for the Exynos5422,
> the OS needs to be aware of it. This is what I see in the linux source
> code. If it boots up on an A7, then a special reset is needed which is
> not needed when booted up otherwise. I do not have much more details on
> that other than the Linux code.
> Without that reset sequence, I have also verified that the powered on CPU
> does not come up.

Are we able to say that if we are booted on cluster 1 (always the A7s) then
we always need this magic reset? i.e. is true for all SoCs which have an A7
cluster and can boot from it? (it's tautologically true for SocS which
either have no A7's or cannot boot from them).

Maybe I'm looking for similarities between different exynos variants which
doesn't exist though. If we are going to talk about specific SoCs in the
comments then I would rather that the code was also explicit rather than
assuming cluster 1 will only be found on the 5800, that might be as simple
as mapping the compatible string to a max_cluster (default 0 for unknown
SoC) and warning if pcluster > max_cluster.

> 
> >  >  The exynos5410 can have only one cluster on at a time, and it boots
> > up
> > > with pcluster == 0.
> > > Any tweaks and comments on the above is appreciated.
> > 
> > How much of this is down to physical h/w limitations and how much of it
> > is
> > down to firmware or software limitations? Can you flip the to the other
> > cluster somehow?
> >   
> The 5410 boots up on an A15, and only those 4 A15 CPUs in cluster 0 are
> brought up. Hence, no flipping is required.

What I meant was, given that the 5410 has a cluster of A15 and a cluster of
A7s (right?) and you can only have one on at a time, how does an OS make
use of the A7s if it wants to? As you say it boots from the A15, so how can
the A7s be used?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-02-10 10:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09  5:48 [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support Suriyan Ramasami
2016-02-09  9:53 ` Ian Campbell
2016-02-09 12:50   ` Suriyan Ramasami
2016-02-09 14:19     ` Ian Campbell
2016-02-09 18:20       ` Suriyan Ramasami
2016-02-10 10:03         ` Ian Campbell [this message]
2016-02-11  1:47           ` Suriyan Ramasami
2016-02-11  9:40             ` Ian Campbell
2016-02-15  6:32               ` Suriyan Ramasami
2016-02-16 10:03                 ` Ian Campbell
2016-02-17  2:24                   ` Suriyan Ramasami

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=1455098624.19857.135.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=suriyan.r@gmail.com \
    --cc=xen-devel@lists.xen.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.