1. 20 11月, 2014 5 次提交
  2. 14 10月, 2014 1 次提交
  3. 04 10月, 2014 1 次提交
  4. 01 10月, 2014 2 次提交
  5. 19 9月, 2014 1 次提交
    • D
      ARM: pxa3xx: provide specific platform_devices for all ssp ports · 0da0e227
      Daniel Mack 提交于
      Currently, devices for SSP ports 1, 2 and 3 are registered as compatible
      devices to pxa27x-ssp. While the actual IP core is comparable, there are
      some subtle differences which users of the SSP ports address by looking at
      the 'type' field.
      
      By registering devices of type 'pxa27x-ssp', this 'type' field is
      incorrectly set to PXA27x_SSP which confuses the users.
      
      To fix this, provide specific ssp port plaform devices which use
      'pxa3xx-ssp' as driver name, an instantiate them from pxa3xx.c.
      Signed-off-by: NDaniel Mack <zonque@gmail.com>
      Signed-off-by: NHaojian Zhuang <haojian.zhuang@linaro.org>
      0da0e227
  6. 09 9月, 2014 1 次提交
  7. 09 8月, 2014 1 次提交
  8. 23 7月, 2014 2 次提交
  9. 18 7月, 2014 1 次提交
    • R
      ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ · 6ebbf2ce
      Russell King 提交于
      ARMv6 and greater introduced a new instruction ("bx") which can be used
      to return from function calls.  Recent CPUs perform better when the
      "bx lr" instruction is used rather than the "mov pc, lr" instruction,
      and this sequence is strongly recommended to be used by the ARM
      architecture manual (section A.4.1.1).
      
      We provide a new macro "ret" with all its variants for the condition
      code which will resolve to the appropriate instruction.
      
      Rather than doing this piecemeal, and miss some instances, change all
      the "mov pc" instances to use the new macro, with the exception of
      the "movs" instruction and the kprobes code.  This allows us to detect
      the "mov pc, lr" case and fix it up - and also gives us the possibility
      of deploying this for other registers depending on the CPU selection.
      Reported-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1
      Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S
      Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood
      Tested-by: NShawn Guo <shawn.guo@freescale.com>
      Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs
      Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385
      Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci
      Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp
      Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen
      Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M
      Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6ebbf2ce
  10. 13 7月, 2014 4 次提交
  11. 11 7月, 2014 1 次提交
  12. 04 7月, 2014 2 次提交
  13. 01 6月, 2014 1 次提交
  14. 21 5月, 2014 2 次提交
  15. 25 4月, 2014 1 次提交
  16. 24 4月, 2014 1 次提交
  17. 22 3月, 2014 6 次提交
    • A
      ARM: pxa: trizeps4 and trizeps4wl use the same file · edd4c720
      Arnd Bergmann 提交于
      The trizeps4 and trizeps4wl platforms are both implemented
      using the same board file. Since the trizeps4wl code is a
      superset of trizeps4, it makes no sense to enable just the
      latter, but with the current Kconfig logic, it causes the
      board file not to be built at all.
      
      Selecting MACH_TRIZEPS4 from MACH_TRIZEPS4WL ensures that
      we are actually building the board file.
      
      Found during randconfig testing.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Daniel Mack <zonque@gmail.com>
      edd4c720
    • A
      ARM: pxa: select I2C_GPIO only if I2C is on · c7dc7d49
      Arnd Bergmann 提交于
      The Arcom/Eurotech VIPER SBC enables the I2C_GPIO driver, but
      that has a dependency on I2C, and causes build failures if I2C
      is disabled. To keep existing configurations running while fixing
      the randconfig problems, this changes the logic to only enable
      I2C_GPIO if I2C is already enabled.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Daniel Mack <zonque@gmail.com>
      c7dc7d49
    • A
      ARM: pxa: remove broken balloon3_gpio_vbus reference · 419606ec
      Arnd Bergmann 提交于
      balloon3_udc_init() tries to register a balloon3_gpio_vbus
      device, but this has never been defined in the mainline
      kernel. To avoid the obvious build failure when this function
      is enabled, remove the bogus reference here.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Daniel Mack <zonque@gmail.com>
      419606ec
    • A
      ARM: pxa: fix colibri build · 847e3496
      Arnd Bergmann 提交于
      The colibri_ohci_init function performs a register access through
      the io_p2v() macro, which requires the IOMEM macro to be defined.
      
      By explicitly including the asm/io.h header file that contains
      this macro, we avoid the build error:
      
      arch/arm/mach-pxa/colibri-evalboard.c: In function 'colibri_ohci_init':
      arch/arm/mach-pxa/colibri-evalboard.c:68:2: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration]
        UP2OCR = UP2OCR_HXS | UP2OCR_HXOE | UP2OCR_DPPDE | UP2OCR_DMPDE;
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Daniel Mack <zonque@gmail.com>
      847e3496
    • A
      ARM: pxa: enable pxafb unconditionally for some boards · e914f19f
      Arnd Bergmann 提交于
      The SAAR and TAVOREVB machines try to call functions from
      the PXAFB frame buffer driver from their platform code,
      which only works if that driver is built-in.
      
      This patch ensures that both the generic frame buffer
      code and the specific pxafb driver are always enabled
      when we build a kernel for one of the two boards.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Daniel Mack <zonque@gmail.com>
      e914f19f
    • A
      ARM: pxa: don't "select" SMC91X on MACH_XCEP · a0ad0fdb
      Arnd Bergmann 提交于
      We normally don't hard-enable Kconfig options just because
      a board contains a specific piece of hardware. In this case,
      selecting SMC91X causes a build error, if we don't also enable
      basic network device driver support.
      
      Since the platform has no direct dependency on this driver
      at link time, we can just remove the 'select' statement.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Daniel Mack <zonque@gmail.com>
      a0ad0fdb
  18. 19 3月, 2014 1 次提交
  19. 04 3月, 2014 1 次提交
  20. 11 2月, 2014 3 次提交
  21. 10 2月, 2014 1 次提交
    • S
      pwm: Remove obsolete HAVE_PWM Kconfig symbol · 557fe99d
      Sascha Hauer 提交于
      Before we had the PWM framework we used to have a barebone PWM api. The
      HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
      the PWM API is present in the kernel. Since the last legacy driver is gone
      the HAVE_PWM symbol can go aswell.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: linux-pwm@vger.kernel.orig
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
      557fe99d
  22. 29 12月, 2013 1 次提交
    • L
      ARM: pxa: fix USB gadget driver compilation regression · 9928422f
      Linus Walleij 提交于
      After commit 88f718e3
      "ARM: pxa: delete the custom GPIO header" a compilation
      error was introduced in the PXA25x gadget driver.
      An attempt to fix the problem was made in
      commit b144e4ab
      "usb: gadget: fix pxa25x compilation problems"
      by explictly stating the driver needs the <mach/hardware.h>
      header, which solved the compilation for a few boards,
      such as the pxa255-idp and its defconfig.
      
      However the Lubbock board has this special clause in
      drivers/usb/gadget/pxa25x_udc.c:
      
      This include file has an implicit dependency on
      <mach/irqs.h> having been included before <mach/lubbock.h>
      was included.
      
      Before commit 88f718e3
      "ARM: pxa: delete the custom GPIO header" this implicit
      dependency for the pxa25x_udc compile on the Lubbock was
      satisfied by <linux/gpio.h> implicitly including
      <mach/gpio.h> which was in turn including <mach/irqs.h>,
      apart from the earlier added <mach/hardware.h>.
      
      Fix this by having the PXA25x <mach/lubbock.h> explicitly
      include <mach/irqs.h>.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Greg Kroah-Hartmann <gregkh@linuxfoundation.org>
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      9928422f