[RFC PATCHv1 0/7] ARM core support for hardware I/O coherency in non-SMP platforms

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Mon May 19 04:17:57 PDT 2014


On Mon, 19 May 2014 11:42:19 +0100, Catalin Marinas wrote:

> > I have no problem about the bootloader doing some initialization, so if
> > that's a requirement for arm64, no problem. But it should be a
> > requirement regardless of the kernel configuration: in the current
> > kernel, some initialization is done when CONFIG_SMP is enabled. And now
> > that the same initialization is needed in !CONFIG_SMP, I'm asked to do
> > it in the bootloader. That's the thing I don't buy.
> And that's a hard thing for me to sell for arm32 ;) because of the
> current code already doing this.
> One of the issues is secure vs non-secure kernel deployment and
> secure-only registers like ACTLR (and even SCU). I've seen SoCs for
> which the mainline kernel assumes secure mode but it's deployed as
> non-secure in the field with out of tree modifications to make it work.
> I would rather have a single kernel image for both cases.

As things are today, I believe the Armada 370/XP/375/38x are always
booted in secure mode. Couldn't the kernel detect if it's running
secure or non-secure. If it's running secure, it can do all the ACTLR
configuration (and other things that require being in secure mode). If
it's running non-secure, then it doesn't do this configuration, and
assumes the firmware/bootloader did it.

> > > > Unfortunately, __create_page_tables is called so early that I don't
> > > > know if it's possible to access 'struct machine_desc' at this point to
> > > > know whether the platform needs shareable pages or not.
> > > > 
> > > > Also, don't we have the same problem with the TTB_FLAGS_{SMP,UP) ?
> > > 
> > > I don't think we do because we use the ALT_{SMP,UP} for TTB settings and
> > > we have the smp-on-up fixup running before __v7_setup.
> > 
> > Ok. For Armada 370, I don't need shareable pages. For Armada 380, I
> > need shareable pages, but even if the processor is single core, I
> > believe it pretends to be SMP in MPIDR.
> You'd need to check this.

I got the confirmation. *But* this is only going to affect CONFIG_SMP
builds. Armada 380 being single core, we want I/O coherency to work on
it in !CONFIG_SMP configurations. And in !CONFIG_SMP configuration,
it's always ALT_UP() that is used, regardless of what MPIDR says. And
therefore the TTB_FLAGS_UP will be used.

> > > I'm always for the former (and that's the case for arm64), though for
> > > some older boards it's too late to change.
> > 
> > Indeed. So how do we move forward?
> As I said previously, it's not my call, just a recommendation. It's up
> to the arm/arm-soc maintainers to take this. Give the arm32 SMP
> initialisation precedent, forcing it for an existing platform is a
> harder sell.

Ok. So I should keep going with the approach proposed in my patch
series, obviously after fixing the various other comments that were


Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering

More information about the linux-arm-kernel mailing list