1. 01 4月, 2015 1 次提交
  2. 27 3月, 2015 2 次提交
  3. 25 3月, 2015 3 次提交
  4. 31 1月, 2015 1 次提交
  5. 27 10月, 2014 6 次提交
  6. 16 5月, 2014 2 次提交
  7. 18 1月, 2014 1 次提交
  8. 22 11月, 2012 1 次提交
    • R
      ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count · e6d3a8b0
      Rajendra Nayak 提交于
      OMAP4 has module specific context lost registers which makes it now
      possible to have module level context loss count, instead of relying
      on the powerdomain level context count.
      
      Add 2 private hwmod api's to update/clear the hwmod/module specific
      context lost counters/register.
      
      Update the module specific context_lost_counter and clear the hardware
      bits just after enabling the module.
      
      omap_hwmod_get_context_loss_count() now returns the hwmod context loss
      count them on platforms where they exist (OMAP4), else fall back on
      the pwrdm level counters for older platforms.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
       rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
       prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
       and clear, merged patches]
      [t-kristo@ti.com: added support for arch specific hwmod ops, and changed
       the no context offset indicator to USHRT_MAX]
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      [paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
       convert unsigned context lost counter to int to match the return type;
       get rid of hwmod_ops in favor of the existing soc_ops mechanism;
       move context loss low-level accesses to the PRM code]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e6d3a8b0
  9. 09 11月, 2012 2 次提交
  10. 21 10月, 2012 2 次提交
    • P
      ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver · 2bb2a5d3
      Paul Walmsley 提交于
      The OMAP watchdog timer driver needs to determine what caused the SoC
      to reset for its GETBOOTSTATUS ioctl.  So, define a set of standard
      reset sources across OMAP SoCs.  For OMAP2xxx, 3xxx, and 4xxx SoCs,
      define mappings from the SoC-specific reset source register bits to
      the standardized reset source IDs.  Create SoC-specific PRM functions
      that read the appropriate per-SoC register and use the mapping to
      return the standardized reset bits.  Register the SoC-specific PRM
      functions with the common PRM code via prm_register().  Create a
      function in the common PRM code, prm_read_reset_sources(), that
      calls the SoC-specific function, registered during boot.
      
      This patch does not yet handle some SoCs, such as AM33xx.  Those SoCs
      were not handled by the code this will replace.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      2bb2a5d3
    • P
      ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers · e24c3573
      Paul Walmsley 提交于
      There are several PRM operations which behave similarly across OMAP2+
      SoCs, but which have slight differences in their underlying
      implementations.  For example, to fetch the SoC's last reset sources,
      different registers are read across OMAP2xxx, 3xxx, and 44xx, and
      different bits are used on each SoC.  But the information returned is
      so similar that a single, common interface for drivers is useful.
      
      This patch creates the support code for this function pointer
      registration process.  No function pointers are included yet, but a
      subsequent patch will create one for the reset source API.
      
      To illustrate the end goal with the above reset source example, each
      per-SoC driver will use its own low-level implementation function --
      e.g., prm2xxx.c would contain omap2xxx_prm_read_reset_sources().  This
      function would read the appropriate register and remap the register
      bits to a standard set of reset source bits.  When the prm2xxx.c
      driver is loaded, it would register this function with the common PRM
      driver, prm.c.  prm.c would then export a common function,
      omap_prm_read_reset_sources().  Calling it would call through to the
      function pointer for the currently-registered SoC PRM driver.  This
      will allow other drivers to use PRM-provided data and operations
      without needing to know which SoC is currently in use.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      e24c3573
  11. 22 12月, 2010 2 次提交
  12. 22 9月, 2010 2 次提交
    • P
      OMAP2/3: PRM: add module hard reset support · cf21405f
      Paul Walmsley 提交于
      This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
      on OMAP2/3 platforms.  It's based on the OMAP4 hard-reset support that Benoît
      developed in the previous patch.
      
      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>
      Cc: Benoît Cousson <b-cousson@ti.com>
      cf21405f
    • 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
  13. 21 5月, 2010 2 次提交
  14. 27 1月, 2010 1 次提交
  15. 21 1月, 2010 1 次提交
  16. 12 12月, 2009 1 次提交
  17. 20 10月, 2009 1 次提交
  18. 29 8月, 2009 1 次提交
  19. 29 5月, 2009 1 次提交
  20. 26 5月, 2009 2 次提交
  21. 09 2月, 2009 1 次提交
  22. 06 9月, 2008 1 次提交
    • R
      [ARM] omap: Fix IO_ADDRESS() macros · e8a91c95
      Russell King 提交于
      OMAP1_IO_ADDRESS(), OMAP2_IO_ADDRESS() and IO_ADDRESS() returns cookies
      for use with __raw_{read|write}* for accessing registers.  Therefore,
      these macros should return (void __iomem *) cookies, not integer values.
      
      Doing this improves typechecking, and means we can find those places
      where, eg, DMA controllers are incorrectly given virtual addresses to
      DMA to, or physical addresses are thrown through a virtual to physical
      address translation.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e8a91c95
  23. 19 8月, 2008 1 次提交
  24. 03 7月, 2008 2 次提交