Commit Graph

8 Commits

Author SHA1 Message Date
Linus Torvalds 47f92418c7 Remove __cpuinit macros and users.
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJVkO0aAAoJEOvOhAQsB9HWoRUQAII3ueftazj4ZYVEF5QBIdNL
 MrEyUbPMyXHYBKmcAVkig5N4JLkITvPnuT/LRQ3ba7gMyeYKUFCHpLniRHwGkHIJ
 UAHgDYzLXO7bv2ZhHiSk6ZL6XtEq2vY+dcedS26CAoR53erjmRiniakYhT/NbfSf
 rFfPKaVOH7E7yGn7OrFAASGSPlKbzjICqfnUQQi5Z9XxAfdXcHLiuX98KufSaXbM
 a27KDJudH11/guwCkACvD0C0NnUoRxe6X7/JyTmt/ldqH3f9JR2jEnDgrh/jakJE
 LgsguiHGcDuZjC1n4jb5n72Iua0zOtyrKhvDAZ77bG7NEcK6OlvhY0No3rEvXA9X
 XhScF3BUd1/pBKRwVALWTprHJ0q8HjQAfci1ONX9qMWNhjpY1jU6J8cUpAEKf8hk
 nHSsSesvsXKLogTEY05vF4sOUupILi1zlP/1dGDLXr/FVWX52U4BFlur67Vay7pN
 PtjvKl30Tw0yLOLkZwr53jKpqFZOgcTy+mm/DF3j2v77da1JXS94pCV3PcV8lNxT
 xlQPB2O6LvYn5LPnyJ8SwuLm466+OD3jfLNBPgXVLgZb+lY/GpL/mHgxoK+/FweH
 quHj3e7q3OWADxPEdnJswuCKpeG/w+jcpK7fWWo+4haC4bMcSDM42Dc78o9ve4rU
 E9Ex9ymil7W4DmAWsd2g
 =qNLm
 -----END PGP SIGNATURE-----

Merge tag 'cpuinit-v4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux

Pull __cpuinit removal from Paul Gortmaker:
 "Remove __cpuinit macros and users.

  We removed the __cpuinit stuff in 3.11-rc1 with commit 22f0a27367
  ("init.h: remove __cpuinit sections from the kernel") but we left some
  no-op stubs as a courtesy to unmerged code.

  Here we get rid of the stubs as well, since (as can be seen in these
  changes) they are enabling use cases to sneak back in, primarily from
  older BSP code that has been living out of tree for some time prior to
  getting mainlined.  So we get rid of these "new" users 1st and then
  get rid of the stubs.

  Obviously, getting rid of the stubs can't happen until all the users
  are gone, so I had to keep this together as a series, even though some
  of these commits since got picked up into maintainers trees as well.

  The nature of this change is such that it should have zero impact on
  the generated runtime.

  This is one of several independent cleanup branches aimed at enabling
  better organization in the init.h and module.h code.  They have been
  getting coverage in the linux-next tree for the last month, in
  addition to my local testing, which also covers approximately a half
  dozen or more architectures"

* tag 'cpuinit-v4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  init: delete the __cpuinit related stubs
  kernel/cpu.c: remove new instance of __cpuinit that crept back in
  sched/core: remove __cpuinit section tag that crept back in.
  mips/mm/tlbex: remove new instance of __cpuinit that crept back in
  mips/c-r4k: remove legacy __cpuinit section that crept in
  mips/bcm77xx: remove legacy __cpuinit sections that crept in
  mips/ath25: remove legacy __cpuinit section that crept in
  arm/mach-hisi: remove legacy __CPUINIT section that crept in
  arm/mach-rockchip: remove legacy __cpuinit section that crept in
  arm/mach-mvebu: remove legacy __cpuinit sections that crept in
  arm/mach-keystone: remove legacy __cpuinit sections that crept in
2015-07-02 09:54:14 -07:00
Paul Gortmaker ff6138ad19 arm/mach-mvebu: remove legacy __cpuinit sections that crept in
We removed __cpuinit support (leaving no-op stubs) quite some time
ago.  However these ones crept back in as of commit 1ee89e2231
("ARM: mvebu: add SMP support for Armada 375 and Armada 38x")

