1. 16 10月, 2012 1 次提交
  2. 19 9月, 2012 1 次提交
    • A
      ARM: omap: move platform_data definitions · 2203747c
      Arnd Bergmann 提交于
      Platform data for device drivers should be defined in
      include/linux/platform_data/*.h, not in the architecture
      and platform specific directories.
      
      This moves such data out of the omap include directories
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: "Benoît Cousson" <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: Jean Pihet <j-pihet@ti.com>
      Cc: J Keerthy <j-keerthy@ti.com>
      Cc: linux-omap@vger.kernel.org
      2203747c
  3. 13 9月, 2012 2 次提交
    • 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
  4. 12 9月, 2012 1 次提交
    • P
      ARM: OMAP: unwrap strings · 7852ec05
      Paul Walmsley 提交于
      Find and unwrap wrapped strings in the style:
      
      	pr_debug("clockdomain: hardware cannot set/clear wake up of "
      		 "%s when %s wakes up\n", clkdm1->name, clkdm2->name);
      
      Keeping these strings contiguous seems to be the current Linux kernel
      policy.
      
      The offending lines were found with the following command:
      
          pcregrep -rnM '"\s*$\s*"' arch/arm/*omap*
      
      While here, some messages have been clarified, some pr_warning(
      ... calls have been converted to pr_warn( ..., and some printk(KERN_*
      ... have been converted to pr_*.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      7852ec05
  5. 11 9月, 2012 1 次提交
  6. 31 7月, 2012 1 次提交
  7. 20 6月, 2012 1 次提交
    • T
      ARM: OMAP2+: Fix MUSB ifdefs for platform init code · 310018d5
      Tony Lindgren 提交于
      Commit 62285963 (usb: musb: drop a gigantic amount of ifdeferry)
      got rid of a bunch of ifdefs in the MUSB code. Looks like the
      platform init code is still using these dropped defines though,
      which in many cases results the board defaulting always to host
      mode.
      
      Currently the situation is that USB_MUSB_HDRC is the main
      Kconfig option with additional USB_GADGET_MUSB_HDRC so only
      these two should be used to select between host and OTG mode.
      
      Fix the situation for omaps. The following users should fix the
      platform init code in a similar way:
      
      Dropped Kconfig option          Current users
      
      USB_MUSB_OTG                    blackfin, davinci, not in Kconfigs
      USB_MUSB_PERIPHERAL             davinci, not in Kconfigs
      USB_MUSB_HOST                   davinci, not in Kconfigs
      USB_MUSB_HDRC_HCD               blackfin, not in Kconfigs
      USB_MUSB_OTG                    blackfin, not in Kconfigs
      
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: linux-usb@vger.kernel.org
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      310018d5
  8. 08 5月, 2012 1 次提交
  9. 07 3月, 2012 1 次提交
  10. 25 2月, 2012 1 次提交
  11. 21 2月, 2012 1 次提交
  12. 05 1月, 2012 1 次提交
  13. 15 12月, 2011 1 次提交
    • D
      ARM: OMAP2+: UART: Allow UART parameters to be configured from board file. · c86845db
      Deepak K 提交于
      The following UART parameters are defined within the UART driver:
      
      1). Whether the UART uses DMA (dma_enabled), by default set to 0
      2). The size of dma buffer (set to 4096 bytes)
      3). The time after which the dma should stop if no more data is received.
      4). The auto suspend delay that will be passed for pm_runtime_autosuspend
          where uart will be disabled after timeout
      
      Different UARTs may be used for different purpose such as the console,
      for interfacing bluetooth chip, for interfacing to a modem chip, etc.
      Therefore, it is necessary to be able to customize the above settings
      for a given board on a per UART basis.
      
      This change allows these parameters to be configured from the board file
      and allows the parameters to be configured for each UART independently.
      
      If a board does not define its own custom parameters for the UARTs, then
      use the default parameters in the structure "omap_serial_default_info".
      The default parameters are defined to be the same as the current settings
      in the UART driver to avoid breaking the UART for any cuurnelty supported
      boards. By default, make all boards use the default UART parameters.
      Signed-off-by: NDeepak K <deepak.k@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      c86845db
  14. 12 12月, 2011 1 次提交
  15. 18 11月, 2011 1 次提交
  16. 16 11月, 2011 1 次提交
  17. 27 9月, 2011 1 次提交
  18. 24 8月, 2011 2 次提交
    • T
      ARM: OMAP: Introduce SoC specific early_init · 8f5b5a41
      Tony Lindgren 提交于
      Introduce them for each omap variant and just make them all call
      omap2_init_common_infrastructure for now. Do this for each board-*.c
      file except for board-generic and board-omap3beagle as they use
      the same machine ID for multiple SoCs.
      
      No functional changes.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      8f5b5a41
    • T
      ARM: OMAP: Move omap2_init_common_devices out of init_early · a4ca9dbe
      Tony Lindgren 提交于
      There's no need to call omap2_init_common_devices from init_early.
      
      It no longer does anything else except reprogram the memory timings
      for some boards, so it's better to do it later so we have a chance
      to get console messages if something goes wrong.
      
      Move it to happen after omap_serial_init gets called. And while
      patching it anyways, rename it to omap_sdrc_init as suggested by
      Benoit Cousson <b-cousson@ti.com>.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a4ca9dbe
  19. 22 8月, 2011 1 次提交
  20. 20 6月, 2011 1 次提交
    • T
      omap: Set separate timer init functions to avoid cpu_is_omap tests · e74984e4
      Tony Lindgren 提交于
      This is needed for the following patches so we can initialize the
      rest of the hardware timers later on.
      
      As with the init_irq calls, there's no need to do cpu_is_omap calls
      during the timer init as we only care about the major omap generation.
      This means that we can initialize the sys_timer with the .timer
      entries alone.
      
      Note that for now we just set stubs for the various sys_timer entries
      that will get populated in a later patch. The following patches will
      also remove the omap_dm_timer_init calls and change the init for the
      rest of the hardware timers to happen with an arch_initcall.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      e74984e4
  21. 16 6月, 2011 1 次提交
  22. 12 5月, 2011 1 次提交
  23. 02 3月, 2011 1 次提交
    • A
      omap: mmc: split out init for 2420 · e08016d0
      Anand Gadiyar 提交于
      The MMC controller on the OMAP2420 is different from those
      on the OMAP2430, OMAP3 and OMAP4 families - all of the latter
      are identical. The one on the OMAP2420 is closer to that
      on OMAP1 chips.
      
      Currently, the n8x0 is the only OMAP2420 platform supported
      in mainline which registers the MMC controller. Upcoming
      changes to register the controllers using hwmod data are
      potentially invasive. To reduce the risk, separate out the
      2420 controller registration from the common init function
      and update its only user. Also seperating out mux settings
      for OMAP2420.
      Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Chris Ball <cjb@laptop.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e08016d0
  24. 15 2月, 2011 1 次提交
  25. 23 12月, 2010 1 次提交
  26. 22 12月, 2010 1 次提交
    • P
      OMAP2+: io: split omap2_init_common_hw() · 4805734b
      Paul Walmsley 提交于
      Split omap2_init_common_hw() into two functions.  The first,
      omap2_init_common_infrastructure(), initializes the hwmod code and
      data, the OMAP PM code, and the clock code and data.  The second,
      omap2_init_common_devices(), handles any other early device
      initialization that, for whatever reason, has not been or cannot be
      moved to initcalls or early platform devices.
      
      This patch is required for the hwmod postsetup patch, which allows
      board files to change the state that hwmods should be placed into at
      the conclusion of the hwmod _setup() function.  For example, for a
      board whose creators wish to ensure watchdog coverage across the
      entire kernel boot process, code to change the watchdog's postsetup
      state will be added in the board-*.c file between the
      omap2_init_common_infrastructure() and omap2_init_common_devices() function
      calls.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      4805734b
  27. 10 12月, 2010 1 次提交
  28. 08 12月, 2010 1 次提交
    • V
      OMAP: GPIO: Implement GPIO as a platform device · 77640aab
      Varadarajan, Charulatha 提交于
      Implement GPIO as a platform device.
      
      GPIO APIs are used in machine_init functions. Hence it is
      required to complete GPIO probe before board_init. Therefore
      GPIO device register and driver register are implemented as
      postcore_initcalls.
      
      omap_gpio_init() does nothing now and this function would be
      removed in the next patch as it's usage is spread across most
      of the board files.
      
      Inorder to convert GPIO as platform device, modifications are
      required in clockxxxx_data.c file for OMAP1 so that device names
      can be used to obtain clock instead of getting clocks by
      name/NULL ptr.
      
      Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling
      or disabling the clocks, modify sysconfig settings and remove usage
      of clock FW APIs.
      Note 1: Converting GPIO driver to use runtime PM APIs is not done as a
      separate patch because GPIO clock names are different for various OMAPs
      and are different for some of the banks in the same CPU. This would need
      usage of cpu_is checks and bank id checks while using clock FW APIs in
      the gpio driver. Hence while making GPIO a platform driver framework,
      PM runtime APIs are used directly.
      
      Note 2: While implementing GPIO as a platform device, pm runtime APIs
      are used as mentioned above and modification is not done in gpio's
      prepare for idle/ resume after idle functions. This would be done
      in the next patch series and GPIO driver would be made to use dev_pm_ops
      instead of sysdev_class in that series only.
      
      Due to the above, the GPIO driver implicitly relies on
      CM_AUTOIDLE = 1 on its iclk for power management to work, since the
      driver never disables its iclk.
      This would be taken care in the next patch series (see Note 3 below).
      
      Refer to
      http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html
      for more details.
      
      Note 3: only pm_runtime_get_sync is called in gpio's probe() and
      pm_runtime_put* is never called. This is to make the implementation
      similar to the existing GPIO code. Another patch series would be sent
      to correct this.
      
      In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They
      are enabled/ disabled whenever required using clock framework APIs
      
      TODO:
      1. Cleanup the GPIO driver. Use function pointers and register
      offest pointers instead of using hardcoded values
      2. Remove all cpu_is_ checks and OMAP specific macros
      3. Remove usage of gpio_bank array so that only
         instance specific information is used in driver code
      4. Rename 'method'/ avoid it's usage
      5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4
      6. Modify gpio's prepare for idle/ resume after idle functions
         to use runtime pm implentation.
      Signed-off-by: NCharulatha V <charu@ti.com>
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Reviewed-by: NBasak, Partha <p-basak2@ti.com>
      Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
      [tony@atomide.com: updated for bank specific revision and updated boards]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      77640aab
  29. 03 12月, 2010 2 次提交
  30. 20 10月, 2010 1 次提交
    • N
      arm: remove machine_desc.io_pg_offst and .phys_io · 6451d778
      Nicolas Pitre 提交于
      Since we're now using addruart to establish the debug mapping, we can
      remove the io_pg_offst and phys_io members of struct machine_desc.
      
      The various declarations were removed using the following script:
      
        grep -rl MACHINE_START arch/arm | xargs \
        sed -i '/MACHINE_START/,/MACHINE_END/ { /\.\(phys_io\|io_pg_offst\)/d }'
      
      [ Initial patch was from Jeremy Kerr, example script from Russell King ]
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: Eric Miao <eric.miao at canonical.com>
      6451d778
  31. 09 10月, 2010 1 次提交
    • M
      OMAP2plus: Fix static function warnings · 04aeae77
      Manjunath Kondaiah G 提交于
      This patch fixes sparse warnings due non declarations of static functions.
      
      arch/arm/mach-omap2/timer-gp.c:115:12: warning: symbol 'omap2_gp_clockevent_set_gptimer' was not declared. Should it be static?
      arch/arm/mach-omap2/powerdomain.c:993:5: warning: symbol 'pwrdm_set_lowpwrstchange' was not declared. Should it be static?
      arch/arm/mach-omap2/board-flash.c:141:8: warning: symbol 'board_nand_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-n8x0.c:416:6: warning: symbol 'n8x0_mmc_slot1_cover_handler' was not declared. Should it be static?
      arch/arm/mach-omap2/board-n8x0.c:544:13: warning: symbol 'n8x0_mmc_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-rx51-peripherals.c:902:13: warning: symbol 'rx51_peripherals_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-rx51-video.c:107:13: warning: symbol 'rx51_video_mem_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-zoom-debugboard.c:155:12: warning: symbol 'zoom_debugboard_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-zoom-peripherals.c:280:13: warning: symbol 'zoom_peripherals_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-igep0020.c:110:13: warning: symbol 'igep2_flash_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-am3517evm.c:109:6: warning: symbol 'am3517_evm_ethernet_init' was not declared. Should it be static?
      drivers/mtd/onenand/omap2.c:577:5: warning: symbol 'omap2_onenand_rephase' was not declared. Should it be static?
      Signed-off-by: NManjunath Kondaiah G <manjugk@ti.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      04aeae77
  32. 05 10月, 2010 1 次提交
  33. 28 9月, 2010 1 次提交
  34. 24 9月, 2010 3 次提交
  35. 17 8月, 2010 1 次提交