- 22 Jan, 2016 2 commits
-
-
Olof Johansson authored
Merge tag 'renesas-fixes-for-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Renesas ARM Based SoC Fixes for v4.5 Correct extal1 frequency of armadillo800eva board * tag 'renesas-fixes-for-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: dts: armadillo800eva Correct extal1 frequency to 24 MHz Signed-off-by: Olof Johansson <olof@lixom.net>
-
Arnd Bergmann authored
gcc warns about the 'found' variable possibly being used uninitialized: drivers/soc/qcom/spm.c: In function 'spm_dev_probe': drivers/soc/qcom/spm.c:305:5: error: 'found' may be used uninitialized in this function [-Werror=maybe-uninitialized] However, the code is correct because we know that there is always at least one online CPU. This initializes the 'found' variable to zero before the loop so the compiler knows it does not have to warn about it. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
- 21 Jan, 2016 1 commit
-
-
Linus Walleij authored
As it happens, two obj-$(CONFIG_FOO) += foo.o variables are above obj-y := core.o, which doesn't work: the += directives need to add something to the build and doesn't work if obj-y is not set first, so move the obj-y to be on top and everything builds nicely again. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
- 18 Jan, 2016 2 commits
-
-
Arnd Bergmann authored
During my randconfig build testing, I found that a kernel with DEBUG_AT91_UART and ARCH_BCM_63XX fails to build: arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror] It turns out that the DEBUG_UART_BCM63XX option is enabled whenever the ARCH_BCM_63XX is, and that breaks multiplatform kernels because we then end up using the UART address from BCM63XX rather than the one we actually configured (if any). This changes the BCM63XX options to only have one Kconfig option, and only enable that if the user explicitly turns it on. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b51312be ("ARM: BCM63XX: add low-level UART debug support") Cc: stable@vger.kernel.org
-
Geert Uytterhoeven authored
On r8a7740/armadillo, actual clock rates are ca. 4% lower than reported by /sys/kernel/debug/clk/clk_summary. Correct the extal1 frequency from 25 MHz to 24 MHz to fix this. This matches the Armadillo-800 EVA Product Manual, which claims the main crystal runs at 24 MHz, and the old legacy/reference board code. Fixes: 25aa7ba3 ("ARM: shmobile: armadillo800eva: Sync DTS") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
-
- 31 Dec, 2015 3 commits
-
-
Arnd Bergmann authored
When CONFIG_SMP is disabled, we get a warning from Kconfig: warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL && MMU) This changes the REALVIEW_DT Kconfig entry to not select SMP_ON_UP unless SMP is also set. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
For a long time, gcc has warned about odd configurations on s3c64xx: In file included from arch/arm/plat-samsung/pm.c:34:0: arch/arm/mach-s3c64xx/include/mach/pm-core.h:61:0: warning: "s3c_irqwake_eintallow" redefined #define s3c_irqwake_eintallow ((1 << 28) - 1) In file included from arch/arm/plat-samsung/pm.c:33:0: arch/arm/plat-samsung/include/plat/pm.h:49:0: note: this is the location of the previous definition #define s3c_irqwake_eintallow 0 The definitions of s3c_irqwake_intallow and s3c_irqwake_eintallow are a bit consistent between the various platforms. Things have become easier now that it's only s3c24xx and s3c64xx that use them at all, so I've tried to rearrange the definitions to make it more obvious what is going on. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
-
Arnd Bergmann authored
I got one randconfig build that failed to compile plat-samsung/pm-debug.c on s3c64xx: In file included from arch/arm/plat-samsung/pm-debug.c:27:0: arch/arm/mach-s3c64xx/include/mach/pm-core.h: In function 's3c_pm_debug_init_uart': arch/arm/mach-s3c64xx/include/mach/pm-core.h:25:25: error: 'S3C_VA_SYS' undeclared (first use in this function) u32 tmp = __raw_readl(S3C_PCLK_GATE); arch/arm/mach-s3c64xx/include/mach/pm-core.h:25:25: note: each undeclared identifier is reported only once for each function it appears in arch/arm/mach-s3c64xx/include/mach/pm-core.h:39:2: error: implicit declaration of function 'udelay' [-Werror=implicit-function-declaration] udelay(10); I have not investigated why this does not show up much more often, I guess the headers are usually included from elsewhere, but adding explicit #include statements is an obvious fix. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
-
- 22 Dec, 2015 1 commit
-
-
Valentin Rothberg authored
Since commit 1c6c6952 ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. So pass the IRQF_ONESHOT flag in this case. Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
- 18 Dec, 2015 9 commits
-
-
Arnd Bergmann authored
The realview multiplatform series has a trivial conflict with one of the treewide cleanups, let's just merge that in to avoid having to resolve this later. * treewide/cleanup: ARM: use "depends on" for SoC configs instead of "if" after prompt ARM/clocksource: use automatic DT probing for ux500 PRCMU ARM: use const and __initconst for smp_operations ARM: hisi: do not export smp_operations structures Conflicts: arch/arm/mach-integrator/Kconfig
-
Arnd Bergmann authored
The platsmp-dt.c file does not build when CONFIG_SMP is disabled: platsmp-dt.c:84:2: error: unknown field 'smp_prepare_cpus' specified in initializer This changes the Makefile to build it conditionally on CONFIG_SMP. The legacy platsmp.c file is only used for ATAGS based builds, so we can move it into the CONFIG_ATAGS conditional. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Merge tag 'realview-multiplatform-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into next/multiplatform Pull "Multiplatform support for the RealView" from Linus Walleij: Here is the result of my application of the second part of Arnds patchset, actually enabling multiplatform and getting the RealView off the ground as a multiplatform target. It is dependent on an outstanding patch to the irqchips tree bumping the number of GICs to 2 for the RealView platform. I cannot say I will be sleepless if these go in side by side: each branch will compile but will not boot until both trees have been pulled hurting bisectability a bit. - Tested on the ARM PB11MPCore - Tested with boardfile boot - Tested with DeviceTree boot * tag 'realview-multiplatform-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator: ARM: realview: select apropriate targets ARM: realview: clean up header files ARM: realview: make all header files local ARM: no longer make CPU targets visible separately ARM: integrator: use explicit core module options ARM: realview: enable multiplatform
-
Linus Walleij authored
Now that we have multiplatform support, let the RealView defconfigs select all the RealView boards so we boot out of the box like before. This updates both defconfigs. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
This contains multiple trivial cleanups to the realview headers: - removing the file names from the introductory comment - removing the uncompress.h header that is unused - removing the irqs.h header and NR_IRQS logic that is obsoleted by sparse IRQs Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
Nothing includes these files any more, so we can simply move them from arch/arm/mach-realview/include/mach/ to arch/arm/mach-realview. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [Two fixes added to make everything compile] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
Now that realview and integrator always select the correct CPU type themselves based on the core tiles, there is no need to still have them user-visible in arch/arm/mm/Kconfig. The ARM925T symbol has been selected by the only user for many years, so that can be removed along with the realview and integrator specific ones. This also solves randconfig build problems on realview. 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
For consistency with the other platforms, this remove the CPU selection logic in mm/Kconfig that was only used by integrator, and adds specific options for each available core tile and core module, which in turn select the correct CPUs. This is consistent with the new way that we do it for realview and all other platforms. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
Arnd Bergmann authored
All obstacles are out of the way by now, so we can finally move realview to multiplatform. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk> [Rebased Kconfig, fixed if $(X) to if X in Makefile] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
-
- 17 Dec, 2015 4 commits
-
-
Arnd Bergmann authored
The 'fixes' branch contains d5d4fdd8 ("irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB") that is required for booting the versatile platform prior to the rework in this branch, but including both causes a build-time error. I'm doing an evil merge here to pull in the fixes branch so we have that commit included but at the same time revert the trivial change. This gives us a bisectable history. * fixes: (22 commits) fsl-ifc: add missing include on ARM64 ls2080a/dts: Add little endian property for GPIO IP block dt-bindings: define little-endian property for QorIQ GPIO ARM64: dts: ls2080a: fix eSDHC endianness ARM: dts: vf610: use reset values for L2 cache latencies ARM: pxa: use PWM lookup table for all machines ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1 ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock ARM: dts: am4372: fix clock source for arm twd and global timers ARM: at91: fix pinctrl driver selection ARM: at91/dt: add always-on to 1.8V regulator ARM: dts: vf610: fix clock definition for SAI2 ARM: imx: clk-vf610: fix SAI clock tree ARM: ixp4xx: fix read{b,w,l} return types irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB ARM: OMAP2+: enable REGULATOR_FIXED_VOLTAGE ARM: dts: add dm816x missing spi DT dma handles ARM: dts: add dm816x missing #mbox-cells cpufreq: s3c24xx: Do not mark s3c2410_plls_add as __init bus: sunxi-rsb: unlock on error in sunxi_rsb_read() ...
-
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 18 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
-
Lijun Pan authored
Need to include sched.h to fix the following compilation error if FSL_IFC is enabled on ARM64 machine. In file included from include/linux/mmzone.h:9:0, from include/linux/gfp.h:5, from include/linux/kmod.h:22, from include/linux/module.h:13, from drivers/memory/fsl_ifc.c:22: drivers/memory/fsl_ifc.c: In function ‘check_nand_stat’: include/linux/wait.h:165:35: error: ‘TASK_NORMAL’ undeclared (first use in this function) #define wake_up(x) __wake_up(x, TASK_NORMAL, 1, NULL) ^ drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’ wake_up(&ctrl->nand_wait); ^ include/linux/wait.h:165:35: note: each undeclared identifier is reported only once for each function it appears in #define wake_up(x) __wake_up(x, TASK_NORMAL, 1, NULL) ^ drivers/memory/fsl_ifc.c:136:3: note: in expansion of macro ‘wake_up’ wake_up(&ctrl->nand_wait); ^ Analysis is as follows: I put some instrumental code and get the following .h files inclusion sequence: In file included from ./arch/arm64/include/asm/compat.h:25:0, from ./arch/arm64/include/asm/stat.h:23, from include/linux/stat.h:5, from include/linux/module.h:10, from drivers/memory/fsl_ifc.c:23: include/linux/sched.h:113:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘struct’ struct sched_attr { ^ CONFIG_COMPAT=y is enabled while 39 and 48 bit VA is selected. When 42 bit VA is selected, it does not enable CONFIG_COMPAT=y In ./arch/arm64/include/asm/stat.h:23, it has "#ifdef CONFIG_COMPAT" "#include <asm/compat.h>" "..." "#endif" Since ./arch/arm64/include/asm/stat.h does not include ./arch/arm64/include/asm/compat.h, then it will not include include/linux/sched.h Hence we have to manually add "#include <linux/sched.h>" in drivers/memory/fsl_ifc.c Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
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>
-