1. 11 11月, 2011 2 次提交
  2. 05 11月, 2011 2 次提交
  3. 04 11月, 2011 1 次提交
  4. 23 10月, 2011 1 次提交
    • M
      ARM: gic: consolidate PPI handling · 292b293c
      Marc Zyngier 提交于
      PPI handling is a bit of an odd beast. It uses its own low level
      handling code and is hardwired to the local timers (hence lacking
      a registration interface).
      
      Instead, switch the low handling to the normal SPI handling code.
      PPIs are handled by the handle_percpu_devid_irq flow.
      
      This also allows the removal of some duplicated code.
      
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NDavid Brown <davidb@codeaurora.org>
      Tested-by: NDavid Brown <davidb@codeaurora.org>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      292b293c
  5. 22 10月, 2011 2 次提交
    • M
      ARM: mach-shmobile: sh7372 A4R support (v4) · 382414b9
      Magnus Damm 提交于
      This change adds support for the sh7372 A4R power domain.
      
      The sh7372 A4R hardware power domain contains the
      SH CPU Core and a set of I/O devices including
      multimedia accelerators and I2C controllers.
      
      One special case about A4R is the INTCS interrupt
      controller that needs to be saved and restored to
      keep working as expected. Also the LCDC hardware
      blocks are in a different hardware power domain
      but have their IRQs routed only through INTCS. So
      as long as LCDCs are active we cannot power down
      INTCS because that would risk losing interrupts.
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      382414b9
    • M
      ARM: mach-shmobile: sh7372 A3SP support (v4) · d93f5cde
      Magnus Damm 提交于
      This change adds support for the sh7372 A3SP power domain.
      
      The sh7372 A3SP hardware power domain contains a
      wide range of I/O devices. The list of I/O devices
      include SCIF serial ports, DMA Engine hardware,
      SD and MMC controller hardware, USB controllers
      and I2C master controllers.
      
      This patch adds the A3SP low level code which
      powers the hardware power domain on and off. It
      also ties in platform devices to the pm domain
      support code.
      
      It is worth noting that the serial console is
      hooked up to SCIFA0 on most sh7372 boards, and
      the SCIFA0 port is included in the A3SP hardware
      power domain. For this reason we cannot output
      debug messages from the low level power control
      code in the case of A3SP.
      
      QoS support is needed in drivers before we can
      enable the A3SP power control on the fly.
      Signed-off-by: NMagnus Damm <damm@opensource.se>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d93f5cde
  6. 26 9月, 2011 2 次提交
  7. 29 8月, 2011 1 次提交
  8. 25 8月, 2011 1 次提交
  9. 22 8月, 2011 1 次提交
  10. 12 8月, 2011 3 次提交
  11. 13 7月, 2011 1 次提交
  12. 10 7月, 2011 3 次提交
  13. 02 7月, 2011 4 次提交
  14. 29 6月, 2011 1 次提交
  15. 21 6月, 2011 1 次提交
  16. 25 5月, 2011 6 次提交
  17. 24 5月, 2011 1 次提交
  18. 23 5月, 2011 1 次提交
  19. 07 4月, 2011 1 次提交
  20. 25 3月, 2011 1 次提交
  21. 18 2月, 2011 1 次提交
  22. 15 2月, 2011 2 次提交
  23. 25 1月, 2011 1 次提交
    • S
      ARM: 6617/1: mmc, Add zboot from MMC support for SuperH Mobile ARM · f45b1149
      Simon Horman 提交于
      This allows a ROM-able zImage to be written to MMC and
      for SuperH Mobile ARM to boot directly from the MMCIF
      hardware block.
      
      This is achieved by the MaskROM loading the first portion
      of the image into MERAM and then jumping to it. This portion
      contains loader code which copies the entire image to SDRAM
      and jumps to it. From there the zImage boot code proceeds
      as normal, uncompressing the image into its final location
      and then jumping to it.
      
      Cc: Magnus Damm <magnus.damm@gmail.com>
      
      Russell, please consider merging this for 2.6.38.
      
      This patch depends on:
      * "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
        which will be merged though Paul Mundt's rmobile sh-2.6.
        The absence of this patch will break the build if
        the (new) CONFIG_ZBOOT_ROM_MMCIF option is set.
        There are no subtle side-effects.
      
      v2:
      Addressed comments by Magnus Damm
      * Fix copyright in vrl4.c
      * Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
      * Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
        as this is considered board-specific.
      
      v3:
      Addressed comments made in person by Magnus Damm
      * Move mmcif_loader to be earlier in the image and
        reduce the number of blocks of boot program loaded by the MaskRom
        from 40 to 8 accordingly.
      * Move LED GPIO initialisation into mmcif_progress_init
        - This leaves the partner jet script unbloated
      Other
      * inline mmcif_update_progress so it is a static inline in a header file
      
      v4:
      * Use htole16() and htole32() in v4rl.c to ensure
        that the output is little endian
      
      v5:
      Addressed comments by Russell King
      * Simplify assembly code
      * Jump to code rather than an address <- bug fix
      * Use (void __iomem *) as appropriate
      Roll in mackerel support
      * This was previously a separate patch, only because of the order
        in which this code was developed
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f45b1149