1. 23 9月, 2012 1 次提交
    • R
      ARM: omap: clk: add clk_prepare and clk_unprepare · 4d7cb45e
      Rajendra Nayak 提交于
      As part of Common Clk Framework (CCF) the clk_enable() operation
      was split into a clk_prepare() which could sleep, and a clk_enable()
      which should never sleep. Similarly the clk_disable() was
      split into clk_disable() and clk_unprepare(). This was
      needed to handle complex cases where in a clk gate/ungate
      would require a slow and a fast part to be implemented.
      None of the clocks below seem to be in the 'complex' clocks
      category and are just simple clocks which are enabled/disabled
      through simple register writes.
      Most of the instances also seem to be called in non-atomic
      context which means its safe to move all of those from
      using a clk_enable() to clk_prepare_enable() and clk_disable() to
      clk_disable_unprepare().
      
      For some others, mainly the ones handled through the hwmod framework
      there is a possibility that they get called in either an atomic
      or a non-atomic context.
      
      The way these get handled below work only as long as clk_prepare
      is implemented as a no-op (which is the case today) since this gets
      called very early at boot while most subsystems are unavailable.
      Hence these are marked with a *HACK* comment, which says we need
      to re-visit these once we start doing something meaningful with
      clk_prepare/clk_unprepare like doing voltage scaling or something
      that involves i2c.
      
      This is in preparation of OMAP moving to CCF.
      
      Based on initial changes from Mike Turquette.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4d7cb45e
  2. 13 9月, 2012 3 次提交
    • T
      ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ · dbc04161
      Tony Lindgren 提交于
      As the plat and mach includes need to disappear for single zImage work,
      we need to remove plat/hardware.h.
      
      Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
      
      The old plat/hardware.h already has omap1 only defines, so it gets moved
      to mach/hardware.h for omap1. For omap2+, we use the local soc.h
      that for now just includes the related SoC headers to keep this patch more
      readable.
      
      Note that the local soc.h still includes plat/cpu.h that can be dealt
      with in later patches. Let's also include plat/serial.h from common.h for
      all the board-*.c files. This allows making the include files local later
      on without patching these files again.
      
      Note that only minimal changes are done in this patch for the
      drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
      patches are needed to eventually remove cpu_is_omap usage in the drivers.
      
      Also only minimal changes are done to sound/soc/omap/* to remove the
      unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
      no need to include omap44xx.h.
      
      While at it, also sort some of the includes in the standard way.
      
      Cc: linux-watchdog@vger.kernel.org
      Cc: alsa-devel@alsa-project.org
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Acked-by: NWim Van Sebroeck <wim@iguana.be>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc04161
    • T
      ARM: OMAP2+: Prepare for irqs.h removal · 7d7e1eba
      Tony Lindgren 提交于
      As the interrupts should only be defined in the platform_data, and
      eventually coming from device tree, there's no need to define them
      in header files.
      
      Let's remove the hardcoded references to irqs.h and fix up the includes
      so we don't rely on headers included in irqs.h. Note that we're
      defining OMAP_INTC_START as 0 to the interrupts. This will be needed
      when we enable SPARSE_IRQ. For some drivers we need to add
      #include <plat/cpu.h> for now until these drivers are fixed to
      remove cpu_is_omapxxxx() usage.
      
      While at it, sort som of the includes the standard way, and add
      the trailing commas where they are missing in the related data
      structures.
      
      Note that for drivers/staging/tidspbridge we just define things
      locally.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7d7e1eba
    • T
      ARM: OMAP2+: Remove hardcoded twl4030 gpio_base, irq_base and irq_end · a940d9a1
      Tony Lindgren 提交于
      We can't use hardcoded interrupts for SPARSE_IRQ, and can replace
      the hardcoded gpio_base with twl_gpiochip.base after it's been
      allocated.
      
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a940d9a1
  3. 11 9月, 2012 1 次提交
  4. 20 7月, 2012 1 次提交
  5. 09 7月, 2012 1 次提交
  6. 10 5月, 2012 4 次提交
  7. 09 5月, 2012 4 次提交
  8. 08 5月, 2012 1 次提交
  9. 16 4月, 2012 1 次提交
  10. 13 4月, 2012 1 次提交
    • P
      ARM: OMAP2+: declare file-local functions as static · 8c3d4534
      Paul Walmsley 提交于
      Several function declarations used only in the files in which they're
      declared should include the static keyword, but don't:
      
          arch/arm/mach-omap2/serial.c:248:6: warning: symbol 'cmdline_find_option' was not declared. Should it be static?
          arch/arm/mach-omap2/omap-wakeupgen.c:259:6: warning: symbol 'irq_sar_clear' was not declared. Should it be static?
          arch/arm/mach-omap2/board-rx51-peripherals.c:878:27: warning: symbol 'rx51_vibra_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-rx51-peripherals.c:882:27: warning: symbol 'rx51_audio_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:201:29: warning: symbol 'omap_panda_wlan_data' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:393:24: warning: symbol 'omap4_panda_dvi_device' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:403:12: warning: symbol 'omap4_panda_dvi_init' was not declared. Should it be static?
          arch/arm/mach-omap2/board-omap4panda.c:464:6: warning: symbol 'omap4_panda_display_init' was not declared. Should it be static?
          arch/arm/mach-omap2/hsmmc.c:434:6: warning: symbol 'omap_init_hsmmc' was not declared. Should it be static?
          arch/arm/mach-omap2/hwspinlock.c:31:12: warning: symbol 'hwspinlocks_init' was not declared. Should it be static?
          arch/arm/mach-omap1/timer.c:58:12: warning: symbol 'omap1_dm_timer_init' was not declared. Should it be static?
          arch/arm/mach-omap1/fpga.c:90:6: warning: symbol 'innovator_fpga_IRQ_demux' was not declared. Should it be static?
      
      Mark all of these as static.
      
      Thanks to Arnd Bergmann <arnd@arndb.de> for pointing out a typo in the
      original patch description.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Govindraj R <govindraj.raja@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: David Anders <x0132446@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      8c3d4534
  11. 29 3月, 2012 1 次提交
  12. 22 3月, 2012 1 次提交
  13. 12 3月, 2012 1 次提交
  14. 06 3月, 2012 1 次提交
  15. 25 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init · d1589f09
      Tony Lindgren 提交于
      Now that omap hsmmc init is split into two functions, it's safe
      to mark omap_hsmmc_init and omap_mux related functions to __init.
      
      This basically reverts the following fixes for the case where
      TWL was compiled as a module:
      
      a98f77bb (ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup())
      8930b4e3 (ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c)
      
      Additionally it fixes up the remaining section warnings for
      all callers of omap_mux functions.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d1589f09
  16. 21 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins · 3b972bf0
      Tony Lindgren 提交于
      Otherwise omap_device_build() and omap_mux related functions
      can't be marked as __init when twl is build as a module.
      
      If a board is using GPIO pins or regulators configured by an
      external chip, such as TWL PMIC on I2C bus, the board must
      mark those MMC controllers as deferred. Additionally both
      omap_hsmmc_init() and omap_hsmmc_late_init() must be called
      by the board.
      
      For MMC controllers using internal GPIO pins for card
      detect and regulators the slots don't need to be marked
      deferred. In this case calling omap_hsmmc_init() is sufficient.
      
      Only mark the MMC slots using gpio_cd or gpio_wd as deferred
      as noted by Igor Grinberg <grinberg@compulab.co.il>.
      
      Note that this patch does not change the behaviour for
      board-4430sdp.c board-omap4panda.c. These boards wrongly
      rely on the omap_hsmmc.c init function callback to configure
      the PMIC GPIO interrupt lines on external chip. If the PMIC
      interrupt lines are not configured during init, they will
      fail.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      3b972bf0
  17. 13 2月, 2012 1 次提交
    • R
      ARM: omap: resolve nebulous 'Error setting wl12xx data' · 70d669de
      Russell King 提交于
      It's useful to print the error code when a called function fails so a
      diagnosis of why it failed is possible.  In this case, it fails because
      we try to register some data for the wl12xx driver, but as the driver
      is not configured, a stub function is used which simply returns -ENOSYS.
      
      Let's do the simple thing for -rc and print the error code.
      
      Also, the return code from platform_register_device() at each of these
      sites was not being checked.  Add some checking, and again print the
      error code.
      
      This should be fixed properly for the next merge window so we don't
      issue error messages merely because a driver is not configured.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      70d669de
  18. 26 1月, 2012 6 次提交
  19. 05 1月, 2012 3 次提交
  20. 15 12月, 2011 1 次提交
    • G
      ARM: OMAP2+: UART: Add default mux for all uarts. · 7496ba30
      Govindraj.R 提交于
      Padconf wakeup is used to wakeup uart after uart fclks/iclks are gated.
      Rx-Pad wakeup was done by writing to rx-pad offset value populated in
      serial.c idle_init. Remove the direct reading and writing into rx pad.
      Remove the padconf field part of omap_uart_state struct and pad offsets
      populated.
      
      Now with mux framework support we can use mux_utilities
      along with hmwod framework to handle io-pad configuration and enable rx-pad
      wake-up mechanism.
      
      To avoid breaking any board support add default mux data for all uart's
      if mux info is not passed from board file.
      With the default pads populated in serial.c wakeup capability for
      rx pads is set, this can be used to enable uart_rx io-pad wakeup from
      hwmod framework. The pad values in 3430sdp/4430sdp/omap4panda board file
      are same as the default pad values populated in serial.c. Remove pad values
      from 3430sdp/4430sdp/omap4panda board file and use the default pads
      from serial.c file.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      7496ba30
  21. 18 11月, 2011 1 次提交
  22. 16 11月, 2011 1 次提交
  23. 30 9月, 2011 2 次提交
  24. 27 9月, 2011 1 次提交