summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-uniphier/platsmp.c
AgeCommit message (Collapse)AuthorFilesLines
2016-08-29ARM: uniphier: remove SoC-specific SMP codeMasahiro Yamada1-209/+0
The UniPhier architecture (32bit) switched over to PSCI. Remove the SoC-specific SMP operations. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-03ARM: uniphier: drop code for old DT bindingMasahiro Yamada1-13/+5
Commit 307d40c56b0c ("ARM: uniphier: rework SMP code to support new System Bus binding") added a new DT binding for SMP code, but still kept old code for the backward compatibility. Linux 4.6 was out with both bindings supported, so it should not hurt to drop the old code now. Moreover, the mainline code are currently not used for any of our products, so this change has no impact on our customers in any way. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-05-18Merge tag 'armsoc-soc' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC platform updates from Arnd Bergmann: "We get support for three new 32-bit SoC platforms this time. The amount of changes in arch/arm for any of them is miniscule, as all the interesting code is in device driver subsystems (irqchip, clk, pinctrl, ...) these days. I'm listing them here, as the addition of the Kconfig statement is the main relevant milestone for a new platform. In each case, some drivers are are shared with existing platforms, while other drivers are added for v4.7 as well, or come in a later release. - The Aspeed platform is probably the most interesting one, this is what most whitebox servers use as their baseboard management controller. We get support for the very common ast2400 and ast2500 SoCs. The OpenBMC project focuses on this chip, and the LWN article about their ELC 2016 presentation at https://lwn.net/Articles/683320/ triggered the submission, but the code comes from IBM's OpenPOWER team rather than the team at Facebook. There are still a lot more drivers that need to get added over time, and I hope both teams can work together on that. - OXNAS is an old platform for Network Attached Storage devices from Oxford Semiconductor. There are models with ARM10 (!) and ARM11MPCore cores, but for now, we only support the original ARM9 based versions. The product lineup was subsequently part of PLX, Avago and now the new Broadcom Ltd. https://wiki.openwrt.org/doc/hardware/soc/soc.oxnas has some more information. - V2M-MPS2 is a prototyping platform from ARM for their Cortex-M cores and is related to the existing Realview / Versatile Express lineup, but without MMU. We now support various NOMMU platforms, so adding a new one is fairly straightforward. http://infocenter.arm.com/help/topic/com.arm.doc.100112_0100_03_en/ has detailed information about the platform. Other noteworthy updates: - Work on LPC32xx has resumed, and Vladimir Zapolskiy and Sylvain Lemieux are now maintaining the platform. This is an older ARM9 based platform from NXP (not Freescale), but it remains in use in embedded markets. - Kevin Hilman is now co-maintaining the Amlogic Meson platform for both 32-bit and 64-bit ARM, and started contributing some patches. - As is often the case, work on the OMAP platforms makes up the bulk of the actual SoC code changes in arch/arm, but there isn't a lot of that either" * tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (42 commits) MAINTAINERS: ARM/Amlogic: add co-maintainer, misc. updates MAINTAINERS: add ARM/NXP LPC32XX SoC specific drivers to the section MAINTAINERS: add new maintainers of NXP LPC32xx SoC MAINTAINERS: move ARM/NXP LPC32xx record to ARM section arm: Add Aspeed machine ARM: lpc32xx: remove duplicate const on lpc32xx_auxdata_lookup ARM: lpc32xx: remove leftovers of legacy clock source and provider drivers ARM: lpc32xx: remove reboot header file ARM: dove: Remove CLK_IS_ROOT ARM: orion5x: Remove CLK_IS_ROOT ARM: mv78xx0: Remove CLK_IS_ROOT ARM: davinci: da850: use clk->set_parent for async3 ARM: davinci: Move clock init after ioremap. MAINTAINERS: Update ARM Versatile Express platform entry ARM: vexpress/mps2: introduce MPS2 platform MAINTAINERS: add maintainer entry for ARM/OXNAS platform ARM: Add new mach-oxnas irqchip: versatile-fpga: add new compatible for OX810SE SoC ARM: uniphier: correct the call order of of_node_put() MAINTAINERS: fix stale TI DaVinci entries ...
2016-04-26ARM: uniphier: correct the call order of of_node_put()Masahiro Yamada1-2/+2
Put nodes after of_address_to_resource() in case the nodes might be released while parsing in them. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2016-04-12ARM: uniphier: drop weird sizeof()Masahiro Yamada1-1/+1
My intention was to ioremap a 4-byte register. Coincidentally enough, sizeof(SZ_4) equals to SZ_4, but this code is weird anyway. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2016-03-18ARM: uniphier: rework SMP code to support new System Bus bindingMasahiro Yamada1-9/+16
During the review process of the UniPhier System Bus driver (drivers/bus/uniphier.c), the current binding of the System Bus Controller turned out to be no good. In order to use the driver, some nodes in the device trees must be tweaked. It would also have impacts on the SMP code because the SMP related registers are located in the System Bus Controller block. This commit reworks the smp_operations to support the new binding, but still supports the old binding, too. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2016-03-18ARM: uniphier: add missing of_node_put()Masahiro Yamada1-0/+1
This node pointer is allocated by of_find_compatible_node() in this function. It should be put before exitting this function. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-12-01ARM: use const and __initconst for smp_operationsMasahiro Yamada1-1/+1
These smp_operations structures are not over-written, so add "const" qualifier and replace __initdata with __initconst. Also, add "static" where it is possible. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Moritz Fischer <moritz.fischer@ettus.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org> # qcom part Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Patrice Chotard <patrice.chotard@st.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Wei Xu <xuwei5@hisilicon.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Shawn Guo <shawnguo@kernel.org> Acked-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-10-27ARM: uniphier: rework SMP operations to use trampoline codeMasahiro Yamada1-30/+155
The complexity of the boot sequence of UniPhier SoC family is a PITA due to the following hardware limitations: [1] No dedicated on-chip SRAM SoCs in general have small SRAM, on which a tiny firmware or a boot loader can run before SDRAM is initialized. As UniPhier SoCs do not have any dedicated SRAM accessible from CPUs, the locked outer cache is used instead. Due to the ARM specification, to have access to the outer cache, the MMU must be enabled. This is done for all CPU cores by the program hard-wired in the boot ROM. The boot ROM code loads a small amount of program (this is usually SPL of U-Boot) from a non-volatile device onto the locked outer cache, and the primary CPU jumps to it. The secondary CPUs stay in the boot ROM until they are kicked by the primary CPU. [2] CPUs can not directly jump to SDRAM address space As mentioned above, the MMU is enable for all the CPUs with the page table hard-wired in the boot ROM. Unfortunately, the page table only has minimal sets of valid sections; all the sections of SDRAM address space are zero-filled. That means all the CPUs, including secondary ones, can not jump directly to SDRAM address space. So, the primary CPU must bring up secondary CPUs to accessible address mapped onto the outer cache, then again kick them to SDRAM address space. Before this commit, this complex task was done with help of a boot loader (U-Boot); U-Boot SPL brings up the secondary CPUs to the entry of U-Boot SPL and they stay there until they are kicked by Linux. This is not nice because a boot loader must put the secondary CPUs into a certain state expected by the kernel. It makes difficult to port another boot loader because the boot loader and the kernel must work in sync to wake up the secondary CPUs. This commit reworks the SMP operations so that they do not rely on particular boot loader implementation; the SMP operations (platsmp.c) put trampoline code (headsmp.S) on a locked way of the outer cache. The secondary CPUs jump from the boot ROM to secondary_entry via the trampoline code. The boot loader no longer needs to take care of SMP. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-08-13ARM: uniphier: drop v7_invalidate_l1 call at secondary entryMasahiro Yamada1-7/+1
This is unnecessary since commit 02b4e2756e01 ("ARM: v7 setup function should invalidate L1 cache"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-05-12ARM: UniPhier: add basic support for UniPhier architectureMasahiro Yamada1-0/+90
Initial commit for a new SoC family, UniPhier, developed by Socionext Inc. (formerly, System LSI Business Division of Panasonic Corporation). This commit includes a minimal set of components for booting the kernel, including SMP support. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>