- 17 Dec, 2015 3 commits
-
-
Arnd Bergmann authored
Moving ARCH_VERSATILE into ARCH_MULTIPLATFORM means that it no longer works as the default target for MMU-less kernels. While we might want to get that working again in the future, it's also a rather bad default, and it makes sense to make ARM_SINGLE_V7M the default because that is what realistically all NOMMU users on ARM are using, and it actually is what gets selected by default in the absence of versatile in the choice statement. Related to this, 'allnoconfig' kernels fail to link with the new default, as they do not include a machine record: arm-linux-gnueabi-ld: no machine record defined For ARCH_MULTIPLATFORM kernels, we avoid this error by using a default machine descriptor that works for all trivial platforms, like ARCH_VIRT. The same reasoning applies for ARM_SINGLE_V7M, as that can also boot with empty machine descriptors both on qemu and on real hardware, as long as all the drivers are present. We could also follow up with a patch to remove the existing machine descriptors for the ARMv7M platforms, the only callback pointer the four platforms contain today is the armv7m_restart handler and we can simply make that the default for v7M with an add-on patch. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
I accidentally move the DEBUG_LL_UART_EFM32 option when sorting all other options alphanumerically, but it belongs into the same group as DEBUG_LL_UART_8250 and DEBUG_LL_UART_PL01X. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 1dc93416 ("ARM: debug-ll: reorder Kconfig alphanumerically")
-
Arnd Bergmann authored
The debug-ll infrastructure can be configured in two ways, either by selecting a platform specific debug option, or by picking one of the generic options (8250 or pl01x typically). For compatibility with multiplatform kernels, we have changed a couple of platforms to use the former method now when they used to use the latter. Unfortunately, this broke the defconfigs because now they still enable CONFIG_DEBUG_LL_UART_PL01X or CONFIG_DEBUG_LL_UART_8250, and we no longer configure the correct register addresses automatically. Embarrassingly, this was only found in linux-next when the defconfig builds turned up errors for multiple people, and I had not caught those in my own tests, which were done using the randconfig fixes patchset on top, and that has a workaround to avoid a build error when the addresses are not configured. The error was something like: .config:2010:warning: symbol value '' invalid for DEBUG_UART_PHYS .config:2011:warning: symbol value '' invalid for DEBUG_UART_VIRT This patch avoids the problem by removing the respective statements from the defconfig files. Any out of tree defconfig files on the platforms I have changed will have to do the same change or run into the build error above. Any users that have a full .config already set the correct DEBUG_UART_PHYS/VIRT addresses and do not need to change anything. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 4db22c10 ("ARM: debug-ll: rework integrator/versatile handling") Fixes: f06455fa ("ARM: debug-ll: rework ep93xx handling") Fixes: c047f529 ("ARM: debug-ll: reorganize mvebu debug uart config") Fixes: 59bd4c38 ("ARM: debug-ll: rework lpc32xx handling")
-
- 15 Dec, 2015 33 commits
-
-
git://git.infradead.org/linux-mvebuArnd Bergmann authored
Merge "mvebu soc for 4.5 (part 1)" from Gregory CLEMENT: - orion5x/mv78xx0 multiplatform conversion - legacy dove PMU support conversion * tag 'mvebu-soc-4.5-1' of git://git.infradead.org/linux-mvebu: ARM: dove: convert legacy dove to PMU support soc: dove: add legacy support to PMU driver ARM: orion5x: multiplatform support ARM: orion5x: clean up mach/*.h headers ARM: mv78xx0: multiplatform support ARM: mv78xx0: clean up mach/*.h headers ARM: orion: use SPARSE_IRQ everywhere ARM: orion: always use MULTI_IRQ_HANDLER ARM: orion: move watchdog setup to mach-orion5x Conflicts: arch/arm/Kconfig arch/arm/mach-dove/include/mach/entry-macro.S arch/arm/mach-orion5x/include/mach/entry-macro.S
-
Arnd Bergmann authored
Merge tag 'realview-base-armsoc-1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into next/multiplatform Merge "Realview multiplatform support" from Linus Walleij: The board and infrastructure changes for RealView multiplatform and extended DT support. * tag 'realview-base-armsoc-1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator: ARM: realview: add an DT SMP boot method ARM: realview: select SP810 and ICST for the DT variant soc: versatile: add support for the PB11MPCore clk: versatile-icst: add device tree support clk: versatile-icst: refactor to allocate regmap separately clk: versatile-icst: convert to use regmap ARM: realview: remove private barrier implementation ARM: no longer force unbuffered DMA for realview clk/realview: stop using machine headers ARM: realview: don't map undefined PCI registers ARM: realview: remove sparsemem hack Conflicts: drivers/clk/versatile/Kconfig
-
Arnd Bergmann authored
Merge "ARM Versatile multi-platform support" from Rob Herring: Arnd lit a fire under me to dust this off and get it merged. So here it is. The main change from prior version is I merged all the code to a single file. It's a bigger patch than I'd like, but I don't think trying to do it in multiple steps is worth it. This is dependent on some solution for the default platform choice on !MMU builds (allnoconfig) as it can't be Versatile after this series. Arnd has some ideas on how to address that. This is tested under QEMU. Linus previously tested this on actual h/w and had a problem with the display identification which needs investigation or agreement to worry about it if and when someone actually cares. * versatile/multiplatform: ARM: versatile: convert to multi-platform ARM: versatile: merge mach code into a single file ARM: versatile: switch to DT only booting and remove legacy code ARM: versatile: add DT based PCI detection Acked-by: Marc Zyngier <marc.zyngier@arm.com>
-
Rob Herring authored
Now that all the prerequisites are in place, we can enable Versatile boards for multi-platform kernels. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Rob Herring authored
With DT-only support now in place and most of the legacy code removed, the separation of core.c and versatile_dt.c makes little sense. The headers in mach include directory also have to move for multi-platform support, but with a single .c file the remaining definitions needed can also be moved into the versatile_dt.c. In the move, the system registers and IB2 registers are converted to run-time mappings and all register accesses converted to use readl/writel. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Rob Herring authored
With DT support for clocks, irqchips, timers, and PCI now in place, DT based booting has feature parity with non-DT legacy boot. The final piece is actually enabling common clock support on Versatile. Enabling full DT support requires either removing the old Versatile clock code, updating the legacy boot to use the common clock code, or making DT and legacy boot mutually exclusive. Given that removing legacy boot code is the goal anyway, I am going with the 1st option. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Mike Turquette <mturquette@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Rob Herring authored
Disable the Versatile PCI DT node when no PCI backplane is detected. This will prevent the Versatile PCI driver from probing when PCI is not populated. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
The ezx platform contains multiple machine descriptors, but not all of them use all of the data structures, and it's possible to disable all of the machines, which produces some harmless warnings: mach-pxa/ezx.c:53:26: warning: 'ezx_pwm_lookup' defined but not used [-Wunused-variable] mach-pxa/ezx.c:86:31: warning: 'ezx_fb_info_1' defined but not used [-Wunused-variable] mach-pxa/ezx.c:107:31: warning: 'ezx_fb_info_2' defined but not used [-Wunused-variable] mach-pxa/ezx.c:113:32: warning: 'ezx_devices' defined but not used [-Wunused-variable] mach-pxa/ezx.c:117:22: warning: 'ezx_pin_config' defined but not used [-Wunused-variable] This marks all those structures as __maybe_unused to avoid the warnings. Obviously a configuration that contains the ezx platform but no specific model is a bit silly, but it should not cause compile-time warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
-
Arnd Bergmann authored
The raumfeld.c file contains three similar machine definitions, each with their own init function. If one or more of them are disabled, we get compile-time warnings: arm/mach-pxa/raumfeld.c:1070:123: warning: 'raumfeld_connector_init' defined but not used [-Wunused-function] arm/mach-pxa/raumfeld.c:1082:123: warning: 'raumfeld_speaker_init' defined but not used [-Wunused-function] This marks the functions as __maybe_unused to avoid the warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Mack <daniel@zonque.org>
-
Arnd Bergmann authored
In an old commit, we worked around the duplicate definition of GPIO24_SSP1_SFRM in cm-x2xx.c, which includes files for both pxa25x and pxa27x. Apparently the problem has come back and we now have four additional duplicate symbols that cause warnings: In file included from /git/arm-soc/arch/arm/mach-pxa/pxa27x.h:7:0, from /git/arm-soc/arch/arm/mach-pxa/cm-x2xx.c:27: /git/arm-soc/arch/arm/mach-pxa/mfp-pxa27x.h:21:0: warning: "GPIO86_GPIO" redefined #define GPIO86_GPIO MFP_CFG_IN(GPIO86, AF0) This uses the same hack as before and undefines all symbols that are defined more than once. Fortunately, cm-x2xx does not need any of these. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
-
Arnd Bergmann authored
* mmp/multiplatform: ARM: mmp: avoid unused functions ARM: mmp: move into ARCH_MULTIPLATFORM ARM: mmp: make all header files local ARM: mmp: make plat-pxa build standalone ARM: mmp: remove remaining legacy pxa-dma support ARM: mohawk: allow building with MMU disabled ARM: make xscale iwmmxt code multiplatform aware clk: mmp: stop using platform headers
-
Arnd Bergmann authored
* s3c64xx/multiplatform: ARM: s3c64xx: allow building without board support ARM: s3c64xx: multiplatform support ARM: s3c64xx: use common debug-ll implementation ARM: s3c64xx: use new adc/touchscreen driver iio: exynos-adc: add experimental touchscreen support ARM: s3c64xx: enable sparse IRQ support ARM: s3c64xx: prepare initcalls for multiplatform gpio: samsung: move gpio-samsung driver back to platform code ASoC: samsung/smartq: use dynamic registration Input: s3c2410_ts: fix S3C_ADC dependency Conflicts: arch/arm/Kconfig.debug
-
Arnd Bergmann authored
* multiplatform/debug-ll: ARM: debug-ll: reorder Kconfig alphanumerically ARM: debug-ll: rework footbridge handling ARM: debug-ll: rework lpc32xx handling ARM: debug-ll: rework gemini handling ARM: debug-ll: rework integrator/versatile handling ARM: debug-ll: rework SPEAr handling ARM: debug-ll: rework ep93xx handling ARM: debug-ll: reorganize mvebu debug uart config ARM: debug-ll: fix UART configuration with ARCH_KEYSTONE
-
Arnd Bergmann authored
The file has gotten a little out of sync, as platforms got added in the wrong place, or have been renamed. This moves the options around, but should not change any functionality. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Footbridge has two debug ports that are handled a bit differently: The 8250 port uses the normal debug/8250.S implementation that is shared with a lot of other platforms, but it relies on the DEBUG_UART_8250 option to be turned on automatically instead of being selected by DEBUG_FOOTBRIDGE_COM1 as we do for most other platforms. I'm changing this to use a 'select' and change the dependency to the debug symbol rather than the platform symbol for consistency. The DC21285 UART has a separate top-level option, and relies on the traditional include/mach/debug-macro.S method. With the s3c64xx multiplatform series queued up for 4.5, it is now the last one that does this, so by moving this file to include/debug/dc21285.S, we can get all platforms to do things the same way. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
LPC32xx can not yet be configured in a multiplatform kernel, but if we ever get there, enabling one of the LPC32xx platforms while trying to use DEBUG_LL for another platform can default to the wrong UART address, as the options are purely based on the architecture being enabled or not. This changes the logic to use the LPC32xx default addresses only if we have also picked the respective Kconfig symbols introduced here. While we're at it, this also reorders the virtual address as it should be. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Vladimir Zapolskiy <vz@mleia.com>
-
Arnd Bergmann authored
Gemini can not yet be configured in a multiplatform kernel, but if we ever get there, enabling one of the gemini platforms while trying to use DEBUG_LL for another platform can default to the wrong UART address, as the options are purely based on the architecture being enabled or not. This changes the logic to use the gemini default addresses and the flow control settings only if we have also picked the respective Kconfig symbols introduced here. While we're at it, this also reorders the virtual address as it should be. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
-
Arnd Bergmann authored
Enabling one of the integrator platforms in a multiplatform kernel while trying to use DEBUG_LL for another platform can default to the wrong UART address, as the options are purely based on the architecture being enabled or not. This changes the logic to use the integrator default addresses only if we have also picked the respective Kconfig symbols introduced here. Versatile is not yet part of multiplatform, but hopefully soon will be, so we do the same change for versatile as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Enabling one of the SPEAr platforms in a multiplatform kernel while trying to use DEBUG_LL for another platform can default to the wrong UART address, as the options are purely based on the architecture being enabled or not. This changes the logic to use the SPEAr default addresses only if we have also picked the respective Kconfig symbols introduced here. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
This makes ep93xx debug-ll handling more consistent with the other platforms, by adding a separate Kconfig symbol for it that in turn selects the standard DEBUG_UART_PL01X symbol. We still have to pick a physical address even if DEBUG_LL is disabled here, because the EP93xx uncompress output code uses CONFIG_DEBUG_UART_PHYS. If we ever move to multiplatform support, this can go away. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
As we are moving dove/mv78xx0/orion into multiplatform, the debug-ll configuration options for these platforms are conflicting with the multiplatform configuration: enabling one of those platforms sometimes changes the default addresses to the ones used on one of them, rather than the one that was selected in Kconfig. This changes the configuration so we share the physical address configuration with mach-mvebu. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
We may have multiple platforms enabled and also DEBUG_LL configured for one of them. However if we enable ARCH_KEYSTONE, we default to using 32-bit UART access independent of which platform we are actually using, which can be confusing. This changes the logic so the 32-bit default gets only used by default if we actually configure the keystone UART, as opposed to picking some other 8250 setting on a kernel that has keystone support enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Linus Walleij authored
This adds an SMP boot method for the ARM RealView reference designs. We also select HAVE_SMP by default and make it use SMP_ON_UP so we only need to support one single kernel across the RealView reference designs when using DT. The RealViews need to have the SCU (Snoop Control Unit) activated on boot, and this is now done by looking up its address from the device tree and initializing it and counting the available cores. The RealViews boot by using a magic address register in the system controller (SYS_FLAGS) to store the boot address, the ROM will then read this register to the PC when the CPUs are taken out of WFI. This code uses a handle to the syscon regmap to access this register. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
The device tree boot for RealView need the SP810 system controller (same as found on the Versatile Express) to set up the timers on the board so the machine can tick. It further utilize the ICST307 through its system controller for 6 other oscillators. We have to select these from Kconfig or the machine does not boot. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
The SoC driver needs a minor update to display the correct sysfs information for the PB11MPCore. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
This adds support for the ARM syscon ICST clocks to initialized directly from the device tree syscon node on ARM Integrator, Versatile and RealView reference designs. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: linux-clk@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Break out the registration function so it creates a regmap and pass to the setup function, so the latter can be shared with a device tree probe function that already has a regmap. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: linux-clk@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Linus Walleij authored
Instead of passing around register bases, pass around a regmap in this driver. This refactoring make things so much easier when we later want to manage an ICST that is part of a syscon. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: linux-clk@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
The realview barrier implementation tries to avoid calling outer_sync in order to not lock up as a result of a bug in the l220 cache controller. This gets in the way of the multiplatform support, but we can still remove it if we make sure that the outer_sync function never gets called, by replacing the function pointer with NULL, right after initialization. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [Fixed up header inclusions] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
Commit 42c4dafe ("ARM: 6202/1: Do not ARM_DMA_MEM_BUFFERABLE on RealView boards with L210/L220") changed the generic setting for ARM_DMA_MEM_BUFFERABLE to be disabled on any Realview kernel that includes support for any of the ARM11 variations. Doing this was required to allow doing DMA without a lockup in the l2x0 cache controller on the Realview platform. Unfortunately, in a kernel that also contains support for any ARMv7 based machine, the same change makes it impossible to do DMA on ARMv7, which gets in the way of enabling multiplatform support on Realview. As confirmed by Catalin Marinas and Linus Walleij, the current code for Realview that we have in the kernel does not actually perform any DMA, and this is unlikely to change in the future. Therefore we can revert 42c4dafe without introducing regressions, but we must never start using DMA on this platform in the future. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
In order to move realview into multiplatform, we have to prevent device drivers from accessing the machine header files. In case of the clk driver, this is very simple, we just copy the small set of register definitions into the driver that needs them. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
PCI support for realview was never merged, and trying to build realview with CONFIG_PCI enabled fails because the constants for the mapping windows are not defined anywhere. This removes them from the static I/O window mapping table as a preparation for multiplatform support. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
The realview-pbx platform has an elaborate way of avoiding the use of highmem by redefining its phys_to_virt function. In practice this doesn't help all that much, and it gets in the way of doing multiplatform builds for realview. This removes the feature and kills off the mach/memory.h file for realview. We also lose the ability to do sparsemem with this patch, but that should be put back into place for generic multiplatform configurations, to save a little memory on PBX. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 08 Dec, 2015 2 commits
-
-
Russell King authored
Since Dove has non-DT support for various facilities in the PMU, convert the legacy support to use the new PMU driver. Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Russell King authored
Add support for legacy non-DT Dove to the PMU driver, so that we can transition the legacy support over. [gregory.clement@free-electrons.com: removed pm_genpd_poweroff_unused] Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
- 07 Dec, 2015 2 commits
-
-
Arnd Bergmann authored
The orion5x platform is now ready to be enabled for multiplatform support, this patch does the switch over by modifying the Kconfig file, the defconfig and removing the last mach/*.h header that becomes obsolete with this. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Arnd Bergmann authored
This is a simple move of all header files that are no longer included by anything else from the include/mach directory to the platform directory itself as preparation for multiplatform support. The mach/uncompress.h headers are left in place for now, and are mildly modified to be independent of the other headers. They will be removed entirely when ARCH_MULTIPLATFORM gets enabled and they become obsolete. Rather than updating the path names inside of the comments of each header, I delete those comments to avoid having to update them again, should they get moved or copied another time. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-