1. 22 1月, 2011 2 次提交
    • D
      msm: Generalize timer register mappings · 8c27e6f3
      David Brown 提交于
      Allow the timer register to be determined dynamically instead of at
      compile time.  Use common virtual addresses for the registers across
      all MSM chips, and select the register mappings based on the detected
      CPU.
      Signed-off-by: NDavid Brown <davidb@codeaurora.org>
      8c27e6f3
    • D
      msm: Add CPU queries · 87fa28e9
      David Brown 提交于
      Create runtime queries to distinguish the various MSM targets.
      Although these would probably be better named soc_is..., use
      cpu_is... to match convention in the rest of the kernel.
      
      Hard code the tests based on config options for now.  When runtime
      device detection is implemented, these can be made dynamic.
      Signed-off-by: NDavid Brown <davidb@codeaurora.org>
      87fa28e9
  2. 08 1月, 2011 1 次提交
  3. 17 12月, 2010 1 次提交
  4. 10 12月, 2010 1 次提交
  5. 03 12月, 2010 1 次提交
  6. 01 12月, 2010 3 次提交
  7. 22 11月, 2010 1 次提交
  8. 17 11月, 2010 1 次提交
  9. 30 10月, 2010 2 次提交
    • D
      msm: fix compile failure when no debug uart is selected · 06125ff0
      Daniel Walker 提交于
      If the board has a debug uart the user is given a choice of which
      uart to use. The user can also select NONE, which means not to use one.
      In most of our header files when NONE is selected nothing is defined
      for MSM_DEBUG_UART_PHYS or MSM_DEBUG_UART_BASE. This causes a compile
      failure in debug-macro.S which expect something to be defined there.
      
      Example of the failure,
      
      arch/arm/kernel/built-in.o: In function `hexbuf':
      linux-2.6/arch/arm/kernel/debug.S:186: undefined reference to `MSM_DEBUG_UART_PHYS'
      linux-2.6/arch/arm/kernel/debug.S:186: undefined reference to `MSM_DEBUG_UART_BASE'
      
      This fixes the compile failure by adding an ifdef to debug-macro.S
      that removes all the debug uart code in the case of NONE.
      Signed-off-by: NDaniel Walker <dwalker@codeaurora.org>
      06125ff0
    • D
      msm: fix debug-macro.S build failure · bcd72c3e
      Daniel Walker 提交于
      Originally there was an ifdef case to handle when no debug uart
      was selected. In commit 0ea12930
      that case was removed which causes the following build failure,
      
      linux-2.6/arch/arm/kernel/debug.S: Assembler messages:
      linux-2.6/arch/arm/kernel/debug.S:174: Error: bad instruction `addruart r1,r2'
      linux-2.6/arch/arm/kernel/debug.S:176: Error: bad instruction `waituart r2,r3'
      linux-2.6/arch/arm/kernel/debug.S:177: Error: bad instruction `senduart r1,r3'
      linux-2.6/arch/arm/kernel/debug.S:178: Error: bad instruction `busyuart r2,r3'
      linux-2.6/arch/arm/kernel/debug.S:190: Error: bad instruction `addruart r1,r2'
      
      This is a partial revert to add back the case which was removed with
      two caveats. First the API for the addruart macro was updated, and
      the new addruart case now return 0xfff00000 so that a know IO mapping
      is created instead of a random one.
      
      Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Jason Wang <jason77.wang@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
      Signed-off-by: NDaniel Walker <dwalker@codeaurora.org>
      bcd72c3e
  10. 20 10月, 2010 1 次提交
  11. 09 10月, 2010 11 次提交
  12. 07 10月, 2010 2 次提交
    • G
      msm: gpio: Remove tlmm routines obsoleted by gpiomux. · 10c4580e
      Gregory Bean 提交于
      Now that all supported gpio_tlmm_config-using boards
      are using gpiomux, remove the deprecated code.
      Signed-off-by: NGregory Bean <gbean@codeaurora.org>
      Signed-off-by: NDaniel Walker <dwalker@codeaurora.org>
      10c4580e
    • G
      msm: add gpiomux api for gpio multiplex & configuration. · 1963a2af
      Gregory Bean 提交于
      Add the 'gpiomux' api, which addresses the following shortcomings
      of existing tlmm api:
      
      - gpio power-collapse, which is managed by a peripheral processor on
        other targets, must be managed by the application processor on the 8x60.
      - The enable/disable flag of the legacy gpio_tlmm_config api
        is not applicable on the 8x60, and causes confusion.
      - The gpio 'direction' bits are meaningless for all func_sel
        configurations except for generic-gpio mode (func_sel 0), in which
        case the gpio_direction_* functions should be used.  Having these
        bits in the tlmm api leads to confusion and misuse of the gpiolib
        api, and they have been removed in gpiomux.
      - The functional api of the legacy system ran contrary to the typical
        use-case, which is a single massive configuration at boot.  Rather
        than forcing hundreds of 'config' function calls, the new api
        allows data to be configured with a single table.
      
      gpiomux_get and gpiomux_put are meant to be called automatically
      when gpio_request and gpio_free are called, giving automatic
      gpiomux/tlmm control to those drivers/lines with simple
      power profiles - in the simplest cases, an entry in the gpiomux table
      and the correct usage of gpiolib is all that is required to get proper
      gpio power control.
      Signed-off-by: NGregory Bean <gbean@codeaurora.org>
      Signed-off-by: NDaniel Walker <dwalker@codeaurora.org>
      1963a2af
  13. 02 10月, 2010 1 次提交
    • N
      ARM: do not define VMALLOC_END relative to PAGE_OFFSET · 7c63984b
      Nicolas Pitre 提交于
      VMALLOC_END is supposed to be an absolute value, while PAGE_OFFSET may
      vary depending on the selected user:kernel memory split mode through
      CONFIG_VMSPLIT_*.  In fact, the goal of moving PAGE_OFFSET down is to
      accommodate more directly addressed RAM by the kernel below the vmalloc
      area, and having VMALLOC_END move along PAGE_OFFSET is rather against
      the very reason why PAGE_OFFSET can be moved in the first place.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      7c63984b
  14. 10 8月, 2010 2 次提交
  15. 16 6月, 2010 1 次提交
  16. 14 5月, 2010 9 次提交