Commit Graph

24 Commits

Author SHA1 Message Date
Ezequiel Garcia
a728b97742 ARM: mvebu: Fix coherency bus notifiers by using separate notifiers
Currently, the coherency fabric support registers two bus notifiers;
one for platform, one for pci bus types, with the same notifier block.
However, this is illegal and can cause serious issues: the notifier
block is also a link in the notifier list and cannot be inserted twice.

This commit fixes this by using different notifier blocks (with the same
notifier callback) to set the platform and pci bus types notifiers.

Fixes: b0063aad5d ("ARM: mvebu: use hardware I/O coherency also for PCI devices")
Reported-by: Paolo Pisati <p.pisati@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1404826657-6977-1-git-send-email-ezequiel.garcia@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-08 13:53:53 +00:00
Thomas Petazzoni
8828ccc3f2 ARM: mvebu: coherency: fix registration of PCI bus notifier when !PCI
Commit b0063aad5d ("ARM: mvebu: use hardware I/O coherency also for
PCI devices") added a reference to the pci_bus_type variable, but this
variable is only available when CONFIG_PCI is enabled. Therefore,
there is now a build failure in !CONFIG_PCI situations.

This commit fixes that by enclosing the entire initcall into a
IS_ENABLED(CONFIG_PCI) condition.

Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1400598783-706-1-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-22 14:17:46 +00:00
Thomas Petazzoni
497a92308a ARM: mvebu: implement L2/PCIe deadlock workaround
The Marvell Armada 375 and Armada 38x SOCs, which use the Cortex-A9
CPU core, the PL310 cache and the Marvell PCIe hardware block are
affected a L2/PCIe deadlock caused by a system erratum when hardware
I/O coherency is used.

This deadlock can be avoided by mapping the PCIe memory areas as
strongly-ordered (note: MT_UNCACHED is strongly-ordered), and by
removing the outer cache sync done in software. This is implemented in
this patch by:

 * Registering a custom arch_ioremap_caller function that allows to
   make sure PCI memory regions are mapped MT_UNCACHED.

 * Adding at runtime the 'arm,io-coherent' property to the PL310 cache
   controller. This cannot be done permanently in the DT, because the
   hardware I/O coherency can only be enabled when CONFIG_SMP is
   enabled, in the current kernel situation.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1400165974-9059-4-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-22 14:07:18 +00:00
Thomas Petazzoni
b0063aad5d ARM: mvebu: use hardware I/O coherency also for PCI devices
Since the beginning of the introduction of hardware I/O coherency
support for Armada 370 and Armada XP, the special DMA operations
should have applied to all DMA capable devices. Unfortunately, while
the original code properly took into account platform devices, it
didn't take into account PCI devices, which can also be DMA masters.

This commit fixes that by registering a bus notifier on pci_bus_type,
to register our custom DMA operations, like is already done for
platform devices. While doing this, we also rename
mvebu_hwcc_platform_notifier() to mvebu_hwcc_notifier() and
mvebu_hwcc_platform_nb to mvebu_hwcc_nb because they are no longer
specific to platform devices.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399997070-11434-1-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-16 05:34:24 +00:00
Thomas Petazzoni
3943856717 ARM: mvebu: conditionalize Armada 375 coherency workaround
The Armada 375 coherency workaround only needs to be applied to the Z1
revision of the SoC. The A0 and later revisions have been fixed, and
no longer need this workaround.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399302326-6917-6-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:40:17 +00:00
Gregory CLEMENT
2e8a5942f8 ARM: mvebu: Split low level functions to manipulate HW coherency
Actually enabling coherency and adding a CPU on a SMP group are two
different operations which can be done separately. This patch splits
this in two functions.

Moreover as they use common pattern, this patch also creates local low
level functions (ll_get_coherency_base and ll_get_cpuid) to be used by
the exposed functions (ll_add_cpu_to_smp_group and
ll_enable_coherency)

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-6-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:18:54 +00:00
Gregory CLEMENT
952f4ca79b ARM: mvebu: Remove the unused argument of set_cpu_coherent()
set_cpu_coherent() took the SMP group ID as parameter. But this
parameter was never used, and the CPU always uses the SMP group 0. So
we can remove this parameter.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-5-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:18:52 +00:00
Gregory CLEMENT
b41375f71a ARM: mvebu: ll_set_cpu_coherent always uses the current CPU
ll_set_cpu_coherent is always used on the current CPU, so instead of
passing the CPU id as argument, ll_set_cpu_coherent() can find it by
itself.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-4-git-send-email-gregory.clement@free-electrons.com
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:18:51 +00:00
Gregory CLEMENT
ccd6a13180 ARM: mvebu: remove the address parameter for ll_set_cpu_coherent
In order to be able to deal with the MMU enabled and the MMU disabled
cases, the base address of the coherency registers was passed to the
function. The address by itself was not interesting as it can't change
for a given SoC, the only thing we need is to have a distinction
between the physical or the virtual address.

This patch add a check of the MMU bit to choose the accurate address,
then the calling function doesn't have to pass this information.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397488214-20685-3-git-send-email-gregory.clement@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-05-08 16:10:24 +00:00
Thomas Petazzoni
d0de932382 ARM: mvebu: add Armada 38x support to the coherency code
The Armada 38x has a coherency unit that is similar to the one of the
Armada 375 SoC, except that it does not have the bug of the Armada 375
coherency unit that requires the XOR based workaround.

This commit therefore extends the Marvell EBU coherency code with a
new compatible string to support the Armada 38x coherency unit.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-9-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24 05:00:38 +00:00
Thomas Petazzoni
5ab5afd8ba ARM: mvebu: implement Armada 375 coherency workaround
The early revisions of Armada 375 SOCs (Z1 stepping) have a bug in the
I/O coherency unit that prevents using the normal method for the I/O
coherency barrier. The recommended workaround is to use a XOR memset
transfer to act as the I/O coherency barrier.

This involves "borrowing" a XOR engine, which gets disabled in the
Device Tree so the normal XOR driver doesn't use it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-8-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24 05:00:37 +00:00
Thomas Petazzoni
77fa4b9ab0 ARM: mvebu: add Armada 375 support to the coherency code
The Armada 375, like the Armada 370 and Armada XP, has a coherency
unit. However, unlike the coherency unit of 370/XP which does both CPU
and I/O coherency, the one on Armada 735 only does I/O
coherency. Therefore, instead of having two sets of registers (the
first one being used mainly to register each CPU in the coherency
fabric, the second one being used for the I/O coherency barrier), it
has only one set of register (for the I/O coherency barrier).

This commit adds a new "marvell,armada-375-coherency-fabric"
compatible string for this variant of the coherency fabric. The custom
DMA operations, and the way of triggering an I/O barrier is the same
as Armada 370/XP, so the code changes are minimal. However, the
set_cpu_coherent() function is not needed on Armada 375 and will not
work.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-7-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24 05:00:37 +00:00
Thomas Petazzoni
5fbba08051 ARM: mvebu: ARM: mvebu: use of_find_matching_node_and_match() in coherency.c
In the mach-mvebu coherency code, instead of using
of_find_matching_node() and then of_match_node(), directly use the
of_find_matching_node_and_match() which does both at once.

We take this opportunity to also simplify the initialization of the
"type" variable.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24 05:00:36 +00:00
Thomas Petazzoni
501f928e00 ARM: mvebu: add a coherency_available() call
This commit extends the coherency fabric code to provide a
coherency_available()function that the SoC code can call to be told
whether coherency support is available or not. On Armada 370/XP,
coherency support is available as soon as the relevant DT node is
present. On some upcoming SoCs, the DT node needs to be present *and*
the system running with CONFIG_SMP enabled.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-3-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24 05:00:36 +00:00
Thomas Petazzoni
924d38f404 ARM: mvebu: prepare coherency code to support more SOCs
The code that handles the coherency fabric of Armada 370 and Armada XP
in arch/arm/mach-mvebu/coherency.c made the assumption that there was
only one type of coherency fabric. Unfortunately, it turns out that
upcoming SoCs have a slightly different coherency unit.

In preparation to the introduction of the coherency support for more
SoCs, this commit:

 * Introduces a data associated to the compatible string in the
   compatible string match table, so that the code can differantiate
   the variant of coherency unit being used.

 * Separates the coherency unit initialization code into its own
   function.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397483228-25625-2-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-24 05:00:35 +00:00
Jisheng Zhang
b12634e343 ARM: mvebu: fix some sparse warnings
This patch fixes conflicting types for 'set_cpu_coherent' and fixes the
following sparse warnings.

arch/arm/mach-mvebu/system-controller.c:42:38:
warning: symbol 'armada_370_xp_system_controller' was not declared. Should it be static?
arch/arm/mach-mvebu/system-controller.c:49:38:
warning: symbol 'orion_system_controller' was not declared. Should it be static?
arch/arm/mach-mvebu/system-controller.c:67:6:
warning: symbol 'mvebu_restart' was not declared. Should it be static?
arch/arm/mach-mvebu/coherency.c:31:15:
warning: symbol 'coherency_phys_base' was not declared. Should it be static?
arch/arm/mach-mvebu/coherency.c:48:5:
warning: symbol 'set_cpu_coherent' was not declared. Should it be static?
arch/arm/mach-mvebu/coherency.c:123:12:
warning: symbol 'coherency_init' was not declared. Should it be static?
arch/arm/mach-mvebu/pmsu.c:38:5: warning:
symbol 'armada_xp_boot_cpu' was not declared. Should it be static?
arch/arm/mach-mvebu/pmsu.c:61:12: warning:
symbol 'armada_370_xp_pmsu_init' was not declared. Should it be static?
arch/arm/mach-mvebu/platsmp.c:49:13: warning:
symbol 'set_secondary_cpus_clock' was not declared. Should it be static?
arch/arm/mach-mvebu/platsmp.c:97:13: warning:
symbol 'armada_xp_smp_prepare_cpus' was not declared. Should it be static?
arch/arm/mach-mvebu/hotplug.c:24:12: warning:
symbol 'armada_xp_cpu_die' was not declared. Should it be static?

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-11-24 03:27:54 +00:00
Jisheng Zhang
abe511ac85 ARM: mvebu: add missing of_node_put() to fix reference leak
Add of_node_put to properly decrement the refcount when we are
done using a given node.

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>

Conflicts:
	arch/arm/mach-mvebu/armada-370-xp.c
	arch/arm/mach-mvebu/platsmp.c
2013-09-18 16:40:53 +00:00
Paul Gortmaker
8bd26e3a7e arm: delete __cpuinit/__CPUINIT usage from all ARM users
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
and are flagged as __cpuinit  -- so if we remove the __cpuinit from
the arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
related content into no-ops as early as possible, since that will get
rid of these warnings.  In any case, they are temporary and harmless.

This removes all the ARM uses of the __cpuinit macros from C code,
and all __CPUINIT from assembly code.  It also had two ".previous"
section statements that were paired off against __CPUINIT
(aka .section ".cpuinit.text") that also get removed here.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2013-07-14 19:36:52 -04:00
Thomas Petazzoni
1919bff0e2 arm: mvebu: fix coherency_late_init() for multiplatform
As noticed by Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>, commit
865e0527d2 ('arm: mvebu: avoid hardcoded virtual address in
coherency code') added a postcore_initcall() to register the bus
notifier that the mvebu code needs to apply correct DMA operations on
its platform devices breaks the multiplatform boot on other platforms,
because the bus notifier registration is unconditional.

This commit fixes that by registering the bus notifier only if we have
the mvebu coherency unit described in the Device Tree. The conditional
used is exactly the same in which the bus_register_notifier() call was
originally enclosed before 865e0527d2 ('arm: mvebu: avoid hardcoded
virtual address in coherency code').

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-06-20 12:12:48 +00:00
Thomas Petazzoni
580ff0eea1 arm: mvebu: don't hardcode a physical address in headsmp.S
Now that the coherency_init() function is called a bit earlier, we can
actually read the physical address of the coherency unit registers
from the Device Tree, and communicate that to the headsmp.S code,
which avoids hardcoding a physical address.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-06-13 17:48:40 +00:00
Thomas Petazzoni
865e0527d2 arm: mvebu: avoid hardcoded virtual address in coherency code
Now that the coherency_get_cpu_count() function no longer requires a
very early mapping of the coherency unit registers, we can avoid the
hardcoded virtual address in coherency.c. However, the coherency
features are still used quite early, so we need to do the of_iomap()
early enough, at the ->init_timer() level, so we have the call of
coherency_init() at this point.

Unfortunately, at ->init_timer() time, it is not possible to register
a bus notifier, so we add a separate coherency_late_init() function
that gets called as as postcore_initcall(), when bus notifiers are
available.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-06-13 17:48:20 +00:00
Thomas Petazzoni
b21dcafea3 arm: mvebu: remove dependency of SMP init on static I/O mapping
The ->smp_init_cpus() function is called very early during boot, at a
point where dynamic I/O mappings are not yet possible. However, in the
Armada 370/XP implementation of this function, we have to get the
number of CPUs. We used to do that by accessing a hardware register,
which requires relying on a static I/O mapping set up by
->map_io(). Not only this requires hardcoding a virtual address, but
it also prevents us from removing the static I/O mapping.

So this commit changes the way used to get the number of CPUs: we now
use the Device Tree, which is a representation of the hardware, and
provides us the number of available CPUs. This is also more accurate,
because it potentially allows to boot the Linux kernel on only a
number of CPUs given by the Device Tree, instead of unconditionally on
all CPUs.

As a consequence, the coherency_get_cpu_count() function becomes no
longer used, so we remove it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-06-13 17:48:13 +00:00
Gregory CLEMENT
e60304f8cb arm: mvebu: Add hardware I/O Coherency support
Armada 370 and XP come with an unit called coherency fabric. This unit
allows to use the Armada 370/XP as a nearly coherent architecture. The
coherency mechanism uses snoop filters to ensure the coherency between
caches, DRAM and devices. This mechanism needs a synchronization
barrier which guarantees that all the memory writes initiated by the
devices have reached their target and do not reside in intermediate
write buffers. That's why the architecture is not totally coherent and
we need to provide our own functions for some DMA operations.

Beside the use of the coherency fabric, the device units will have to
set the attribute flag of the decoding address window to select the
accurate coherency process for the memory transaction. This is done
each device driver programs the DRAM address windows. The value of the
attribute set by the driver is retrieved through the
orion_addr_map_cfg struct filled during the early initialization of
the platform.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
2012-11-21 17:07:49 +01:00
Gregory CLEMENT
009f13159b arm: mvebu: Add support for coherency fabric in mach-mvebu
The Armada 370 and Armada XP SOCs have a coherency fabric unit which
is responsible for ensuring hardware coherency between all CPUs and
between CPUs and I/O masters. This patch provides the basic support
needed for SMP.

Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
2012-11-21 16:49:06 +01:00