1. 21 10月, 2012 1 次提交
  2. 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
  3. 22 6月, 2012 2 次提交
    • T
      ARM: OMAP3+: PRM: Enable IO wake up · 8a680ea2
      Tero Kristo 提交于
      Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
      managed in cpuidle path which is not the right place. Subsequent patch
      will remove IO Daisy chain handling in cpuidle path once daisy chain is
      handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
      enable code from the trigger function to init time setup.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Reviewed-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: harmonize function names with other PRM functions; add
       kerneldoc; resolve checkpatch warnings]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      8a680ea2
    • R
      ARM: OMAP4: PRM: Add IO Daisychain support · dea6200b
      Rajendra Nayak 提交于
      IO daisychain is a mechanism that allows individual IO pads to generate
      wakeup events on their own based on a switch of an input signal level.
      This allows the hardware module behind the pad to be powered down, but
      still have device level capability to detect IO events, and once this
      happens the module can be powered back up to resume IO. See section
      3.9.4 in OMAP4430 Public TRM for details.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: use the shared MAX_IOPAD_LATCH_TIME declaration; renamed
       omap4_trigger_io_chain() to conform to other PRM function names;
       added kerneldoc; resolved checkpatch warnings]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      dea6200b
  4. 12 3月, 2012 1 次提交
  5. 25 2月, 2012 1 次提交
  6. 13 2月, 2012 1 次提交
  7. 17 12月, 2011 3 次提交
    • T
      ARM: OMAP4: PRM: use PRCM interrupt handler · 2f31b516
      Tero Kristo 提交于
      Use the new PRCM interrupt handler code on OMAP4 systems.
      
      The OMAP code will need to be converted to use sparse IRQs for this
      to work.  Until that time, the following message will appear on boot:
      
      PRCM: failed to allocate irq descs: -12
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      [paul@pwsan.com: split this from a previous patch to this patch; call
       omap4xxx_prcm_init() during init; write trivial commit log]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      2f31b516
    • T
      ARM: OMAP: PRCM: add suspend prepare / finish support · 91285b6f
      Tero Kristo 提交于
      PRCM chain handler needs to disable forwarding of interrupts during
      suspend, because runtime PM is disabled and most of the drivers
      are potentially not able to handle interrupts coming at this time.
      
      This patch masks all the PRCM interrupt events if a PRCM interrupt
      occurs during suspend, but does not ack them. Once suspend finish
      is called, all the masked events will be re-enabled, which causes
      immediate PRCM interrupt and handles the postponed event.
      
      The suspend prepare and complete  callbacks will be called from
      pm34xx.c / pm44xx.c files in the following patches.
      
      The functions defined in this patch should eventually be moved to
      suspend->prepare and suspend->finish driver hooks, once the PRCM
      chain handler will be made as its own driver.
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      [paul@pwsan.com: add kerneldoc, add omap_prcm_irq_setup.saved_mask, add fn
       ptrs for save_and_clear_irqen() and restore_irqen()]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      91285b6f
    • P
      ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrier · 26c98c56
      Paul Walmsley 提交于
      Add PRM functions to test for pending PRM IRQs.  This will be used in
      a subsequent patch to implement the PRM interrupt handler on the MPU.
      
      Add PRM functions to ensure that all outstanding writes from the MPU
      to the PRM IP block have completed before continuing execution.  This
      will be used in a subsequent patch to ensure that all PRM interrupt
      status bits are cleared in the hardware before exiting the ISR.
      Normally we would not expose such a low-level function to other code.
      But the current implementation of the PRM interrupt code, which uses
      the generic IRQ chip code, doesn't give us a choice.
      
      The pending PRM IRQ functions are based on code originally written by
      Tero Kristo <t-kristo@ti.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      26c98c56
  8. 18 11月, 2011 1 次提交
  9. 16 9月, 2011 2 次提交
  10. 10 7月, 2011 3 次提交
  11. 22 12月, 2010 3 次提交
    • P
      OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file · dac9a771
      Paul Walmsley 提交于
      Move the OMAP4 global software reset function to the OMAP4-specific
      prm44xx.c file, where it belongs.  Part of the long-term process of
      moving all of the direct PRCM register writes into lower-layer code.
      
      Also add OCP barriers on OMAP2/3/4 to reduce the chance that the MPU
      will continue executing while the system is supposed to be resetting
      itself.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NRajendra Nayak <rnayak@ti.com>
      dac9a771
    • 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
      OMAP4: PRCM: reorganize existing OMAP4 PRCM header files · d198b514
      Paul Walmsley 提交于
      Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files
      so they match their underlying OMAP hardware modules.  Add clockdomain
      offset information.
      
      Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the
      SCRM, scrm44xx.h.  SCRM register offsets still need to be added; TI
      should do this.
      
      Move the "_MOD" macros out of the prcm-common.h header file, into the
      header file of the hardware module that they belong to.  For example,
      OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header.
      
      Adjust #includes of all files that used the old PRCM header file names
      to point to the new filenames.
      
      The autogeneration scripts have been updated accordingly.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.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>
      d198b514
  12. 22 9月, 2010 1 次提交
    • B
      OMAP4: PRM: add module hard reset support · 0be1621a
      Benoît Cousson 提交于
      Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
      under the control of the PRM.  This patch adds an API for this purpose
      for OMAP4 devices:
      
      int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
      int omap4_prm_assert_hardreset(void __iomem *rstctrl_reg, u8 shift);
      int omap4_prm_deassert_hardreset(void __iomem *rstctrl_reg, u8 shift);
      
      This API is intended to be used only by the hwmod code - a subsequent
      patch will add that support to hwmod.
      
      This patch is a collaboration between Benoît Cousson <b-cousson@ti.com>
      and Paul Walmsley <paul@pwsan.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NBenoît Cousson <b-cousson@ti.com>
      Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
      0be1621a