1. 25 2月, 2012 2 次提交
    • T
      ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers · acea7c7b
      Tony Lindgren 提交于
      Drivers should no longer use omap_read/write functions
      but instead use ioremap + read/write functions.
      
      As some USB legacy code is still shared between omap1 and
      omap2420, let's limit the omap_read/write to plat/usb.h.
      
      Note that the long term fix is to update the drivers to
      use ioremap and read/write functions. That can now be
      done as a separate patch series that is limited to the
      USB drivers.
      
      Also make sure the legacy omap1-keypad.c driver builds
      if selected for 2420 based systems.
      
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      acea7c7b
    • T
      ARM: OMAP2+: Move most of plat/io.h into local iomap.h · ee0839c2
      Tony Lindgren 提交于
      There's no need to have these defines in plat/io.h.
      
      Note that we now need to ifdef omap_read/write calls
      as they will be available for omap1 only.
      
      While at it, clean up the includes to group them like
      they typically are grouped.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ee0839c2
  2. 26 1月, 2012 1 次提交
    • P
      ARM: OMAP2+: io: fix compilation breakage on 2420-only configs · 16110798
      Paul Walmsley 提交于
      Commit 7b250aff ("ARM: OMAP: Avoid
      cpu_is_omapxxxx usage until map_io is done") breaks the build on a
      2420-only config on v3.3-rc1:
      
      arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
      arch/arm/mach-omap2/io.c:406: undefined reference to `omap2_set_globals_243x'
      arch/arm/mach-omap2/io.c:410: undefined reference to `omap243x_clockdomains_init'
      arch/arm/mach-omap2/io.c:411: undefined reference to `omap2430_hwmod_init'
      
      Fix by only compiling omap2420_init_early() when CONFIG_SOC_OMAP2420
      is selected, and only compiling omap2430_init_early() when
      CONFIG_SOC_OMAP2430 is selected.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      16110798
  3. 14 12月, 2011 2 次提交
  4. 09 12月, 2011 1 次提交
    • S
      ARM: OMAP4: Fix errata i688 with MPU interconnect barriers. · 137d105d
      Santosh Shilimkar 提交于
      On OMAP4 SOC, intecronnects has many write buffers in the async bridges
      and they need to be drained before CPU enters into standby state.
      
      Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support
      but OMAP errata i688 (Async Bridge Corruption) needs to be taken
      care to avoid issues like system freeze, CPU deadlocks, random
      crashes with register accesses, synchronisation loss on initiators
      operating on both interconnect port simultaneously.
      
      As per the errata, if a data is stalled inside asynchronous bridge
      because of back pressure, it may be accepted multiple times, creating
      pointer misalignment that will corrupt next transfers on that data
      path until next reset of the system (No recovery procedure once
      the issue is hit, the path remains consistently broken).
      Async bridge can be found on path between MPU to EMIF and
      MPU to L3 interconnect. This situation can happen only when the
      idle is initiated by a Master Request Disconnection (which is
      trigged by software when executing WFI on CPU).
      
      The work-around for this errata needs all the initiators
      connected through async bridge must ensure that data path
      is properly drained before issuing WFI. This condition will be
      met if one Strongly ordered access is performed to the
      target right before executing the WFI. In MPU case, L3 T2ASYNC
      FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure
      that there is no synchronisation loss on initiators operating
      on both interconnect port simultaneously.
      
      Thanks to Russell for a tip to conver assembly function to
      C fuction there by reducing 40 odd lines of code from the patch.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
      Acked-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      137d105d
  5. 19 11月, 2011 1 次提交
  6. 18 11月, 2011 1 次提交
  7. 16 11月, 2011 1 次提交
  8. 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
  9. 20 10月, 2011 4 次提交
  10. 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
  11. 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
  12. 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
  13. 22 8月, 2011 1 次提交
  14. 16 6月, 2011 1 次提交
  15. 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
  16. 18 2月, 2011 1 次提交
  17. 17 2月, 2011 1 次提交
  18. 15 2月, 2011 2 次提交
  19. 28 1月, 2011 2 次提交
  20. 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
  21. 15 12月, 2010 1 次提交
  22. 11 12月, 2010 1 次提交