1. 22 12月, 2010 27 次提交
    • K
      OMAP: PM noop: implement context loss count for non-omap_devices · 6081dc34
      Kevin Hilman 提交于
      For devices which have not (yet) been converted to use omap_device,
      implement the context loss counter using the "brutal method" as
      originally proposed by Paul Walmsley[1].
      
      The dummy context loss counter is incremented every time it is
      checked, but only when off-mode is enabled.  When off-mode is
      disabled, the dummy counter stops incrementing.
      
      Tested on 36xx/Zoom3 using MMC driver, which is currently the
      only in-tree user of this API.
      
      This patch should be reverted after all devices are converted to using
      omap_device.
      
      [1] http://marc.info/?l=linux-omap&m=129176260000626&w=2Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      [paul@pwsan.com: fixed compile warning; fixed to compile on OMAP1]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6081dc34
    • K
      OMAP: PM: implement context loss count APIs · c80705aa
      Kevin Hilman 提交于
      Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by
      creating similar APIs at the omap_device and omap_hwmod levels.  The
      omap_hwmod level call is the layer with access to the powerdomain
      core, so it is the place where the powerdomain is queried to get the
      context loss count.
      
      The new APIs return an unsigned value that can wrap as the
      context-loss count grows.  However, the wrapping is not important as
      the role of this function is to determine context loss by checking for
      any difference in subsequent calls to this function.
      
      Note that these APIs at each level can return zero when no context
      loss is detected, or on errors.  This is to avoid returning error
      codes which could potentially be mistaken for large context loss
      counters.
      
      NOTE: only works for devices which have been converted to use
            omap_device/omap_hwmod.
      
      Longer term, we could possibly remove this API from the OMAP PM layer,
      and instead directly use the omap_device level API.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c80705aa
    • J
      OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4 · a36795c1
      Jon Hunter 提交于
      J-Type DPLLs have additional configuration parameters that need to
      be programmed when setting the multipler and divider for the DPLL.
      These parameters being the sigma delta divider (SD_DIV) for the DPLL
      and the digital controlled oscillator (DCO) to be used by the DPLL.
      
      The current code is implemented specifically to configure the
      OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL
      and so this code needs to be updated to work for both OMAP3 and OMAP4
      devices and any other future devices that have J-TYPE DPLLs.
      
      For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are
      used but for the OMAP4430 USB DPLL only the SD_DIV field is used.
      The current implementation will only program the SD_DIV and DCO
      fields if the DPLL has both and hence this does not work for
      OMAP4430.
      
      In order to make the code more generic add two new fields to the
      dpll_data structure for the SD_DIV field and DCO field bit-masks
      and only program these fields if the masks are defined for a specific
      DPLL. This simplifies the code and allows us to remove the flag
      DPLL_NO_DCO_SEL.
      
      Tested on OMAP36xx Zoom3 and OMAP4 Blaze.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      [paul@pwsan.com: removed explicit inlining and added '_' prefix on lookup_*()
       functions; added testing info to commit message; added 35xx comments back in]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a36795c1
    • B
      OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs · 86009eb3
      Benoit Cousson 提交于
      The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup.
      
      This new idlemode replaces the enawakeup for the new IPs but seems to
      coexist as well for some legacy IPs (UART, GPIO, MCSPI...)
      
      Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this
      capability.
      The omap_hwmod_44xx_data.c will have to be updated to add this new flag.
      
      Enable this new mode when applicable in _enable_wakeup, _enable_sysc and
      _idle_sysc.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Tested-by: NSebastien Guiriec <s-guiriec@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      86009eb3
    • B
      OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister · 0102b627
      Benoit Cousson 提交于
      Do not allow omap_hwmod_register to be used outside the core
      hwmod code. An omap_hwmod should be registered only at init time.
      Remove the omap_hwmod_unregister that is not used today since the
      hwmod list will be built once at init time and never be modified
      at runtime.
      Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      0102b627
    • P
      OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu · 553d239a
      Paul Walmsley 提交于
      Clarify the usage of the struct omap_clk.cpu flags (e.g., CK_*) to use
      bits only for individual SoC variants (e.g., CK_3430ES1, CK_3505,
      etc.).  Superset flags, such as CK_3XXX or CK_AM35XX, are now defined
      as disjunctions of individual SoC variant flags.  This simplifies the
      definition and use of these flags.  struct omap_clk record definitions
      can now simply specify the bitmask of actual SoCs that the records are
      valid for.  The clock init code can simply set a single CPU type mask
      bit for the SoC that is currently in use, and test against that,
      rather than needing to set some combination of flags.
      
      Similarly, clarify the use of struct clksel_rate.flags.  The bit
      allocated for RATE_IN_3XXX has been reassigned, and RATE_IN_3XXX has
      been defined as a disjunction of the 34xx and 36xx rate flags.  The
      advantages are the same as the above.
      
      Clarify the usage of struct omap_clk.cpu flags such as CK_34XX to only
      apply to the SoCs that they name, e.g., OMAP34xx chips.  The previous
      practice caused significantly different SoCs, such as OMAP36xx, to be
      included in CK_34XX.  In my opinion, this is much more intuitive.
      
      Similarly, clarify the use of struct clksel_rate.flags, such that
      RATE_IN_3430ES2PLUS now only applies to 34xx chips with ES level >= 2
      - it does not apply to OMAP36xx.
      
      ...
      
      At some point, it probably makes sense to collapse the CK_* and
      RATE_IN_* flags together into a single bitfield, and possibly use the
      existing CHIP_IS_OMAP* flags for platform detection.
      
      ...
      
      This all seems to work fine on OMAP34xx and OMAP36xx Beagle.  Not sure
      if it works on Sitara or the TI816X, unfortunately I don't have any
      here to test with.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      553d239a
    • P
      OMAP3: control/PM: move padconf save code to mach-omap2/control.c · 596efe47
      Paul Walmsley 提交于
      Move the padconf save code from pm34xx.c to the System Control Module
      code in mach-omap2/control.c.  This is part of the general push to
      move direct register access from middle-layer core code to low-level
      core code, so the middle-layer code can be abstracted to work on
      multiple platforms and cleaned up.
      
      In the medium-to-long term, this code should be called by the mux
      layer code, not the PM idle code.  This is because, according to the
      TRM, saving the padconf only needs to be done when the padconf
      changes[1].
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      
      1. OMAP34xx Multimedia Device Silicon Revision 3.1.x [Rev. ZH] [SWPU222H]
         Section 4.11.4 "Device Off-Mode Sequences"
      596efe47
    • 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/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM register accesses · 55ae3507
      Paul Walmsley 提交于
      Reverse some of the effects of commit
      84c0c39a ("ARM: OMAP4: PM: Make OMAP3
      Clock-domain framework compatible for OMAP4").  On OMAP2/3, the
      CM_CLKSTCTRL register is at a constant offset from the powerdomain's
      CM instance.
      
      Also, remove some of the direct CM register access from the
      clockdomain code, moving it to the OMAP2/3 CM code instead.  The
      intention here is to simplify the clockdomain code.  (The long-term
      goal is to move all direct CM register access across the OMAP core
      code to the appropriate cm*.c file.)
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      55ae3507
    • P
      OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support · bd2122ca
      Paul Walmsley 提交于
      Add PRCM partition, CM instance register address offset, and clockdomain
      register address offset to each OMAP4 struct clockdomain record.  Add OMAP4
      clockdomain code to use this new data to access registers properly.
      
      While here, clean up some nearby clockdomain code to allocate auto variables
      in my recollection of Linus's preferred style.
      
      The autogeneration scripts have been updated.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      bd2122ca
    • P
      OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions · a64bb9cd
      Paul Walmsley 提交于
      OMAP4 powerdomain control registers are split between the PRM hardware
      module and the PRCM_MPU local PRCM.  Add this PRCM partition
      information to each OMAP4 powerdomain record, and convert the OMAP4
      powerdomain function implementations to use the OMAP4 PRM instance
      functions.
      
      Also fixes a potential null pointer dereference of pwrdm->name.
      
      The autogeneration scripts have been updated.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      a64bb9cd
    • P
      OMAP4: PRCM: add OMAP4-specific accessor/mutator functions · 2ace831f
      Paul Walmsley 提交于
      In some ways, the OMAP4 PRCM register layout is quite different than
      the OMAP2/3 PRCM register layout.  For example, on OMAP2/3, from a
      register layout point of view, all CM instances were located in the CM
      subsystem, and all PRM instances were located in the PRM subsystem.
      OMAP4 changes this.  Now, for example, some CM instances, such as
      WKUP_CM and EMU_CM, are located in the system PRM subsystem.  And a
      "local PRCM" exists for the MPU - this PRCM combines registers that
      would normally appear in both CM and PRM instances, but uses its own
      register layout which matches neither the OMAP2/3 PRCM layout nor the
      OMAP4 PRCM layout.
      
      To try to deal with this, introduce some new functions, omap4_cminst*
      and omap4_prminst*.  The former is to be used when writing to a CM
      instance register (no matter what subsystem or hardware module it
      exists in), and the latter, similarly, with PRM instance registers.
      To determine which "PRCM partition" to write to, the functions take a
      PRCM instance ID argument.  Subsequent patches add these partition IDs
      to the OMAP4 powerdomain and clockdomain definitions.
      
      As far as I can see, there's really no good way to handle these types
      of register access inconsistencies.  This patch seemed like the least
      bad approach.
      
      Moving forward, the long-term goal is to remove all direct PRCM
      register access from the PM code.  PRCM register access should go
      through layers such as the powerdomain and clockdomain code that can
      hide the details of how to interact with the specific hardware
      variant.
      
      While here, rename cm4xxx.c to cm44xx.c to match the naming convention
      of the other OMAP4 PRCM files.
      
      Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak
      <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      2ace831f
    • P
      OMAP3: PRM/CM: separate CM context save/restore; remove PRM context save/restore · f0611a5c
      Paul Walmsley 提交于
      The OMAP3 PRM module is in the WKUP powerdomain, which is always
      powered when the chip is powered, so it shouldn't be necessary to save
      and restore those PRM registers.  Remove the PRM register save/restore
      code, which should save several microseconds during off-mode
      entry/exit, since PRM register accesses are relatively slow.
      
      While doing so, move the CM register save/restore code into
      CM-specific code.  The CM module has been distinct from the PRM module
      since 2430.
      
      This patch includes some minor changes to pm34xx.c.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Tero Kristo <tero.kristo@nokia.com>
      Cc: Kalle Jokiniemi <kalle.jokiniemi@digia.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>
      f0611a5c
    • P
      OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files · 59fb659b
      Paul Walmsley 提交于
      In preparation for adding OMAP4-specific PRCM accessor/mutator
      functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
      files.  Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
      moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
      OMAP2xxx/3xxx-specific.
      
      This process also requires the #includes in each of these files to be
      changed to reference the new file name.  As part of doing so, add some
      comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
      "sideways includes", to indicate that these users of the PRM/CM includes
      should not be doing so.
      
      Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this
      patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Jarkko Nikula <jhnikula@gmail.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Cc: Liam Girdwood <lrg@slimlogic.co.uk>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Acked-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      59fb659b
    • 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: Infrastructure to put arch specific code · 3b1e8b21
      Rajendra Nayak 提交于
      Put infrastructure in place, so arch specific func pointers
      can be hooked up to the platform-independent part of the
      framework.
      This is in preparation of splitting the powerdomain framework into
      platform-independent part (for all omaps) and platform-specific
      parts.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.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>
      3b1e8b21
    • 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+: hwmod: fix a warning, add some docs, remove unused fields · b56b7bc8
      Paul Walmsley 提交于
      Trivial cleanup and documentation changes on the hwmod code and data:
      
      - add some hwmod documentation to indicate flags that should be moved
        outside the static hwmod data in a future patch
      
      - remove some unused fields in the struct omap_hwmod_ocp_if and
        struct omap_hwmod structures
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      b56b7bc8
    • P
      OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock · dc6d1cda
      Paul Walmsley 提交于
      Change the per-hwmod mutex to a spinlock.  (The per-hwmod lock
      serializes most post-initialization hwmod operations such as enable,
      idle, and shutdown.)  Spinlocks are needed, because in some cases,
      hwmods must be enabled from timer interrupt disabled-context, such as
      an ISR.  The current use-case that is driving this is the OMAP GPIO
      block ISR: it can trigger interrupts even with its clocks disabled,
      but these clocks are needed for register accesses in the ISR to succeed.
      
      This patch also effectively reverts commit
      84824022 - this patch makes
      _omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
      to _enable() and _idle(), and changes their callers to call the
      spinlocking versions.  Previously, since omap_hwmod_{enable,init}()
      attempted to take mutexes, these functions could not be called while
      the timer interrupt was disabled; but now that the functions use
      spinlocks and save and restore the IRQ state, it is appropriate to
      call them directly.
      
      Kevin Hilman <khilman@deeprootsystems.com> originally proposed this
      patch - thanks Kevin.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      dc6d1cda
    • P
      OMAP2+: hwmod: add support for per-class custom device reset functions · bd36179e
      Paul Walmsley 提交于
      The standard omap_hwmod.c _reset() code relies on an IP block's
      OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block.  This
      works for most IP blocks on the chip, but unfortunately not all.  For
      example, initiator-only IP blocks often don't have any MPU-accessible
      OCP-header registers, and therefore the MPU can't write to any
      OCP_SYSCONFIG registers in that block.  Other IP blocks, such as the
      IVA and I2C, require a specialized reset sequence.
      
      Since we need to be able to reset these IP blocks as well, allow
      custom IP block reset functions to be passed into the hwmod code via a
      per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
      If .reset is non-null, then the hwmod _reset() code will call the custom
      function instead of the standard OCP SOFTRESET-based code.
      
      As part of this change, rename most of the existing _reset() function
      code to _ocp_softreset(), to indicate more clearly that it does not work
      for all cases.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Paul Hunt <hunt@ti.com>
      Cc: Stanley Liu <stanley_liu@ti.com>
      bd36179e
    • 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+: hwmod: allow custom pre-shutdown functions · e4dc8f50
      Paul Walmsley 提交于
      Some OMAP IP blocks, such as the watchdog timers, cannot be completely
      shut down via the standard hwmod shutdown mechanism.  This patch
      enables the hwmod data files to supply a pointer to a custom
      pre-shutdown function via the struct omap_hwmod_class.pre_shutdown
      function pointer.  If the struct omap_hwmod_class.pre_shutdown
      function pointer is non-null, the function will be executed before the
      existing hwmod shutdown code runs.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      e4dc8f50
    • 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
    • J
      OMAP2+: use global values for the SRAM PA addresses · b4b36fd9
      Jean Pihet 提交于
      The SRAM PA addresses are locally defined and used at
      different places, i.e. SRAM management code and idle sleep code.
      
      The macros are now defined at a centralized place, for
      easier maintenance.
      
      Tested on N900 and Beagleboard with full RET and OFF modes,
      using cpuidle and suspend.
      Signed-off-by: NJean Pihet <j-pihet@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: Nishanth Menon<nm@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b4b36fd9
    • 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
  2. 21 12月, 2010 7 次提交
  3. 18 12月, 2010 1 次提交
  4. 16 12月, 2010 1 次提交
  5. 10 12月, 2010 1 次提交
  6. 08 12月, 2010 3 次提交
    • R
      ARM: io: make iounmap() a simple macro · a0b7bd08
      Russell King 提交于
      Defining iounmap() with arguments prevents it from being used as a
      function pointer, causing platforms to work around this.  Instead,
      define it to be a simple macro.
      
      Do the same for __arch_io(re|un)map too.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a0b7bd08
    • T
      omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xx · 5de62b86
      Tony Lindgren 提交于
      We need to divide the 15xx/16xx offset by 2 for 7xx. Use bank->stride
      for that. This allows us to get rid of the duplicate defines for the
      MPUIO registers.
      
      Note that this will cause omap-keypad.c driver to not work on 7xx.
      However, the right fix there is to move over to matrix_keypad instead
      as suggested by Cory Maccarrone <darkstar6262@gmail.com> and
      Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>.
      
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Acked-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      5de62b86
    • 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