aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2015-12-17ARM: debug-ll: move DEBUG_LL_UART_EFM32 to correct Kconfig locationArnd Bergmann1-14/+14
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: 1dc9341 ("ARM: debug-ll: reorder Kconfig alphanumerically")
2015-12-17ARM: defconfig: use correct debug_ll settingsArnd Bergmann5-5/+0
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: 4db22c1 ("ARM: debug-ll: rework integrator/versatile handling") Fixes: f06455f ("ARM: debug-ll: rework ep93xx handling") Fixes: c047f52 ("ARM: debug-ll: reorganize mvebu debug uart config") Fixes: 59bd4c3 ("ARM: debug-ll: rework lpc32xx handling")
2015-12-16fsl-ifc: add missing include on ARM64Lijun Pan1-0/+1
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>
2015-12-15ARM: versatile: convert to multi-platformRob Herring5-70/+19
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>
2015-12-15ARM: versatile: merge mach code into a single fileRob Herring6-648/+325
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>
2015-12-15ARM: versatile: switch to DT only booting and remove legacy codeRob Herring14-1372/+24
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>
2015-12-15ARM: versatile: add DT based PCI detectionRob Herring1-0/+50
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>
2015-12-15ARM: pxa: mark ezx structures as __maybe_unusedArnd Bergmann1-5/+5
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>
2015-12-15ARM: pxa: mark raumfeld init functions as __maybe_unusedArnd Bergmann1-3/+3
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>
2015-12-15ARM: pxa: cm-x2xx: avoid duplicate macro warningsArnd Bergmann1-0/+9
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>
2015-12-15ARM: debug-ll: reorder Kconfig alphanumericallyArnd Bergmann1-141/+141
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>
2015-12-15ARM: debug-ll: rework footbridge handlingArnd Bergmann2-5/+7
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>
2015-12-15ARM: debug-ll: rework lpc32xx handlingArnd Bergmann1-3/+11
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>
2015-12-15ARM: debug-ll: rework gemini handlingArnd Bergmann1-5/+13
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>
2015-12-15ARM: debug-ll: rework integrator/versatile handlingArnd Bergmann1-4/+20
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>
2015-12-15ARM: debug-ll: rework SPEAr handlingArnd Bergmann1-4/+19
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>
2015-12-15ARM: debug-ll: rework ep93xx handlingArnd Bergmann1-2/+10
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>
2015-12-15ARM: debug-ll: reorganize mvebu debug uart configArnd Bergmann1-13/+19
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>
2015-12-15ARM: debug-ll: fix UART configuration with ARCH_KEYSTONEArnd Bergmann1-2/+3
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>
2015-12-15ARM: realview: add an DT SMP boot methodLinus Walleij4-1/+95
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>
2015-12-15ARM: realview: select SP810 and ICST for the DT variantLinus Walleij1-0/+2
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>
2015-12-15soc: versatile: add support for the PB11MPCoreLinus Walleij1-0/+4
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>
2015-12-15clk: versatile-icst: add device tree supportLinus Walleij1-1/+88
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>
2015-12-15clk: versatile-icst: refactor to allocate regmap separatelyLinus Walleij1-19/+28
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>
2015-12-15clk: versatile-icst: convert to use regmapLinus Walleij2-28/+61
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>
2015-12-15ARM: realview: remove private barrier implementationArnd Bergmann4-10/+13
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>
2015-12-15ARM: no longer force unbuffered DMA for realviewArnd Bergmann1-2/+0
Commit 42c4dafe803dca ("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 42c4dafe803dca 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>
2015-12-15clk/realview: stop using machine headersArnd Bergmann1-3/+7
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>
2015-12-15ARM: realview: don't map undefined PCI registersArnd Bergmann2-16/+0
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>
2015-12-15ARM: realview: remove sparsemem hackArnd Bergmann3-69/+2
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>
2015-12-11ls2080a/dts: Add little endian property for GPIO IP blockLiu Gang1-0/+4
The GPIO block for ls2080a platform has little endian registers, the GPIO driver needs this property to read/write registers by right interface. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kevin Hilman <khilman@linaro.org>
2015-12-11dt-bindings: define little-endian property for QorIQ GPIOLi Yang1-0/+4
The GPIO block on different QorIQ chips could have registers in different endianess. Define the property to specify which endian is used by the hardware. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kevin Hilman <khilman@linaro.org>
2015-12-11ARM64: dts: ls2080a: fix eSDHC endiannessyangbo lu1-0/+1
Add the "little-endian" property to fix the issue that eSDHC is not working and dumping out "mmc0: Controller never released inhibit bit(s)." error messages constantly. Fixes: 5461597f6ce0 ("dts/ls2080a: Update DTSI to add support of various peripherals") Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kevin Hilman <khilman@linaro.org>
2015-12-11ARM: dts: vf610: use reset values for L2 cache latenciesStefan Agner2-6/+1
Linux on Vybrid used several different L2 latencies so far, none of them seem to be the right ones. According to the application note AN4947 ("Understanding Vybrid Architecture"), the tag portion runs on CPU clock and is inside the L2 cache controller, whereas the data portion is stored in the external SRAM running on platform clock. Hence it is likely that the correct value requires a higher data latency then tag latency. These are the values which have been used so far: - The mainline values: arm,data-latency = <1 1 1>; arm,tag-latency = <2 2 2>; Those values have lead to problems on higher clocks. They look like a poor translation from the reset values (missing +1 offset and a mix up between tag/latency values). - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation): arm,data-latency = <4 2 3> arm,tag-latency = <4 2 3> The cache initialization function along with the value matches the i.MX6 code from the same kernel, so it seems that those values have just been copied. - The Colibri values: arm,data-latency = <2 1 2>; arm,tag-latency = <3 2 3>; Those were a mix between the values of the Linux 3.0 based BSP and the mainline values above. - The SoC Reset values (converted to DT notation): arm,data-latency = <3 3 3>; arm,tag-latency = <2 2 2>; So far there is no official statement on what the correct values are. See also the related Freescale community thread: https://community.freescale.com/message/579785#579785 For now, the reset values seem to be the best bet. Remove all other "bogus" values and use the reset value on vf610.dtsi level. Signed-off-by: Stefan Agner <stefan@agner.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2015-12-11ARM: pxa: use PWM lookup table for all machinesArnd Bergmann1-0/+5
The recent change to use a pwm lookup table for the ezx machines was incomplete and only changed the a780 model, but not the other ones in the same file. This adds the missing calls to pwm_add_table(). Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: c3322022897c ("ARM: pxa: ezx: Use PWM lookup table") Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
2015-12-10ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1Jisheng Zhang1-2/+4
We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag, so the sdhci0 and sdhci1 don't work. We fix this by adding the optional 2nd clock for BG2Q's sdhci0 and sdhci1. This patch brings another benefit: the 2nd clock can be disabled during runtime pm, so saves power a bit. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
2015-12-10ARM: dts: berlin: correct BG2Q's sdhci2 2nd clockJisheng Zhang1-1/+1
The optional 2nd clock is CLKID_SDIO. We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag, so the sdhci2 doesn't work. This patch fixes this issue by correcting the sdhci2's 2nd clock. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
2015-12-09ARM: dts: am4372: fix clock source for arm twd and global timersGrygorii Strashko2-2/+10
ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2. But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result. Timekeeping core misbehaves. For example, execution of command "sleep 5" will take 10 sec instead of 5. Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use it for clocking ARM TWD and Global timer (same way as on OMAP4). Cc: Tony Lindgren <tony@atomide.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU nodes") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-12-08ARM: dove: convert legacy dove to PMU supportRussell King4-102/+33
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>
2015-12-08soc: dove: add legacy support to PMU driverRussell King3-0/+63
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>
2015-12-07ARM: orion5x: multiplatform supportArnd Bergmann5-67/+19
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>
2015-12-07ARM: orion5x: clean up mach/*.h headersArnd Bergmann31-55/+33
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>
2015-12-07ARM: mv78xx0: multiplatform supportArnd Bergmann5-62/+16
The mv78xx0 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>
2015-12-07ARM: mv78xx0: clean up mach/*.h headersArnd Bergmann12-32/+10
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>
2015-12-07ARM: orion: use SPARSE_IRQ everywhereArnd Bergmann31-5/+37
As a preparation for multiplatform support, this moves all the code using plat-orion over to use sparse irq support, which is enabled implicitly for multiplatform. In particular, the hardcoded NR_IRQS macro gets replaced with a machine specific one that is set in the machine descriptor in order to set up a static mapping for all legacy interrupts. 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>
2015-12-07ARM: orion: always use MULTI_IRQ_HANDLERArnd Bergmann9-123/+37
As a preparation for multiplatform support, this enables the MULTI_IRQ_HANDLER code unconditionally on dove and orion5x, and introduces the respective code on mv78xx0, which did not have it so far. The classic entry-macro.S files are removed as they are now obsolete. 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>
2015-12-07ARM: orion: move watchdog setup to mach-orion5xArnd Bergmann4-24/+30
The watchdog device node is created in plat-orion/common.c but depends on the bridge address that is platform specific, so as a preparation for orion multiplatform support, we move it out of the common code into orion5x and dove. At the moment, dove does not use the watchdog, so I'm marking the function as __maybe_unused for the moment. The compiler will be able to compile out the device definition this way, and we can easily add it later. 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>
2015-12-04ARM: at91: fix pinctrl driver selectionLudovic Desroches2-2/+11
Move the selection of the pinctrl driver to SoC family level since we have two pinctrl drivers. It is useless to select one which is not compatible with the SoC. [abelloni: fixed pm.c when only sama2d2 is selected] Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-12-04ARM: at91/dt: add always-on to 1.8V regulatorNicolas Ferre1-0/+1
As the SDHCI controller needs the 1.8V line to be always enabled for some eMMC configurations, set the proper "regulator-always-on" property to the board DTS files. Note that the sdhci classical regulator definitions doesn't suit our controller for this 1.8V purpose. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-12-02ARM: dts: vf610: fix clock definition for SAI2Stefan Agner1-2/+4
So far, only the bus clock has been assigned, but in reality the SAI IP has for clock inputs. The driver has been updated to make use of the additional clock inputs by c3ecef21c3f2 ("ASoC: fsl_sai: add sai master mode support"). Due to a bug in the clock tree, the audio clock has been enabled none the less by the specified bus clock (see "ARM: imx: clk-vf610: fix SAI clock tree"), which made master mode even without the proper clock assigned working. This patch completes the clock definition for SAI2. On Vybrid, only two MCLK out of the four options are available (the first being the bus clock itself). See chapter 8.10.1.2.3 of the Vybrid Reference manual ("SAI transmitter and receiver options for MCLK selection"). Note: The audio clocks are only required in master mode. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>