summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-mvebu/coherency.c
Commit message (Collapse)AuthorAgeFilesLines
* cpu/hotplug: Cleanup state namesThomas Gleixner2016-12-251-1/+1
| | | | | | | | | | | | | | | | | When the state names got added a script was used to add the extra argument to the calls. The script basically converted the state constant to a string, but the cleanup to convert these strings into meaningful ones did not happen. Replace all the useless strings with 'subsys/xxx/yyy:state' strings which are used in all the other places already. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Siewior <bigeasy@linutronix.de> Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* Merge branch 'smp-hotplug-for-linus' of ↵Linus Torvalds2016-07-291-13/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull smp hotplug updates from Thomas Gleixner: "This is the next part of the hotplug rework. - Convert all notifiers with a priority assigned - Convert all CPU_STARTING/DYING notifiers The final removal of the STARTING/DYING infrastructure will happen when the merge window closes. Another 700 hundred line of unpenetrable maze gone :)" * 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (70 commits) timers/core: Correct callback order during CPU hot plug leds/trigger/cpu: Move from CPU_STARTING to ONLINE level powerpc/numa: Convert to hotplug state machine arm/perf: Fix hotplug state machine conversion irqchip/armada: Avoid unused function warnings ARC/time: Convert to hotplug state machine clocksource/atlas7: Convert to hotplug state machine clocksource/armada-370-xp: Convert to hotplug state machine clocksource/exynos_mct: Convert to hotplug state machine clocksource/arm_global_timer: Convert to hotplug state machine rcu: Convert rcutree to hotplug state machine KVM/arm/arm64/vgic-new: Convert to hotplug state machine smp/cfd: Convert core to hotplug state machine x86/x2apic: Convert to CPU hotplug state machine profile: Convert to hotplug state machine timers/core: Convert to hotplug state machine hrtimer: Convert to hotplug state machine x86/tboot: Convert to hotplug state machine arm64/armv8 deprecated: Convert to hotplug state machine hwtracing/coresight-etm4x: Convert to hotplug state machine ...
| * ARM/mvebu: Convert to hotplug state machineSebastian Andrzej Siewior2016-07-141-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Install the callbacks via the state machine. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Gregory Clement <gregory.clement@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: rt@linutronix.de Link: http://lkml.kernel.org/r/20160713153333.503198935@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
* | ARM: mvebu: map PCI I/O regions strongly orderedThomas Petazzoni2016-06-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order for HW I/O coherency to work on Cortex-A9 based Marvell SoCs, all MMIO registers must be mapped strongly ordered. In commit 1c8c3cf0b5239 ("ARM: 8060/1: mm: allow sub-architectures to override PCI I/O memory type") we implemented a new function, pci_ioremap_set_mem_type(), that allow sub-architecture code to override the memory type used to map PCI I/O regions. In the discussion around this patch series [1], Arnd Bergmann made the comment that maybe all PCI I/O regions should be mapped strongly-ordered, which would have made our proposal to add pci_ioremap_set_mem_type() irrelevant. So, we submitted a patch [2] that did what Arnd suggested. However, Russell in the end merged our initial proposal to add pci_ioremap_set_mem_type(), but it was never used anywhere. Further discussion with Arnd and other folks on IRC lead to the conclusion that in fact using strongly-ordered for all platforms was maybe not desirable, and therefore, using pci_ioremap_set_mem_type() was the most appropriate solution. As a consequence, this commit finally adds the pci_ioremap_set_mem_type() call in the mach-mvebu platform code, which was originally part of our initial patch series [3] and is necessary for the whole mechanism to work. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256565.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256755.html [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256563.html Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* | ARM: mvebu: fix HW I/O coherency related deadlocksThomas Petazzoni2016-06-161-14/+8
|/ | | | | | | | | | | | | | | | | | | | | Until now, our understanding for HW I/O coherency to work on the Cortex-A9 based Marvell SoC was that only the PCIe regions should be mapped strongly-ordered. However, we were still encountering some deadlocks, especially when testing the CESA crypto engine. After checking with the HW designers, it was concluded that all the MMIO registers should be mapped as strongly ordered for the HW I/O coherency mechanism to work properly. This fixes some easy to reproduce deadlocks with the CESA crypto engine driver (dmcrypt on a sufficiently large disk partition). Tested-by: Terry Stockert <stockert@inkblotadmirer.me> Tested-by: Romain Perier <romain.perier@free-electrons.com> Cc: Terry Stockert <stockert@inkblotadmirer.me> Cc: Romain Perier <romain.perier@free-electrons.com> Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: mvebu: mark mvebu_hwcc_pci_nb as __maybe_unusedArnd Bergmann2016-02-251-1/+1
| | | | | | | | | | | | | | | | The coherency notifier block is only used when CONFIG_PCI is enabled, otherwise we get a warning: arch/arm/mach-mvebu/coherency.c:110:30: warning: 'mvebu_hwcc_pci_nb' defined but not used [-Wunused-variable] There is no nice way to use an if(IS_ENABLED()) check here to let the compiler know that it might be used, so let's mark the structure as __maybe_unused. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: mvebu: add support to clear shared L2 bit on Armada XPThomas Petazzoni2015-09-291-0/+60
| | | | | | | | | | | | | | | | For optimal performance, in a HW I/O coherency context such as the one used on Armada XP, the shared L2 bit of the CPU configuration register should be cleared. This commit adjusts the coherency fabric code used by Marvell EBU processors to clear this bit on Armada XP. Since it's a per-CPU register, it's cleared in set_cpu_coherent() for the boot CPU, and through a CPU notifier for the non-boot CPUs. [gregory.clement@free-electrons.com: rebasd on 4.3-rc1] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: mvebu: prepare set_cpu_coherent() for future extensionNadav Haklai2015-07-251-12/+17
| | | | | | | | | | | | | | | | This patch prepares the set_cpu_coherent() function in coherency.c to be extended to support other SoCs than Armada XP. It will be needed on Armada 38x to re-enable the coherency after exiting from suspend to RAM. This preparation simply moves the function further down in coherency.c so that it can use coherency_type(), and uses that function to only do the Armada XP specific work if we are on Armada XP. Signed-off-by: Nadav Haklai <nadavh@marvell.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: make of_device_ids constUwe Kleine-König2015-02-191-1/+1
| | | | | | | | | | | | | of_device_ids (i.e. compatible strings and the respective data) are not supposed to change at runtime. All functions working with of_device_ids provided by <linux/of.h> work with const of_device_ids. So mark the non-const structs in arch/arm as const, too. While at it also add some __initconst annotations. Acked-by: Jason Cooper <jason@lakedameon.net> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* Merge tag 'soc-for-linus' of ↵Linus Torvalds2015-02-171-55/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC platform changes from Olof Johansson: "New and updated SoC support. Also included are some cleanups where the platform maintainers hadn't separated cleanups from new developent in separate branches. Some of the larger things worth pointing out: - A large set of changes from Alexandre Belloni and Nicolas Ferre preparing at91 platforms for multiplatform and cleaning up quite a bit in the process. - Removal of CSR's "Marco" SoC platform that never made it out to the market. We love seeing these since it means the vendor published support before product was out, which is exactly what we want! New platforms this release are: - Conexant Digicolor (CX92755 SoC) - Hisilicon HiP01 SoC - CSR/sirf Atlas7 SoC - ST STiH418 SoC - Common code changes for Nvidia Tegra132 (64-bit SoC) We're seeing more and more platforms having a harder time labelling changes as cleanups vs new development -- which is a good sign that we've come quite far on the cleanup effort. So over time we might start combining the cleanup and new-development branches more" * tag 'soc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (124 commits) ARM: at91/trivial: unify functions and machine names ARM: at91: remove at91_dt_initialize and machine init_early() ARM: at91: change board files into SoC files ARM: at91: remove at91_boot_soc ARM: at91: move alternative initial mapping to board-dt-sama5.c ARM: at91: merge all SOC_AT91SAM9xxx ARM: at91: at91rm9200: set idle and restart from rm9200_dt_device_init() ARM: digicolor: select syscon and timer ARM: zynq: Simplify SLCR initialization ARM: zynq: PM: Fixed simple typo. ARM: zynq: Setup default gpio number for Xilinx Zynq ARM: digicolor: add low level debug support ARM: initial support for Conexant Digicolor CX92755 SoC ARM: OMAP2+: Add dm816x hwmod support ARM: OMAP2+: Add clock domain support for dm816x ARM: OMAP2+: Add board-generic.c entry for ti81xx ARM: at91: pm: remove warning to remove SOC_AT91SAM9263 usage ARM: at91: remove unused mach/system_rev.h ARM: at91: stop using HAVE_AT91_DBGUx ARM: at91: fix ordering of SRAM and PM initialization ...
| * ARM: mvebu: use arm_coherent_dma_ops and re-enable hardware I/O coherencyThomas Petazzoni2015-01-191-55/+3
| | | | | | | | | | | | | | | | | | | | | | | | Now that we have enabled automatic I/O synchronization barriers, we no longer need any explicit barriers. We can therefore simplify arch/arm/mach-mvebu/coherency.c by using the existing arm_coherent_dma_ops instead of our custom mvebu_hwcc_dma_ops, and re-enable hardware I/O coherency support. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Remove forgotten comment] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
* | ARM: mvebu: don't set the PL310 in I/O coherency mode when I/O coherency is ↵Thomas Petazzoni2015-01-281-0/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | disabled Since commit f2c3c67f00 (merge commit that adds commit "ARM: mvebu: completely disable hardware I/O coherency"), we disable I/O coherency on Armada EBU platforms. However, we continue to initialize the coherency fabric, because this coherency fabric is needed on Armada XP for inter-CPU coherency. Unfortunately, due to this, we also continued to execute the coherency fabric initialization code for Armada 375/38x, which switched the PL310 into I/O coherent mode. This has the effect of disabling the outer cache sync operation: this is needed when I/O coherency is enabled to work around a PCIe/L2 deadlock. But obviously, when I/O coherency is disabled, having the outer cache sync operation is crucial. Therefore, this commit fixes the armada_375_380_coherency_init() so that the PL310 is switched to I/O coherent mode only if I/O coherency is enabled. Without this fix, all devices using DMA are broken on Armada 375/38x. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Cc: <stable@vger.kernel.org> # v3.8+
* ARM: mvebu: completely disable hardware I/O coherencyThomas Petazzoni2015-01-171-1/+6
| | | | | | | | | | | | | | | The current hardware I/O coherency is known to cause problems with DMA coherent buffers, as it still requires explicit I/O synchronization barriers, which is not compatible with the semantics expected by the Linux DMA coherent buffers API. So, in order to have enough time to validate a new solution based on automatic I/O synchronization barriers, this commit disables hardware I/O coherency entirely. Future patches will re-enable it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by: Andrew Lunn <andrew@lunn.ch>
* ARM: mvebu: Clean-up the Armada XP supportGregory CLEMENT2014-11-221-1/+0
| | | | | | | | | | | | | | | | | | | | This patch removes the unneeded include of the armada-370-xp.h header. It also moves some declarations from this file into more accurate places. Finally, it also adds a comment explaining that we can't remove yet the smp field in the dt machine struct due to backward compatibly of the device tree. In a few releases, when the old device tree will be obsolete, we will be able to remove the smp field and then the armada-370-xp.h header. 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-2-git-send-email-gregory.clement@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: update comments in coherency.cThomas Petazzoni2014-11-221-2/+3
| | | | | | | | | | | The coherency.c top-level comment mentions that it supports the coherency fabric for Armada 370 and XP, but it also supports the coherency fabric on Armada 375 and 38x, so this commit updates the comment accordingly. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1415871540-20302-6-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: remove Armada 375 Z1 workaround for I/O coherencyThomas Petazzoni2014-11-221-166/+3
| | | | | | | | | | | | | | | | | | | This reverts commit 5ab5afd8ba83 ("ARM: mvebu: implement Armada 375 coherency workaround"), since we are removing the support for the very early Z1 revision of the Armada 375 SoC. This commit is an exact revert, with two exceptions: - minor adaptations needed due to other changes that have taken place in coherency.c since the original commit - keep the definition of pr_fmt. This shouldn't originally have been part of the Armada 375 Z1 workaround commit since it had nothing to do with it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1415871540-20302-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: remove unused register offset definitionThomas Petazzoni2014-11-221-2/+0
| | | | | | | | | | Since commit b21dcafea36d ("arm: mvebu: remove dependency of SMP init on static I/O mapping"), the COHERENCY_FABRIC_CFG_OFFSET register offset definition is no longer used, so this commit removes it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1415871540-20302-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XPThomas Petazzoni2014-11-221-14/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabling the hardware I/O coherency on Armada 370, Armada 375, Armada 38x and Armada XP requires a certain number of conditions: - On Armada 370, the cache policy must be set to write-allocate. - On Armada 375, 38x and XP, the cache policy must be set to write-allocate, the pages must be mapped with the shareable attribute, and the SMP bit must be set Currently, on Armada XP, when CONFIG_SMP is enabled, those conditions are met. However, when Armada XP is used in a !CONFIG_SMP kernel, none of these conditions are met. With Armada 370, the situation is worse: since the processor is single core, regardless of whether CONFIG_SMP or !CONFIG_SMP is used, the cache policy will be set to write-back by the kernel and not write-allocate. Since solving this problem turns out to be quite complicated, and we don't want to let users with a mainline kernel known to have infrequent but existing data corruptions, this commit proposes to simply disable hardware I/O coherency in situations where it is known not to work. And basically, the is_smp() function of the kernel tells us whether it is OK to enable hardware I/O coherency or not, so this commit slightly refactors the coherency_type() function to return COHERENCY_FABRIC_TYPE_NONE when is_smp() is false, or the appropriate type of the coherency fabric in the other case. Thanks to this, the I/O coherency fabric will no longer be used at all in !CONFIG_SMP configurations. It will continue to be used in CONFIG_SMP configurations on Armada XP, Armada 375 and Armada 38x (which are multiple cores processors), but will no longer be used on Armada 370 (which is a single core processor). In the process, it simplifies the implementation of the coherency_type() function, and adds a missing call to of_node_put(). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: e60304f8cb7bb545e79fe62d9b9762460c254ec2 ("arm: mvebu: Add hardware I/O Coherency support") Cc: <stable@vger.kernel.org> # v3.8+ Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1415871540-20302-3-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: add missing of_node_put() call in coherency.cThomas Petazzoni2014-11-071-0/+2
| | | | | | | | | | | | There is a missing of_node_put() to decrement the device_node reference counter after a of_find_matching_node() in coherency_init(). Fixes: 501f928e0097 ("ARM: mvebu: add a coherency_available() call") Cc: <stable@vger.kernel.org> # v3.16+ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1414423955-5933-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: Fix coherency bus notifiers by using separate notifiersEzequiel Garcia2014-07-081-1/+5
| | | | | | | | | | | | | | | | 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: b0063aad5dd8 ("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>
* ARM: mvebu: coherency: fix registration of PCI bus notifier when !PCIThomas Petazzoni2014-05-221-0/+2
| | | | | | | | | | | | | | | Commit b0063aad5dd8 ("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>
* ARM: mvebu: implement L2/PCIe deadlock workaroundThomas Petazzoni2014-05-221-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: mvebu: use hardware I/O coherency also for PCI devicesThomas Petazzoni2014-05-161-5/+16
| | | | | | | | | | | | | | | | | | | 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>
* ARM: mvebu: conditionalize Armada 375 coherency workaroundThomas Petazzoni2014-05-081-2/+8
| | | | | | | | | | 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>
* ARM: mvebu: Split low level functions to manipulate HW coherencyGregory CLEMENT2014-05-081-3/+5
| | | | | | | | | | | | | | | 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>
* ARM: mvebu: Remove the unused argument of set_cpu_coherent()Gregory CLEMENT2014-05-081-2/+2
| | | | | | | | | | 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>
* ARM: mvebu: ll_set_cpu_coherent always uses the current CPUGregory CLEMENT2014-05-081-7/+5
| | | | | | | | | | | 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>
* ARM: mvebu: remove the address parameter for ll_set_cpu_coherentGregory CLEMENT2014-05-081-3/+3
| | | | | | | | | | | | | | | 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>
* ARM: mvebu: add Armada 38x support to the coherency codeThomas Petazzoni2014-04-241-3/+11
| | | | | | | | | | | | | 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>
* ARM: mvebu: implement Armada 375 coherency workaroundThomas Petazzoni2014-04-241-3/+165
| | | | | | | | | | | | | | 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>
* ARM: mvebu: add Armada 375 support to the coherency codeThomas Petazzoni2014-04-241-0/+14
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: mvebu: ARM: mvebu: use of_find_matching_node_and_match() in coherency.cThomas Petazzoni2014-04-241-6/+3
| | | | | | | | | | | | | 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>
* ARM: mvebu: add a coherency_available() callThomas Petazzoni2014-04-241-8/+22
| | | | | | | | | | | | | 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>
* ARM: mvebu: prepare coherency code to support more SOCsThomas Petazzoni2014-04-241-14/+33
| | | | | | | | | | | | | | | | | | | | | 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>
* ARM: mvebu: fix some sparse warningsJisheng Zhang2013-11-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ARM: mvebu: add missing of_node_put() to fix reference leakJisheng Zhang2013-09-181-1/+7
| | | | | | | | | | | | | 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
* arm: delete __cpuinit/__CPUINIT usage from all ARM usersPaul Gortmaker2013-07-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* arm: mvebu: fix coherency_late_init() for multiplatformThomas Petazzoni2013-06-201-2/+3
| | | | | | | | | | | | | | | | | | | | As noticed by Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>, commit 865e0527d2d7 ('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 865e0527d2d7 ('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>
* arm: mvebu: don't hardcode a physical address in headsmp.SThomas Petazzoni2013-06-131-0/+12
| | | | | | | | | | | | | 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>
* arm: mvebu: avoid hardcoded virtual address in coherency codeThomas Petazzoni2013-06-131-10/+10
| | | | | | | | | | | | | | | | | | 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>
* arm: mvebu: remove dependency of SMP init on static I/O mappingThomas Petazzoni2013-06-131-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* arm: mvebu: Add hardware I/O Coherency supportGregory CLEMENT2012-11-211-0/+73
| | | | | | | | | | | | | | | | | | | | | | | 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>
* arm: mvebu: Add support for coherency fabric in mach-mvebuGregory CLEMENT2012-11-211-0/+82
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 05:17:52 +0000