Since we want to clobber the stubs soon, get this removed now.
Note that there would normally be a corresponding removal of
a ".previous" directive for each __CPUINIT in asm files, but in
this case it appears that this single function file was never
paired off with one.

Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2015-06-16 14:12:21 -04:00
Russell King 02b4e2756e ARM: v7 setup function should invalidate L1 cache
All ARMv5 and older CPUs invalidate their caches in the early assembly
setup function, prior to enabling the MMU.  This is because the L1
cache should not contain any data relevant to the execution of the
kernel at this point; all data should have been flushed out to memory.

This requirement should also be true for ARMv6 and ARMv7 CPUs - indeed,
these typically do not search their caches when caching is disabled (as
it needs to be when the MMU is disabled) so this change should be safe.

ARMv7 allows there to be CPUs which search their caches while caching is
disabled, and it's permitted that the cache is uninitialised at boot;
for these, the architecture reference manual requires that an
implementation specific code sequence is used immediately after reset
to ensure that the cache is placed into a sane state.  Such
functionality is definitely outside the remit of the Linux kernel, and
must be done by the SoC's firmware before _any_ CPU gets to the Linux
kernel.

Changing the data cache clean+invalidate to a mere invalidate allows us
to get rid of a lot of platform specific hacks around this issue for
their secondary CPU bringup paths - some of which were buggy.

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Dinh Nguyen <dinguyen@opensource.altera.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-06-01 11:30:26 +01:00
Gregory CLEMENT f5789cbb22 ARM: mvebu: Fix the secondary startup for Cortex A9 SoC
During the secondary startup the SCU was assumed to be in normal
mode. It is not always the case, and especially after a kexec. This
commit adds the needed sequence to put the SCU in normal mode.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1414669184-16785-4-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-22 02:14:20 +00:00
Gregory CLEMENT 305969fb62 ARM: mvebu: use the common function for Armada 375 SMP workaround
Use the common function mvebu_setup_boot_addr_wa() introduced in the
commit "ARM: mvebu: Add a common function for the boot address work
around" instead of the dedicated version for Armada 375.

This commit also moves the workaround in the system-controller
module. Indeed the workaround on 375 is really related to setting the
boot address which is done by the system controller.

As a bonus we no longer use an harcoded value to access the register
storing the boot address.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1406120453-29291-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-24 11:46:10 +00:00
Thomas Petazzoni 0e2be4c112 ARM: mvebu: fix SMP boot for Armada 38x and Armada 375 Z1 in big endian
The SMP boot on Armada 38x and Armada 375 Z1 is currently broken in
big-endian configurations, and this commit fixes it for both
platforms.

For Armada 375 Z1, the problem was in the
armada_375_smp_cpu1_enable_code part of the code that gets copied to
the Crypto SRAM as a work-around for an issue of the Z1 stepping. This
piece of code was not switching the CPU core to big-endian, and not
endian-swapping the value read from the Resume Address register (the
value is stored little-endian). Due to the introduction of the
conditional 'rev r1, r1' instruction, the offset between the 'ldr r0,
[pc, ]' instruction and the value it was looking is different
between LE and BE configurations. To solve this, we instead use one
'adr' instruction followed by one 'ldr'.

For Armada 38x, the problem was simply that the CPU core was not
switched to big endian in the secondary CPU startup function.

This change was tested in LE and BE configurations on Armada 385,
Armada 375 Z1 and Armada 375 A0.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1404228186-21203-1-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-01 17:02:26 +00:00
Gregory CLEMENT 87384cc0b4 ARM: mvebu: add workaround for SMP support for Armada 375 stepping Z1
Due to internal bootrom issue, CPU[1] initial jump code (four
instructions) should be placed in SRAM memory of the SoC. In order to
achieve this, we have to unmap the BootROM and at some specific
location where the BootROM was place, create a specific MBus window
for the SRAM. This SRAM is initialized with a few instructions of code
that allows to jump into the real secondary CPU boot address.

This workaround will most likely be disabled when newer steppings of
the Armada 375 will be made available, in which case a dynamic test
based on mvebu-soc-id will be added.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-10-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-10-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:08:30 +00:00
Gregory CLEMENT 1ee89e2231 ARM: mvebu: add SMP support for Armada 375 and Armada 38x
This commit adds the SMP support for Armada 375 and Armada 38x. It
turns out that the SMP logic for both of these SOCs are fairly
similar, the only differences being:

 * A different method to set the secondary CPU boot address

 * An Armada 375 specific workaround needed for the early Z1 stepping,
   added by the following patch.

Other than that, the patch is fairly straightforward and adds the
usual platsmp and headsmp code, defining the smp_operations structure
that is referenced from the DT_MACHINE structures.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483648-26611-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:08:22 +00:00