From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCHv1 0/7] ARM core support for hardware I/O coherency in non-SMP platforms
Date: Fri, 16 May 2014 16:11:30 +0100 [thread overview]
Message-ID: <20140516151130.GB7171@localhost> (raw)
In-Reply-To: <CAL_JsqKSzsyi-XmTKRK=87Z5wFzDjXaLNHj_irOM4V2-8ds1Tw@mail.gmail.com>
On Thu, May 15, 2014 at 08:11:13PM +0100, Rob Herring wrote:
> On Thu, May 15, 2014 at 10:25 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Thu, May 15, 2014 at 03:59:31PM +0100, Rob Herring wrote:
> >> On Thu, May 15, 2014 at 9:22 AM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >> > On Thu, May 15, 2014 at 10:50:10AM +0100, Thomas Petazzoni wrote:
> >> >> On Wed, 14 May 2014 18:04:56 +0100, Catalin Marinas wrote:
> >> >> > On Wed, May 14, 2014 at 04:50:34PM +0100, Thomas Petazzoni wrote:
> >> >> > > - The SCU must be enabled
> >> >> >
> >> >> > Again, could the firmware do this?
> >> >>
> >> >> See above. If the kernel does it for SMP cases, why wouldn't it do it
> >> >> also for !SMP I/O coherent cases?
> >> >
> >> > The I/O coherency is an SoC property rather than an ARM architecture
> >> > property. I want to separate the two so that the kernel can boot a
> >> > significant part assuming sane architecture settings. Once you have DT
> >> > available and start loading device drivers, you are in the SoC realm and
> >> > you can do whatever initialisation for buses, interconnects, but not
> >> > going back to change architected settings.
> >>
> >> The SCU has nothing to do with the architecture and really is part of
> >> the SOC.
> >
> > Indeed, it's not part of the architecture but I don't see it any
> > different than other early configuration like SDRAM controller.
> >
> >> Let's look at this another way. Are there any usecases where
> >> you would not enable the SCU? If any cores are coherent or the ACP is
> >> coherent, it must be on. So that leaves all core in AMP mode. In this
> >> case, does it matter if the SCU is enabled or not?
> >
> > I don't fully follow the question. You may not enable the SCU if you
> > don't care at all about the SMP mode or other coherency like ACP.
> > Otherwise it should be enabled, the latest before the secondaries start.
>
> My question is should the kernel unconditionally enable the SCU
> regardless of CONFIG_SMP or any other condition? Is there harm in
> enabling the SCU when in AMP mode?
I don't see why we couldn't always enable the SCU at boot, whether the
OS runs SMP, AMP or UP mode.
--
Catalin
next prev parent reply other threads:[~2014-05-16 15:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 15:50 [RFC PATCHv1 0/7] ARM core support for hardware I/O coherency in non-SMP platforms Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 1/7] ARM: extend machine_desc with additional flags Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 2/7] ARM: mm: implement the usage of the machine_desc flags Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 3/7] ARM: mm: enable SMP bit and TLB broadcast bit on !SMP when needed Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 4/7] ARM: kernel: allow the SCU to be enabled even on !SMP Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 5/7] ARM: mvebu: split Armada 370 and Armada XP machine_desc Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 6/7] ARM: mvebu: define the Armada 370/375/38x/XP machine_desc flags Thomas Petazzoni
2014-05-14 15:50 ` [RFC PATCHv1 7/7] ARM: mvebu: I/O coherency no longer needs SMP on 375 and 38x Thomas Petazzoni
2014-05-14 17:04 ` [RFC PATCHv1 0/7] ARM core support for hardware I/O coherency in non-SMP platforms Catalin Marinas
2014-05-15 9:50 ` Thomas Petazzoni
2014-05-15 14:22 ` Catalin Marinas
2014-05-15 14:59 ` Rob Herring
2014-05-15 15:25 ` Catalin Marinas
2014-05-15 19:11 ` Rob Herring
2014-05-16 15:11 ` Catalin Marinas [this message]
2014-05-19 9:19 ` Thomas Petazzoni
2014-05-19 9:17 ` Thomas Petazzoni
2014-05-19 10:42 ` Catalin Marinas
2014-05-19 11:17 ` Thomas Petazzoni
2014-05-19 15:19 ` Catalin Marinas
2014-05-19 13:38 ` Thomas Petazzoni
2014-05-14 17:07 ` Rob Herring
2014-05-15 10:01 ` Thomas Petazzoni
2014-05-15 13:27 ` Will Deacon
2014-05-15 13:44 ` Thomas Petazzoni
2014-05-15 14:44 ` Rob Herring
2014-05-19 9:31 ` Thomas Petazzoni
2014-05-19 16:53 ` Rob Herring
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=20140516151130.GB7171@localhost \
--to=catalin.marinas@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).