1. 14 12月, 2011 1 次提交
  2. 19 11月, 2011 1 次提交
  3. 18 11月, 2011 1 次提交
  4. 16 11月, 2011 1 次提交
  5. 05 11月, 2011 1 次提交
    • S
      ARM: OMAP: Fix errors and warnings when building for one board · c4e2d245
      Sanjeev Premi 提交于
      When customizing omap2plus_defconfig to build for only
      one board (omap3evm), I came across these warnings and
      errors (filenames truncated):
      
      arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used
      arch/arm/mach-omap2/built-in.o: In function `omap2420_init_early':
      arch/arm/mach-omap2/io.c:364: undefined reference to `omap2_set_globals_242x'
      arch/arm/mach-omap2/io.c:366: undefined reference to `omap2xxx_voltagedomains_init'
      arch/arm/mach-omap2/io.c:367: undefined reference to `omap242x_powerdomains_init'
      arch/arm/mach-omap2/io.c:368: undefined reference to `omap242x_clockdomains_init'
      arch/arm/mach-omap2/io.c:369: undefined reference to `omap2420_hwmod_init'
      arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
      arch/arm/mach-omap2/io.c:376: undefined reference to `omap2_set_globals_243x'
      arch/arm/mach-omap2/io.c:378: undefined reference to `omap2xxx_voltagedomains_init'
      arch/arm/mach-omap2/io.c:379: undefined reference to `omap243x_powerdomains_init'
      arch/arm/mach-omap2/io.c:380: undefined reference to `omap243x_clockdomains_init'
      arch/arm/mach-omap2/io.c:381: undefined reference to `omap2430_hwmod_init'
      arch/arm/mach-omap2/built-in.o: In function `omap4430_init_early':
      arch/arm/mach-omap2/io.c:436: undefined reference to `omap2_set_globals_443x'
      arch/arm/mach-omap2/io.c:438: undefined reference to `omap44xx_voltagedomains_init'
      arch/arm/mach-omap2/io.c:439: undefined reference to `omap44xx_powerdomains_init'
      arch/arm/mach-omap2/io.c:440: undefined reference to `omap44xx_clockdomains_init'
      arch/arm/mach-omap2/io.c:441: undefined reference to `omap44xx_hwmod_init'
      
      This patch fixes them.
      Signed-off-by: NSanjeev Premi <premi@ti.com>
      Acked-by: NThomas Weber <weber@corscience.de>
      [tony@atomide.com: updated to fix warnings for board-generic.c]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c4e2d245
  6. 20 10月, 2011 4 次提交
  7. 16 9月, 2011 2 次提交
    • K
      OMAP2: add voltage domains and connect to powerdomains · aae030fa
      Kevin Hilman 提交于
      Create basic voltagedomains for OMAP2 and associate OMAP2 powerdomains
      with the newly created voltage domains.
      
      While here, update copyright on powerdomain data to 2011.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      aae030fa
    • K
      OMAP2+: voltage: start towards a new voltagedomain layer · 81a60482
      Kevin Hilman 提交于
      Start cleaning up the voltage layer to have a voltage domain layer
      that resembles the structure of the existing clock and power domain
      layers.  To that end:
      
      - move the 'struct voltagedomain' out of 'struct omap_vdd_info' to
        become the primary data structure.
      
      - convert any functions taking a pointer to struct omap_vdd_info into
        functions taking a struct voltagedomain pointer.
      
      - convert the register & initialize of voltage domains to look like
        that of powerdomains
      
      - convert omap_voltage_domain_lookup() to voltdm_lookup(), modeled
        after the current powerdomain and clockdomain lookup functions.
      
      - omap_voltage_late_init(): only configure VDD info when
        the vdd_info struct is non-NULL
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      81a60482
  8. 15 9月, 2011 2 次提交
    • P
      OMAP: powerdomain: remove omap_chip bitmasks · 8179488a
      Paul Walmsley 提交于
      At Tony's request, remove the omap_chip bitmasks from the powerdomain
      definitions.  Instead, initialize powerdomains based on one or more
      lists that are applicable to a particular SoC family, variant, and
      silicon revision.
      
      Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a
      related patch that also applied to this patch - thanks Gražvydas.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Gražvydas Ignotas <notasas@gmail.com>
      8179488a
    • P
      OMAP: clockdomain code/data: remove omap_chip bitmask from struct clockdomain · a5ffef6a
      Paul Walmsley 提交于
      At Tony's request, remove the omap_chip bitmasks from the clockdomain
      and clockdomain dependency definitions.  Instead, initialize
      clockdomains based on one or more lists that are applicable to a
      particular SoC family, variant, and silicon revision.
      
      Tony Lindgren <tony@atomide.com> found a bug in a previous version of this
      patch - thanks Tony.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      a5ffef6a
  9. 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
  10. 22 8月, 2011 1 次提交
  11. 16 6月, 2011 1 次提交
  12. 26 2月, 2011 1 次提交
    • R
      OMAP: clockdomain: Arch specific funcs to handle deps · 4aef7a2a
      Rajendra Nayak 提交于
      Define the following architecture specific funtions for omap2/3
      .clkdm_add_wkdep
      .clkdm_del_wkdep
      .clkdm_read_wkdep
      .clkdm_clear_all_wkdeps
      .clkdm_add_sleepdep
      .clkdm_del_sleepdep
      .clkdm_read_sleepdep
      .clkdm_clear_all_sleepdeps
      
      Convert the platform-independent framework to call these functions.
      With this also move the clkdm lookups for all wkdep_srcs and
      sleepdep_srcs at clkdm_init.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: fixed loop termination conditions in omap*_clkdm_clear_all_*();
       thanks to Kevin Hilman for finding and helping fix those bugs; also
       avoid re-resolving clockdomains during init; abstracted out clkdm_dep walk]
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4aef7a2a
  13. 18 2月, 2011 1 次提交
  14. 17 2月, 2011 1 次提交
  15. 15 2月, 2011 2 次提交
  16. 28 1月, 2011 2 次提交
  17. 22 12月, 2010 9 次提交
    • P
      OMAP2+: powerdomain: move header file from plat-omap to mach-omap2 · 72e06d08
      Paul Walmsley 提交于
      The OMAP powerdomain code and data is all OMAP2+-specific.  This seems
      unlikely to change any time soon.  Move plat-omap/include/plat/powerdomain.h
      to mach-omap2/powerdomain.h.  The primary point of doing this is to remove
      the temptation for unrelated upper-layer code to access powerdomain code
      and data directly.
      
      As part of this process, remove the references to powerdomain data
      from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap.
      Change the DSPBridge code to point to the new location for the
      powerdomain headers.  The DSPBridge code should not be including the
      powerdomain headers; these should be removed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      72e06d08
    • P
      OMAP2+: clockdomain: move header file from plat-omap to mach-omap2 · 1540f214
      Paul Walmsley 提交于
      The OMAP clockdomain code and data is all OMAP2+-specific.  This seems
      unlikely to change any time soon.  Move plat-omap/include/plat/clockdomain.h
      to mach-omap2/clockdomain.h.  The primary point of doing this is to remove
      the temptation for unrelated upper-layer code to access clockdomain code
      and data directly.
      
      DSPBridge also uses the clockdomain headers for some reason, so,
      modify it also. The DSPBridge code should not be including the
      clockdomain headers; these should be removed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      1540f214
    • P
      OMAP2+: clockdomains: move clockdomain static data to .c files · dc0b3a70
      Paul Walmsley 提交于
      Static data should be declared in .c files, not .h files.  It should be
      possible to #include .h files at any point without creating multiple
      copies of the same data.
      
      We converted the clock data to .c files some time ago.  This patch does
      the same for the clockdomain data.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      dc0b3a70
    • P
      OMAP2+: powerdomains: move powerdomain static data to .c files · 6e01478a
      Paul Walmsley 提交于
      Static data should be declared in .c files, not .h files.  It should be
      possible to #include .h files at any point without creating multiple
      copies of the same data.
      
      We converted the clock data to .c files some time ago.  This patch does
      the same for the powerdomain data.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      6e01478a
    • R
      OMAP: powerdomain: Move static allocations from powerdomains.h to a .c file · 74bea6b9
      Rajendra Nayak 提交于
      powerdomains.h header today has only static definitions.  Adding any
      function declarations into it and including it in multiple source file
      is expected to cause issues.  Hence move all the static definitions
      from powerdomains.h file into powerdomains_data.c file.
      
      Also, create a new powerdomain section of the mach-omap2/Makefile, and
      rearrange the prcm-common part of the Makefile, now that the
      powerdomain code is in its own Makefile section.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: rearrange Makefile changes, tweaked commit message]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      74bea6b9
    • P
      OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism · ff2516fb
      Paul Walmsley 提交于
      The OMAP watchdog timer IP blocks require a specific set of register
      writes to occur before they will be disabled[1], even if the device
      clocks appear to be disabled in the CM_*CLKEN registers.  In the MPU
      watchdog case, failure to execute this reset sequence will eventually
      cause the watchdog to reset the OMAP unexpectedly.
      
      Previously, the code to disable this watchdog was manually called from
      mach-omap2/devices.c during device initialization.  This causes the
      watchdog to be unconditionally disabled for a portion of kernel
      initialization.  This should be controllable by the board-*.c files,
      since some system integrators will want full watchdog coverage of
      kernel initialization.  Also, the watchdog disable code was not
      connected to the hwmod shutdown code.  This means that calling
      omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the
      goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip
      OMAP device.
      
      To resolve the latter problem, populate the pre_shutdown pointer in
      the watchdog timer hwmod classes with a function that executes the
      watchdog shutdown sequence.  This allows the hwmod code to fully
      disable the watchdog.
      
      Then, to allow some board files to support watchdog coverage
      throughout kernel initialization, add common code to mach-omap2/io.c
      to cause the MPU watchdog to be disabled on boot unless a board file
      specifically requests it to remain enabled.  Board files can do this
      by changing the watchdog timer hwmod's postsetup state between the
      omap2_init_common_infrastructure() and omap2_init_common_devices()
      function calls.
      
      1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH
         [SWPU222H], Section 16.4.3.6, "Start/Stop Sequence for WDTs (Using
         WDTi.WSPR Register)"
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      ff2516fb
    • P
      OMAP2+: hwmod: add postsetup state · 2092e5cc
      Paul Walmsley 提交于
      Allow board files and OMAP core code to control the state that some or
      all of the hwmods end up in at the end of _setup() (called by
      omap_hwmod_late_init() ).  Reimplement the old skip_setup_idle code in
      terms of this new postsetup state code.
      
      There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
      in which all IP blocks should stay enabled after _setup() finishes;
      and the MPU watchdog case, in which the watchdog IP block should enter
      idle if watchdog coverage of kernel initialization is desired, and
      should be disabled otherwise.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      2092e5cc
    • 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
    • K
      OMAP3: remove OPP interfaces from OMAP PM layer · 53da4ce2
      Kevin Hilman 提交于
      With new OPP layer, OPP users will access OPP API directly instead of
      using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
      layer.
      Acked-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      53da4ce2
  18. 15 12月, 2010 1 次提交
  19. 11 12月, 2010 2 次提交
  20. 08 12月, 2010 1 次提交
  21. 09 10月, 2010 1 次提交
    • M
      OMAP: plat-omap: Fix static function warnings · b0a330dc
      Manjunath Kondaiah G 提交于
      This patch fixes sparse warnings due non declarations of static functions.
      
      arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static?
      arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be static
      
      arch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static?
      arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static?
      
      arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static?
      arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static?
      arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' 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>
      b0a330dc
  22. 24 9月, 2010 1 次提交
    • B
      OMAP4: hwmod: Add initial data for OMAP4430 ES1 & ES2 · 55d2cb08
      Benoit Cousson 提交于
      The current version contains only the interconnects and the
      mpu hwmods.
      The remaining hwmods will be introduced by further patches on
      top of this one.
      
      - enable as well omap_hwmod.c build for OMAP4 Soc
      
      Please not that this file uses the new naming convention for
      naming HW IPs. This convention will be backported soon for previous
      OMAP2 & 3 data files.
      
      new name        trm name
      -------------   -------------------
      counter_32k     synctimer_32k
      l3_main         l3
      timerX          gptimerX / dmtimerX
      mmcX            mmchsX / sdmmcX
      dma_system      sdma
      smartreflex_X   sr_X / sr?
      usb_host_fs     usbfshost
      usb_otg_hs      hsusbotg
      usb_tll_hs      usbtllhs_config
      wd_timerX       wdtimerX
      ipu             cortexm3 / ducati
      dsp             c6x / tesla
      iva             ivahd / iva2.2
      kbd             kbdocp / keyboard
      mailbox         system_mailbox
      mpu             cortexa9 / chiron
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      55d2cb08
  23. 27 7月, 2010 1 次提交
    • K
      OMAP: PM: create omap_devices for MPU, DSP, L3 · 6f88e9bc
      Kevin Hilman 提交于
      Create simple omap_devices for the main processors and busses.
      
      This is required to support the forth-coming device-based OPP
      approach, where OPPs are managed and tracked at the device level.
      
      Also, move these common PM init functions into a common_pm_init call
      that is called as a device_initcall().  The PM init is done at this level
      to ensure that the driver core is initialized before initialized.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: sparse warnings cleaned up; newly-created functions moved
       from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed
       to start with "omap2" rather than "omap"]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6f88e9bc