1. 09 11月, 2012 14 次提交
  2. 30 10月, 2012 2 次提交
    • P
      ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer · 37c67d03
      Paul Walmsley 提交于
      The OMAP watchdog timer driver directly calls a function exported by
      code in arch/arm/mach-omap2.  This is not good; it tightly couples
      this driver to the mach-omap2 integration code.  Instead, add a
      temporary platform_data function pointer to abstract this function
      call.  A subsequent patch will convert the watchdog driver to use this
      function pointer.
      
      This patch also moves the device creation code out of
      arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c.
      This is another step towards the removal of
      arch/arm/mach-omap2/devices.c.
      
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Acked-by: NWim Van Sebroeck <wim@iguana.be>
      [paul@pwsan.com: skip wd_timer device creation when DT blob is present]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      37c67d03
    • P
      ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type · 508c0d47
      Paul Walmsley 提交于
      An older version of the patch "ARM: OMAP1: create read_reset_sources()
      function (for initial use by watchdog)" was sent upstream, which used
      the wrong return type for the omap1_get_reset_sources() function.
      Fix it to return a u32, which is what the WDTIMER platform_data
      function pointer read_reset_sources() expects.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      508c0d47
  3. 27 10月, 2012 2 次提交
  4. 25 10月, 2012 5 次提交
  5. 21 10月, 2012 9 次提交
    • 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: OMAP1: create read_reset_sources() function (for initial use by watchdog) · b5c5353d
      Paul Walmsley 提交于
      On OMAP1, the existing OMAP watchdog driver reads a register directly
      from a non-watchdog IP block.  It also does not convert the register's
      contents into the standard WDIOF_* bits expected from the
      GETBOOTSTATUS ioctl().
      
      To move towards fixing these problems, create an function in
      arch/arm/mach-omap1 to return the reset source data.  A subsequent
      patch will provide this function to the watchdog driver via
      platform_data.
      
      In the long term, the best approach would be to move this function
      to a new OMAP1 driver that handles access to the OMAP1 Clock
      Generation and Reset Management IP block.  Then no platform_data would
      be needed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b5c5353d
    • P
      ARM: OMAP2+: CM: prepare for use of cm_ll_data function pointers · 21325b25
      Paul Walmsley 提交于
      There are several CM operations which behave similarly across OMAP2+
      SoCs, but which have slight differences in their underlying
      implementations.
      
      This patch creates the support code for this function pointer
      registration process.  No function pointers are included yet, but a
      subsequent patch will create these for the module IDLEST registers.
      
      This patch allows other code to use CM-provided data and operations
      without needing to know which SoC is currently in use.  A further
      description of the concept is provided in the patch entitled
      "ARM: OMAP2+: PRM: prepare for use of prm_ll_data function pointers".
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      21325b25
    • 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
    • P
      ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions into PRM/CM · 4bd5259e
      Paul Walmsley 提交于
      Move the low-level SoC-specific clockdomain control functions into
      cm*.c and prm*.c.  For example, OMAP2xxx low-level clockdomain
      functions go into cm2xxx.c.  Then remove the unnecessary
      clockdomain*xxx*.c files.
      
      The objective is to centralize low-level CM and PRM register accesses
      into the cm*.[ch] and prm*.[ch] files, and then to export an OMAP
      SoC-independent API to higher-level OMAP power management code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Acked-by: NRajendra Nayak <rnayak@ti.com>
      Reviewed-by: NRuss Dill <Russ.Dill@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      4bd5259e
    • P
      ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files · ff4ae5d9
      Paul Walmsley 提交于
      Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and
      OMAP2xxx-specific macros into cm2xxx.[ch].  Move basic CM register
      access functions into static inline functions in cm2xxx_3xxx.h,
      leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c.
      
      As part of this, split the CM and hwmod code that waits for devices to
      become ready into SoC-specific functions.
      
      This is in preparation for the upcoming move of this code to drivers/.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Reviewed-by: NRuss Dill <Russ.Dill@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      ff4ae5d9
    • P
      ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain functions into PRM · 49815399
      Paul Walmsley 提交于
      Move the low-level SoC-specific powerdomain control functions into
      prm*.c.  For example, OMAP2xxx low-level powerdomain functions go into
      prm2xxx.c.  Then remove the unnecessary powerdomain*xxx*.c files.
      
      The objective is to centralize low-level PRM register accesses into
      the prm*.[ch] files, and then to export an OMAP SoC-independent API to
      higher-level OMAP power management code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Acked-by: NRajendra Nayak <rnayak@ti.com>
      Reviewed-by: NRuss Dill <Russ.Dill@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      49815399
    • P
      ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files · 139563ad
      Paul Walmsley 提交于
      Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and
      OMAP2xxx-specific macros into prm2xxx.h.  (prm2xxx.c will be created
      by a subsequent patch when it's needed.)  Move basic PRM register
      access functions into static inline functions in prm2xxx_3xxx.h, leaving
      only OMAP2/3 hardreset functions in prm2xxx_3xxx.c.
      
      Also clarify the initcall function naming to reinforce that this code
      is specifically for the PRM IP block.
      
      This is in preparation for the upcoming powerdomain series and the
      upcoming move of this code to drivers/.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Reviewed-by: NRuss Dill <Russ.Dill@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      139563ad
    • P
      ARM: OMAP2+: PRM: remove PRM weak functions · 7a0c1933
      Paul Walmsley 提交于
      Remove the now-unused PRM weak functions from prm_common.c.  These
      were formerly used to ensure that some OMAP2/3 PRM code would build on
      OMAP4, but none of those functions ever would have worked on OMAP4 due
      to an incompatible PRM register layout.  Now all that has been cleaned
      up and these can be removed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Reviewed-by: NRuss Dill <Russ.Dill@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      7a0c1933
  6. 19 10月, 2012 8 次提交