1. 15 Dec, 2015 15 commits
    • 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
  2. 01 Dec, 2015 25 commits
    • Arnd Bergmann's avatar
      ARM: netx: remove unused mach/param.h · d74b5181
      Arnd Bergmann authored
      I could not find any users of this file, past or present, and
      it contains only a comment, so let's remove it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d74b5181
    • Arnd Bergmann's avatar
      ARM: w90x900: make headers more local · 1d8f3c49
      Arnd Bergmann authored
      Some header files are never included outside of a mach-w90x900
      directory and do not need to be made visible in include/mach,
      so let's just move them all down one level.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      1d8f3c49
    • Arnd Bergmann's avatar
      ARM: iop13xx: make headers more local · c11fc349
      Arnd Bergmann authored
      Some header files are never included outside of a mach-iop13xx
      directory and do not need to be made visible in include/mach,
      so let's just move them all down one level.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c11fc349
    • Arnd Bergmann's avatar
      ARM: davinci: make headers more local · 3acf731c
      Arnd Bergmann authored
      Some header files are never included outside of a mach-davinci
      directory and do not need to be made visible in include/mach,
      so let's just move them all down one level.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSekhar Nori <nsekhar@ti.com>
      3acf731c
    • Arnd Bergmann's avatar
      ARM: ks8695: make headers more local · d8b2823e
      Arnd Bergmann authored
      Some header files are never included outside of a mach-ks8695
      directory and do not need to be made visible in include/mach,
      so let's just move them all down one level.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      d8b2823e
    • Arnd Bergmann's avatar
      ARM: omap1: make headers more local · 100f9638
      Arnd Bergmann authored
      Some header files are never included outside of a mach-omap1
      directory and do not need to be made visible in include/mach,
      so let's just move them all down one level.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      100f9638
    • Arnd Bergmann's avatar
      ARM: pxa: make more mach/*.h files local · 4c25c5d2
      Arnd Bergmann authored
      Lots of header files are never included outside of a mach-pxa
      directory and do not need to be made visible in include/mach,
      so let's just move them all down one level.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      4c25c5d2
    • Arnd Bergmann's avatar
      ARM: s3c64xx: allow building without board support · b2821042
      Arnd Bergmann authored
      Most of the code for the s3c64xx platform is only used when booting
      with ATAGS based board files, but not when using device-tree.
      
      This tries to identify all the s3c64xx specific code that is
      unneeded when CONFIG_ATAGS is not set, so we can build a smaller
      DT-only kernel if configured that way.
      
      All board support is still left intact but now depends on the
      CONFIG_ATAGS symbol that users may intentionally disable.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      b2821042
    • Arnd Bergmann's avatar
      ARM: s3c64xx: multiplatform support · af37eec0
      Arnd Bergmann authored
      After all preparation work is done, we can finally move the Kconfig
      option for s3c64xx into ARCH_MULTIPLATFORM. This implies allowing
      SAMSUNG_ATAGS for multiplatform again, but now disallowing the
      ADC driver below it, as that still has dependencies on header files.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      af37eec0
    • Arnd Bergmann's avatar
      ARM: s3c64xx: use common debug-ll implementation · bb08dea1
      Arnd Bergmann authored
      The uart on s3c64xx is essentially the same as on s3c24xx,
      so we can share a single assembler file. However, the addresses
      are different, and we need to add the respective Kconfig magic
      to get the right addresses.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      bb08dea1
    • Arnd Bergmann's avatar
      ARM: s3c64xx: use new adc/touchscreen driver · a829ae57
      Arnd Bergmann authored
      The old ADC and touchscreen drivers are not compatible with
      multiplatform support, but we can use the exynos-adc driver
      as a replacement.
      
      This changes the common device creation functions for s3c64xx
      (but not s3c24xx for now) to use the new driver. To do this,
      we have to pass the interrupt resources in the opposite order
      and pass the platform data in the adc device node.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      a829ae57
    • Arnd Bergmann's avatar
      iio: exynos-adc: add experimental touchscreen support · 2bb8ad9b
      Arnd Bergmann authored
      This adds support for the touchscreen on Samsung s3c64xx.
      The driver is completely untested but shows roughly how
      it could be done, following the example of the at91 driver.
      
      compared to the old plat-samsung/adc driver, there is
      no support for prioritizing ts over other clients, nor
      for oversampling. From my reading of the code, the
      priorities didn't actually have any effect at all, but
      the oversampling might be needed.
      
      Verifying this driver is the main issue that is currently
      holding up multiplatform support for s3c64xx, so any help
      in testing is very much appreciated.
      
      The current version uses the IS_REACHABLE() that is
      going to be introduced in the linux-media tree, please
      comment this out for testing.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      2bb8ad9b
    • Arnd Bergmann's avatar
      ARM: s3c64xx: enable sparse IRQ support · ba279044
      Arnd Bergmann authored
      This is another prerequisite for enabling multiplatform
      support, and it is the part I am least certain about.
      
      I assume it will cause the extra boot message "Cannot
      allocate irq_descs @ IRQ%d, assuming pre-allocated" to
      be printed, but otherwise work ok. This definitely needs
      to be tested on real hardware to see if it works.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      ba279044
    • Arnd Bergmann's avatar
      ARM: s3c64xx: prepare initcalls for multiplatform · a0e157af
      Arnd Bergmann authored
      In a multiplatform kernel, each initcall is run regardless
      of the platform it is meant for, so it must not attempt to
      access SoC-specific registers.
      
      This adds 'if (soc_is_s3c64xx)' to all initcalls that are
      specific to the s3c64xx platform, to prevent them from breaking
      other platforms once we can build them into a combined kernel.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      a0e157af
    • Arnd Bergmann's avatar
      gpio: samsung: move gpio-samsung driver back to platform code · 0f20e456
      Arnd Bergmann authored
      The gpio-samsung driver is special in the sense that it
      interacts directly in multiple ways with the legacy platform
      code for the s3c24xx and s3c64xx platforms. In contrast,
      all devicetree based machines for Samsung, including the
      ones on those two SoC families use a different driver.
      
      The header files that define the interface between the platform
      code and the gpio driver are not visible when building a
      kernel for ARCH_MULTIPLATFORM, which prevents us from
      turning on this option for s3c64xx.
      
      To work around this, we now move the driver back into platform
      code, from where it was originally moved to as part of commit
      1b39d5f2 ("gpio/samsung: gpio-samsung.c to support
      Samsung GPIOs").
      
      The long-term plan for this driver would be to remove it
      entirely, after all Samsung machines have been converted
      over to boot from DT, but there is currently no timeline
      for when that might happen.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      0f20e456
    • Arnd Bergmann's avatar
      ASoC: samsung/smartq: use dynamic registration · df0cc2d1
      Arnd Bergmann authored
      As a prerequisite for moving s3c64xx into multiplatform configurations,
      we need to change the smartq audio driver to stop using hardcoded
      gpio numbers from the header file, and instead pass the gpio data
      through platform_data.
      
      In order to do that, we also move the code to use module_platform_driver
      and register the platform device using platform_device_register_simple
      and register the gpios through the gpiod API.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      df0cc2d1
    • Arnd Bergmann's avatar
      Input: s3c2410_ts: fix S3C_ADC dependency · 94eb81ad
      Arnd Bergmann authored
      S3C_ADC is only available on machines that don't do ARCH_MULTIPLATFORM,
      so changing the 'select' into 'depends on' here helps us move to
      ARCH_MULTIPLATFORM without introducing regressions.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      94eb81ad
    • Arnd Bergmann's avatar
      ARM: mmp: avoid unused functions · 84f45ee9
      Arnd Bergmann authored
      mach-mmp/devices.c:81:21: warning: 'u2o_get' defined but not used [-Wunused-function]
       static unsigned int u2o_get(void __iomem *base, unsigned int offset)
                           ^
      mach-mmp/devices.c:86:13: warning: 'u2o_set' defined but not used [-Wunused-function]
       static void u2o_set(void __iomem *base, unsigned int offset,
                   ^
      mach-mmp/devices.c:97:13: warning: 'u2o_clear' defined but not used [-Wunused-function]
       static void u2o_clear(void __iomem *base, unsigned int offset,
                   ^
      mach-mmp/devices.c:108:13: warning: 'u2o_write' defined but not used [-Wunused-function]
       static void u2o_write(void __iomem *base, unsigned int offset,
                   ^
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      84f45ee9
    • Arnd Bergmann's avatar
      ARM: mmp: move into ARCH_MULTIPLATFORM · 377524dc
      Arnd Bergmann authored
      With all dependencies taken care of, this enables building
      the Marvell mmp platform as part of ARCH_MULTIPLATFORM, along
      with other ARMv5 and ARMv7 platforms.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarAndrew Lunn <andrew@lunn.ch>
      377524dc
    • Arnd Bergmann's avatar
      ARM: mmp: make all header files local · b501fd7b
      Arnd Bergmann authored
      The mach/*.h headers are now inaccessible to any external code,
      so we can move them all into the mach-mmp directory itself
      and remove the subdirectories.
      
      A few headers are not used at all, so we remove them here.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      b501fd7b
    • Arnd Bergmann's avatar
      ARM: mmp: make plat-pxa build standalone · 8bf42cc8
      Arnd Bergmann authored
      The ssp.c driver in plat-pxa is the only remaining file including a
      mach/*.h header from mmp. It actually doesn't need mach/hardware.h at
      all, so we can remove the #include.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      8bf42cc8
    • Arnd Bergmann's avatar
      ARM: mmp: remove remaining legacy pxa-dma support · 74911e3a
      Arnd Bergmann authored
      All drivers have stopped using this code, so we can just
      as well stop initializing it.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      74911e3a
    • Arnd Bergmann's avatar
      ARM: mohawk: allow building with MMU disabled · 0f67b876
      Arnd Bergmann authored
      It is in principle possible to build an MMP kernel for
      the mohawk CPU with the MMU code disabled, except for one
      simple build error:
      
      proc-mohawk.S:345: Error: invalid operands (*UND* and *UND* sections) for `|'
      proc-mohawk.S:345: Error: invalid operands (*ABS* and *UND* sections) for `|'
      proc-mohawk.S:345: Error: invalid operands (*UND* and *UND* sections) for `|'
      proc-mohawk.S:345: Error: invalid operands (*UND* and *UND* sections) for `|'
      proc-mohawk.S:345: Error: undefined symbol L_PTE_USER used as an immediate value
      
      This patch changes the proc-mohawk code to do the same as the
      other CPUs and not try to actually do anything for the
      cpu_mohawk_set_pte_ext function, which won't be used anyway.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      0f67b876
    • Arnd Bergmann's avatar
      ARM: make xscale iwmmxt code multiplatform aware · d33c43ac
      Arnd Bergmann authored
      In a multiplatform configuration, we may end up building a kernel for
      both Marvell PJ1 and an ARMv4 CPU implementation. In that case, the
      xscale-cp0 code is built with gcc -march=armv4{,t}, which results in a
      build error from the coprocessor instructions.
      
      Since we know this code will only have to run on an actual xscale
      processor, we can simply build the entire file for ARMv5TE.
      
      Related to this, we need to handle the iWMMXT initialization sequence
      differently during boot, to ensure we don't try to touch xscale
      specific registers on other CPUs from the xscale_cp0_init initcall.
      cpu_is_xscale() used to be hardcoded to '1' in any configuration that
      enables any XScale-compatible core, but this breaks once we can have a
      combined kernel with MMP1 and something else.
      
      In this patch, I replace the existing cpu_is_xscale() macro with a new
      cpu_is_xscale_family() macro that evaluates true for xscale, xsc3 and
      mohawk, which makes the behavior more deterministic.
      
      The two existing users of cpu_is_xscale() are modified accordingly,
      but slightly change behavior for kernels that enable CPU_MOHAWK without
      also enabling CPU_XSCALE or CPU_XSC3. Previously, these would leave leave
      PMD_BIT4 in the page tables untouched, now they clear it as we've always
      done for kernels that enable both MOHAWK and the support for the older
      CPU types.
      
      Since the previous behavior was inconsistent, I assume it was
      unintentional.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d33c43ac
    • Arnd Bergmann's avatar
      clk: mmp: stop using platform headers · 990f2f22
      Arnd Bergmann authored
      The mmp clock drivers currently hardcode the physical addresses for
      the clock registers. This is generally a bad idea, and it also gets in
      the way of multiplatform builds, which make the platform header files
      inaccessible to device drivers.
      
      To work around the header file problem, this patch changes the calling
      convention so the three mmp clock drivers get initialized with the base
      addresses as arguments from the platform code.
      
      It would still be useful to have a larger rework of the clock drivers,
      with DT integration to let the clocks actually be probed automatically,
      and the base addresses passed as DT properties. I am unsure if anyone
      is still interested in the mmp platform, so it is possible that this
      won't happen.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Mike Turquette <mturquette@linaro.org>
      Cc: Chao Xie <chao.xie@marvell.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      990f2f22