1. 31 Dec, 2015 3 commits
    • Arnd Bergmann's avatar
      ARM: realview: don't select SMP_ON_UP for UP builds · 2cb58c01
      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: default avatarArnd Bergmann <arnd@arndb.de>
      2cb58c01
    • Arnd Bergmann's avatar
      ARM: s3c: simplify s3c_irqwake_{e,}intallow definition · 26922c59
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      26922c59
    • Arnd Bergmann's avatar
      ARM: s3c64xx: fix pm-debug compilation · b7197612
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      b7197612
  2. 22 Dec, 2015 1 commit
  3. 18 Dec, 2015 9 commits
  4. 17 Dec, 2015 4 commits
    • Arnd Bergmann's avatar
      Merge branch 'fixes' into next/multiplatform · d0b6342d
      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()
        ...
      d0b6342d
    • Arnd Bergmann's avatar
      ARM: make default platform work for NOMMU · 70722803
      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: default avatarArnd Bergmann <arnd@arndb.de>
      70722803
    • Arnd Bergmann's avatar
      ARM: debug-ll: move DEBUG_LL_UART_EFM32 to correct Kconfig location · 06920d4e
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 1dc93416 ("ARM: debug-ll: reorder Kconfig alphanumerically")
      06920d4e
    • Arnd Bergmann's avatar
      ARM: defconfig: use correct debug_ll settings · e45a1e18
      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: default avatarArnd 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")
      e45a1e18
  5. 15 Dec, 2015 23 commits
    • Arnd Bergmann's avatar
      Merge tag 'mvebu-soc-4.5-1' of git://git.infradead.org/linux-mvebu into next/multiplatform · 3081dc9e
      Arnd 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
      3081dc9e
    • Arnd Bergmann's avatar
      Merge tag 'realview-base-armsoc-1-tag' of... · 22ba14f4
      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
      22ba14f4
    • Lijun Pan's avatar
      fsl-ifc: add missing include on ARM64 · c4aa1937
      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: default avatarLijun Pan <Lijun.Pan@freescale.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c4aa1937
    • Arnd Bergmann's avatar
      Merge branch 'versatile/multiplatform' into next/multiplatform · 7379d96b
      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: default avatarMarc Zyngier <marc.zyngier@arm.com>
      7379d96b
    • Rob Herring's avatar
      ARM: versatile: convert to multi-platform · a29da136
      Rob Herring authored
      Now that all the prerequisites are in place, we can enable Versatile
      boards for multi-platform kernels.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a29da136
    • Rob Herring's avatar
      ARM: versatile: merge mach code into a single file · a7096789
      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: default avatarRob Herring <robh@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a7096789
    • Rob Herring's avatar
      ARM: versatile: switch to DT only booting and remove legacy code · 16956fed
      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: default avatarRob 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: default avatarArnd Bergmann <arnd@arndb.de>
      16956fed
    • Rob Herring's avatar
      ARM: versatile: add DT based PCI detection · a8e2894c
      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: default avatarRob Herring <robh@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a8e2894c
    • Arnd Bergmann's avatar
      ARM: pxa: mark ezx structures as __maybe_unused · ee5d8742
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      ee5d8742
    • Arnd Bergmann's avatar
      ARM: pxa: mark raumfeld init functions as __maybe_unused · f41bd6af
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarDaniel Mack <daniel@zonque.org>
      f41bd6af
    • Arnd Bergmann's avatar
      ARM: pxa: cm-x2xx: avoid duplicate macro warnings · f39c42f5
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      f39c42f5
    • Arnd Bergmann's avatar
      Merge branch 'mmp/multiplatform' into next/multiplatform · 8864eaca
      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
      8864eaca
    • Arnd Bergmann's avatar
      Merge branch 's3c64xx/multiplatform' into next/multiplatform · fb4f0424
      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
      fb4f0424
    • Arnd Bergmann's avatar
      Merge branch 'multiplatform/debug-ll' into next/multiplatform · 35d3aad4
      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
      35d3aad4
    • Arnd Bergmann's avatar
      ARM: debug-ll: reorder Kconfig alphanumerically · 1dc93416
      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: default avatarArnd Bergmann <arnd@arndb.de>
      1dc93416
    • Arnd Bergmann's avatar
      ARM: debug-ll: rework footbridge handling · 0045c0dd
      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: default avatarArnd Bergmann <arnd@arndb.de>
      0045c0dd
    • Arnd Bergmann's avatar
      ARM: debug-ll: rework lpc32xx handling · 59bd4c38
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      59bd4c38
    • Arnd Bergmann's avatar
      ARM: debug-ll: rework gemini handling · d7175a3b
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHans Ulli Kroll <ulli.kroll@googlemail.com>
      d7175a3b
    • Arnd Bergmann's avatar
      ARM: debug-ll: rework integrator/versatile handling · 4db22c10
      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: default avatarArnd Bergmann <arnd@arndb.de>
      4db22c10
    • Arnd Bergmann's avatar
      ARM: debug-ll: rework SPEAr handling · 375d84cf
      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: default avatarArnd Bergmann <arnd@arndb.de>
      375d84cf
    • Arnd Bergmann's avatar
      ARM: debug-ll: rework ep93xx handling · f06455fa
      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: default avatarArnd Bergmann <arnd@arndb.de>
      f06455fa
    • Arnd Bergmann's avatar
      ARM: debug-ll: reorganize mvebu debug uart config · c047f529
      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: default avatarArnd Bergmann <arnd@arndb.de>
      c047f529
    • Arnd Bergmann's avatar
      ARM: debug-ll: fix UART configuration with ARCH_KEYSTONE · cdd2e08b
      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: default avatarArnd Bergmann <arnd@arndb.de>
      cdd2e08b